Method ‘FB_Init’, ‘FB_Reinit’

You can set both of these methods explicitly in order to influence the initialization of function block variables.

FB_Init is always available implicitly and it is used by CODESYS primarily for initialization. For a specific influence, you can declare FB_Init explicitly and supplement the present standard initialization code.

FB_Reinit must be implemented explicitly. When this method is present, it is called after the instance of the corresponding function block is copied (during an online change after changes to the function block declaration). It reinitializes the new instance module. To reinitialize the basic implementation of the function block, you must call FB_reinit explicitly for this basic POU.

If FB_Init or FB_Reinit is called explicitly, then the return value can be evaluated. However, if these functions are called implicitly, then the respective return value is not evaluated.

The following includes application possibilities and effects of methods in different operating conditions where variable initializations occur.

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 blocks 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 assigning the method parameters bInCopyCode (FALSE) and bInitRetains (TRUE), you can detect this operating condition clearly. (See “Online change” and “Re-download”)

Online change

Within the scope of the online change, you can influence the initialization of function blocks 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 changes were made to the implementation part (and not the declaration part) of a function block in the application before login, then the data areas are not replaced. Only code blocks are replaced. This also means that 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 methods FB_Init and FB_Exit, the values of the parameters bInCopyCode (TRUE) and bInitRetains (FALSE) can be used to detect whether or not an online change is currently running.

The following calls occur in succession during an online change:

  1. 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. Variables of type INTERFACE are handled separately by the compiler and they are adapted accordingly during the online change. External resources, such as SOCKET, FILE, and other handles, may be applied unchanged by the new instance, and often they do not have to be handled separately during the online change. (See “Download”)

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

  3. Copy

    copy(&old_inst, &new_inst);

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

  4. 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. You design the implementation independent of the online change because it can be called from the application at any time when a function block should be offset again to the original state.

Note

With the no_copy attribute, you can prevent that this is copied during the online change for a single variable of the function block. It always has the initial value.

Re-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 (such as SOCKET and FILE handles) in a defined state.

You can detect this operating condition in the code of the method FB_Exit by means of the parameters bInCopyCode (FALSE) and bInitRetains (FALSE).

Starting the 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.

However, when using FB_Init or {attribute 'call_after_init'}, remember that detecting errors in the FB_Init method or in methods with the {attribute 'call_after_init'} attribute is tedious, because the setting of breakpoints may not have the expected effect.

Attention

If the execution reaches the explicitly defined initialization code, the function block is already completely initialized via the implicit initialization code. Therefore, there must not be a SUPER^.FB_Init call.

Attention

FB_Init replaces the INI operator used in CoDeSys V2.3. It cannot be compared to the design of a constructor like in C#, C++, Java, etc. This has consequences for POUs that extend other POUs. (See below: “Derived POUs”)

Interface of 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

The return value is not used.

You can declare additional function block inputs in an FB_init method. You must assign the inputs to a function block instance in the declaration.

Example

FBInit method for a serialdevice function block

PUBLIC FB_init : bool
VAR_INPUT
    bInitRetains : BOOL; // initializing of retain variable
    bInCopyCode : BOOL; // instance is copied to copy-code
    nCOMnum : INT; // additional input: number of the  COM-interface, that is to be observed
END_VAR

Declaration of the serialdevice function block

\ com1: serialdevice(nCOMnum:=1);
    com0: serialdevice(nCOMnum:=0);

Derived POUs

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.

If you change the signature in a function block, then each POU extending this original POU (EXTENDS) must have an explicit variant of the FB_Init method. Otherwise the extending POU does not get the changed signature.

For information about the processing order and calling order for inheritance, refer to the help page of the FB_exit method: Method ‘FB_Exit’

Example of the calling order of derived function blocks

FB_Exit and FB_Init

Given for the functions blocks in this list: SubFB EXTENDS MainFB and SubSubFB EXTENDS SubFB.

  1. fbSubSubFb.FB_exit(…);

  2. fbSubFb.FB_exit(…);

  3. fbMainFb.FB_exit(…);

  4. fbMainFb.FB_init(…);

  5. fbSubFb.FB_init(…);

  6. fbSubSubFb.FB_init(…);

See also