Function vs Function blocks

[otrotabi]

I realize this subject has many answers on Google so I apologize for posting it, but still the main reason for choosing a function over a funcion block is not clearly answered I think.

So, I need to create a function (or a function block) to validate a password. I plan to define 4 password levels:  0-User 1-Maintenance 2-OEM 3-Developer which will give a USINT output based on each input, and according to that level it willl let some variables and screens be accesed at the HMI.

So basically I think I could either use a FC or a FB.  Intuitively I would assume that FCs use less PLC resources. Is that the reason for choosing that ?

[FedericoM · Accepted solution]

Hi,

the main differences are the followings:

Functions: 1 output, n input

Function Blocks: m output, n input.

Function input are not supporting complex types (at least in version 1.4.0)

Function blocks are declared as instance of an object, so the internal memory is static, while the one of the functions is allocated in the stack.

It means every time you call a function the local variable are reset, while a FB instance mantains the value reached at previous execution.

So FBs use more RAM because each instance requires a dedicated local memory allocation.

If you need internal states, like the integral part of a PID, i.e. your output depends on input and previous states, you need a FB.

Federico 

[otrotabi]

Thanks for your answer.  As I expected, basically it takes less PLC resources, right ?

Actually i have always used FB, as default. But since I am trying to work with TM171 as well, I´d better start using FC when I can.

I just developed my first FC and included a TON timer there. I could not understand why it was not working until it dawned on me that it will not, right ?

[FedericoM]

Hi,

you can't declare FB instances inside a Functions for the reason explained before.

A FB has internal states declared in a static ram while Functions use temporary ram allocated just for the function execution.

If you do it, you should get a compiler error related to invalid data type used in the function.

[otrotabi]

Thank you. Yes, I understood why this attached function (FC) will not work. It does not keep track of time, so it only works if you define it as a FB. However, regarding your last comment, the compiler does not throw any errors or warnings about a FB being used inside a FC. I am using 1.4.0.

FUNCTION PasswordManager: USINT

VAR
	PasswTimer : TON;	(* After time elapses resets output to cero *)
END_VAR

VAR_INPUT
	i_uiHmiPassword : UINT;	(* Password entered at HMI *)
	i_uiLevel1Password : UINT;	(* Password stored in Eeprom level1 - Installer *)
	i_uiLevel2Password : UINT;	(* Password stored in Eeprom level2 - OEM *)
	i_uiLevel3Password : UINT;	(* Password stored in Eeprom level3 - Developer *)
	i_uiDate : TypeDataTime;	(* Current date *)
	i_usiPassCfg : USINT;	(* Configuration of password check *)
	i_uiTimePassword : UINT;	(* Time to enable password level <> 0 in seconds *)
END_VAR

IF i_uiHmiPassword = 0 THEN
	PasswordManager := 0;
	RETURN;
END_IF;

CASE i_usiPassCfg OF
	0: IF i_uiHmiPassword  = i_uiLevel1Password THEN
			PasswordManager := 1;
		ELSIF i_uiHmiPassword  = i_uiLevel2Password THEN	
			PasswordManager := 2;
		ELSIF i_uiHmiPassword  = i_uiLevel3Password THEN	
			PasswordManager := 3;
		ELSE
			PasswordManager := 0;
		END_IF;
		
	1: //Date dependent password if usiPassCfg = --- SAMPLE CODE
		IF i_uiHmiPassword = (i_uiDate.daymonth * 2 + i_uiDate.dayweek * 3 + i_uiDate.month * 4 + i_uidate.year)THEN
			PasswordManager := 1;
		ELSIF i_uiHmiPassword = (i_uiDate.daymonth * 3 + i_uiDate.dayweek * 4 + i_uiDate.month * 5 + i_uidate.year)THEN
			PasswordManager := 2;
		ELSIF i_uiHmiPassword = (i_uiDate.daymonth * 4 + i_uiDate.dayweek * 5 + i_uiDate.month * 6 + i_uidate.year)THEN
			PasswordManager := 3;
		END_IF;

END_CASE;	

IF PasswordManager < 3 THEN // If developer signs in, will allow everything till PLC is reset or password is changed
	PasswTimer(IN := TRUE, PT := i_uiTimePassword * 1000);
	IF PasswTimer.Q THEN
		PasswordManager := 0; //Resets Password
		PasswTimer( IN := FALSE); //Resets timer
	END_IF;
END_IF;		

[FedericoM]

It seems a problem of the simulator, if I compile for a real target I have the error.

[Bastian_Schmitz]

If you want save ressources here some tips

1. Global Variables need ressources, Status and EEPROM variables not. If you use instead of global vars status you can save space.

2. If you use your own FCs/FBs then use always the smalles possible data types. If you use INT instead of REAL you will save 50% space (16/32Bit). 

3. If you need STRING vars, reduce the char number of the suitable minimum

[otrotabi]

Thanks for your tips. Some further questions, I hope you don´t mind.

• Is IL worth learning ? According to wikipedia it is deprecated and will no longer exist sometime in the future. I noticed most (if not all) of the  FB/FCs available in both basic and basic addons libraries are written in IL so I am curious to know what would happen then.

• I´ve also noticed these libraries are organized following an XML structure. Is it compatible with some other programs ? Codesys maybe ? How do you create a folder structure for libraries ?

• Are some of the OSCAT libraries worth importing ? It seems there are hundreds of different functions and function blocks available.

Regards

[Bastian_Schmitz]

Hello 

Personally I see now reason to use IL/AWL, I would expect ST is alltime more up to date. I learn IL/AWL 10 years ago and I use is than this time exactly 0 times. Maybe I´m wrong but I would expect IL/AWL is an old fashion langugage for people which are near to retierment 🙂

You can excahnge data between Codesys and ESME HVAC via PLCopenXML format. You could find a documentation to this topic here. I hope that will help you.

Normally you could convert FCs/FBs from OSACT to ESME HVAC. I started with a general conversion but I find not enough time. Normally you need "only" to adjust sometimes the syntax.