You can declare the methods explicitly in order to influence the initialization of function block variables, as well as the behavior when exiting function blocks.
The type of the return value for the implicit methods is BOOL. The value is not evaluated by the system, but the type should not be changed.
FB_Init is always available implicitly and it is used primarily for initialization. For a
specific influence, you can also declare the methods explicitly and provide additional
code there with the standard initialization code.
FB_Reinit must be implemented explicitly. If this method exists, then it is called after the
instance of the affected function block is copied. That happens during an online change after changes to the function block declaration
(signature change) in order to reinitialize the new instance module. To reinitialize
the basic implementation of the function block, you must call FB_Reinit explicitly.
FB_Exit must be implemented explicitly. If there is an implementation, then the method is
called before the controller removes the code of the function block instance (implicit
call).
The following shows some use cases of these methods for different operating conditions.
Operating condition "First download"
When downloading an application to a PLC with factory settings, the memory of all
variables must be offset to the required initial state. In this way, the data areas
of function block instances are assigned the required values. By the explicit implementation
of FB_Init for function blocks, you can react specifically to this situation in the application
code. By evaluating the method parameters bInCopyCode (FALSE) and bInitRetains (TRUE), you can detect this operating condition clearly. (See "Operating condition "Online
Change"" and "Operating condition "Re-download"".)
Operating condition "Online Change"
Within the scope of the online change, you can influence the initialization of function
block instances by means of the methods FB_Exit, FB_Init, and FB_Reinit. During the online change, the changes to the application that were made in offline
mode are applied in the running PLC. This is the reason that the old instances of
the function blocks are replaced by new instances as much as possible without incident.
If no changes were made to the declaration part of a function block in the application
before login, but in the implementation only, then the data areas are not replaced.
Only code blocks are replaced. Then the methods FB_Exit , FB_Init, and FB_Reinit are not called.
If you have made changes to the declaration of a function block that lead to the copying operation described above, then you receive a message during the online change about possible unintended effects. In the “Details” of the message view, you see a list of all instances to be copied.
In the code of the FB_Init method, the parameter bInCopyCode (TRUE) can be evaluated to detect whether or not an online change is being executed.
The following calls occur in succession during an online change:
-
FB_Exitold_inst.FB_Exit(bInCopyCode := TRUE);You can call
FB_Exitwhen exiting the old instance in order to trigger specific cleanup tasks before the copy operation. In this way, you can prepare the data for the following copy operation and influence the state of the new instance. You can notify other parts of the application about the pending change in location in the memory. Pay special attention to the variables of typePOINTERandREFERENCE. These may no longer refer to the required memory locations after the online change. Interface variables (INTERFACE) are handled separately by the compiler and they are adapted accordingly during the online change. External resources such as sockets, files, or other handles can be applied by the new instance, in some case unchanged. Often they do not have to be treated specially during an online change. (See "Operating condition "Re-download"") -
FB_Initnew_inst.FB_Init(bInitRetains := FALSE, bInCopyCode := TRUE);FB_Initis called before the copy operation and can be used in order to execute specific operations for the online change. For example, you can initialize variables accordingly at the new location in the memory, or notify other parts of the application about the new location of specific variables in the memory. -
Copy operation:
copycopy(&old_inst, &new_inst);Existing values remain unchanged. For this purpose, they are copied from the old instance into the new instance.
-
FB_Reinitnew_inst.FB_Reinit();This method is called after the copy operation and should set defined values for the variables of the instance. For example, you can initialize variables accordingly at the new location in the memory, or notify other parts of the application about the new location of specific variables in the memory. Design the implementation independent of the online change. The method can also be called from the application at any time in order to reset a function block instance to its original state.
With the {attribute 'no_copy'} attribute, you can prevent that this is copied during the online change for a single
variable of the function block. It always retains the initial value.
Operating condition "New download"
When downloading an application, an existing application may be replaced on the PLC.
Therefore, the provision of memory for the present function blocks must be regulated.
You can use the FB_Exit method for implementing the required steps for this. For example, you can offset
external resources (with socket and file handles) in a defined state.
You can detect this operating condition by checking whether or not the parameter bInCopyCode = FALSE for the FB_Exit method.
Operating condition "Start of application"
The initial assignments are processed before the first cycle of the application tasks.
Example
T1 : TON := (PT:=t#500ms);
These kinds of assignments are executed only after calling FB_Init. In order to control the effects of these assignments, you can provide a function
block or a method of a function block with the {attribute ‘call_after_init‘} attribute. You must add the attribute above the declaration part of the function
block body and above the declaration part of the corresponding method. A POU that
extends another POU which uses the {attribute 'call_after_init'} attribute must also have the attribute. For the benefit of clarity, we recommend
that the corresponding methods are overwritten with the same name, the same signature,
and the same attribute. This requires calling SUPER^.MyInit. The name of the method can be chosen without restriction. (Exceptions: FB_Init, FB_Reinit, and FB_Exit). The method is called after processing the initial assignments and before starting
the application tasks. Therefore, the method can react to user input.
When using FB_Init or {attribute 'call_after_init'}, remember that detecting errors in the FB_Init method or in methods decorated with the {attribute 'call_after_init'} attribute is tedious, because the setting of breakpoints may not have the expected
effect.
NOTICE
If the explicitly defined initialization code is reached during execution, then the
function block instance is already completely initialized via the implicit initialization
code. Therefore, there must not be a SUPER^.FB_Init call.
NOTICE
FB_Init replaces the INI operator used in CoDeSys V2.3. The methods cannot be compared to the design of a constructor, such as in C#, C++,
or Java. This has consequences for function blocks that extend other function blocks.
(See below: "Derived function blocks")
Interface of method FB_Init
METHOD FB_Init : BOOL VAR_INPUT bInitRetains : BOOL; // TRUE: the retain variables are initialized (reset warm / reset cold) bInCopyCode : BOOL; // TRUE: the instance will be copied to the copy code afterward (online change) END_VAR
You can declare additional function block inputs in an FB_init method. Then you have to set these inputs in the declaration of the function block
instance.
Example
Method FB_Init for the serialdevice function block
METHOD PUBLIC FB_Init : BOOL
VAR_INPUT
bInitRetains : BOOL; // initializing of retain variable
bInCopyCode : BOOL; // instance is copied to copy code
iCOMnum : INT; // additional input: number of the COM interface, that is to be observed
END_VAR
Instantiation of the serialdevice function block:
com1: serialdevice(iCOMnum:=1); com0: serialdevice(iCOMnum:=0);
Interface of method FB_Reinit
METHOD FB_Reinit : BOOL
Interface of method FB_Exit
There is the mandatory parameter bInCopyCode.
METHOD FB_Exit : BOOL VAR_INPUT bInCopyCode : BOOL; // TRUE: the exit method is called in order to leave the instance which will be copied afterwards (online change). END_VAR
Behavior for derived function blocks
If a function block is derived from another function block, then the FB_Init method of the derived function block must define the same parameters as the FB_Init method of the basic function block. However, you can add further parameters in order
to set up a special initialization for the instance.
Example
The function blocks MainFB, SubFB, and SubSubFB are derived from each other. Therefore, SubFB EXTENDS MainFB and SubSubFB EXTENDS SubFB apply.
Calling order of methods FB_Exit and FB_Init:
-
fbSubSubFb.FB_Exit(...); -
fbSubFb.FB_Exit(...); -
fbMainFb.FB_Exit(...); -
fbMainFb.FB_Init(...); -
fbSubFb.FB_Init(...); -
fbSubSubFb.FB_Init(...);