Methods ‘FB_Init’, ‘FB_Reinit’, and ‘FB_Exit’¶

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.

FB_Init is always available implicitly and it is used primarily for initialization. The return value is not evaluated. For a specific influence, you can also declare the methods explicitly and provide additional code there with the standard initialization code. You can evaluate the return value.

FB_Reinit must be implemented explicitly. If this method is present, 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. The return value is not evaluated. To reinitialize the basic implementation of the function block, you must call FB_Reinit explicitly. You can evaluate the return value.

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 return value is not evaluated.

The following shows some use cases of these methods for different operating conditions.

Operating condition “First download”
Operating condition “Online change”
Operating condition “New download”
Operating condition “Start of application”
Interface of the FB_Init method
Interface of the FB_Reinit method
Interface of FB_Exit method
Behavior for derived function blocks

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.

Note

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_Exit

old_inst.FB_Exit(bInCopyCode := TRUE);

You can call FB_Exit when exiting the old instance in order to trigger specific cleanup activities 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 type POINTER and REFERENCE. 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_Init

new_inst.FB_Init(bInitRetains := FALSE, bInCopyCode := TRUE);

FB_Init can be called in order to execute specific operations for the online change.
Copy operation copy

copy(&old_inst, &new_inst);

Existing values remain unchanged. For this purpose, they are copied from the old instance into the new instance.
FB_Reinit

new_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.

Note

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.

Hint

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.

Hint

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 the `FB_Init` method ¶

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 the `FB_Reinit` method ¶

METHOD FB_Reinit : BOOL

Interface of `FB_Exit` method ¶

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(...);