Skip to main content

Command: Generate

Symbol: ac_icon_generate.png

This command (category "Composer") starts a build process which automatically generates the CODESYS application from the module tree and the settings of the Generator configuration.

Messages and errors will be displayed in the message view.

All objects created by the standard generator (except task objects and applications) will be stored in the subfolder of the application resp. POU pool named AC_Std and AC_FBs. If a folder with the same name already exists, a unique name will be created by adding a suffix _0.

Figure 39. Generated function blocks
Generated function blocks


All objects created by the Generate command are marked with a blue overlay icon. If the user tries to delete, move or modify one of these objects a dialog will open which tells that this action may cause compile problems. If the user continues the color of the overlay icon changes to red (see function block AC_PRG_RMP (PRG) in the screenshot above).

Tip

If you use the Application Composer together with CODESYS SVN:

All Composer generated objects are marked with an Ignore on Commit for SVN. Additionally SVN is switched to the offline mode to avoid SVN locks while the Built command is executed.

Creation of function block instances by the standard generator

For each module instance a function block will be created (in the folder AC_FBs). This function block derives from the module function block.

The function block contains input variables

  • Submodule instances

  • Arrays of configurable size

  • Buffer variables of direct I/O connections

  • Arrays of multislots and instance references

The name of the respective array variable is created by the prefix AC_ARRAY_ followed by the variable name of the respective pointer variable. For arrays with variable index size (VarArrays) the name can be overwritten by the parameter VarArray.InstName.

The implementation part of the function block contains the command SUPER^(); which calls the implementation part of the module function block.

Example 11. Example

The module instance ModuleInstanceA is of type ModuleA and related function block ModuleA_FB. This instance has got a submodule instance of type ModuleB.

The module instance ModuleInstanceA is of type ModuleA and related function block ModuleA_FB. This instance has got a submodule instance of type ModuleB.

FUNCTION_BLOCK AC_ModuleInstanceA EXTENDS ModuleA_FB

VAR_INPUT
        Inst_Sub1 : AC_ModuleInstanceB ;
END_VAR

The name of the function block is created from the module instance path and the prefix AC_.

The name of the variable of the submodule instance is created from a prefix followed by the name of the respective submodule instance.



Each function block is instantiated once, the FB instance of toplevel module directly in the GVL - the rest in the according function blocks of the father instances.

For each referenced module instance which is located in another application, exactly one function block instance of the proxy FB will be created in one GVL of a referring module instance. The name of the proxy instance is AC_PROXY_<InstanceName> where <InstanceName> is the name of the target instance in the other application.

Unique addresses are assigned to all module instances. The proxy FB instances are assigned by the addresses of the module instances in the remote application.

The method IBaseInstance.Main of the proxy instances is called cyclically in the communication task.

Creation of the application and task calls

  • If a module is assigned to an application which does not exists, this application will be created.

  • Creation of non-existing standard task

    • TASK_MODULE_HIGH

    • TASK_MODULE_MEDIUM

    • TASK_MODULE_LOW

    The priority and the cycle time of the tasks is set according to the generator settings. Furthermore module specific tasks with the given settings will be created.

  • Creation of one global variable list per toplevel. In this GVL, module instances which are located under the toplevel module instances of the same application will be created. The global variable list has the name defined in the module, or if it does not have a defined name, it will get the name GVL_MODULE. The GVL is located below the selected application or in the global POU tree.

    Creation of one GVL with the name GVL_ MODULE_TREE for each application. This list contains variables to manage the module tree. The GVL will be created in the folder AC_Std.

  • Creation of initialization code which is called automatically on download and online change:

    • The tree structure will be created.

    • Parameter values will be set.

    • References and submodule instances will be assigned.

    • Arrays with variable size will be filled.

    • Instance references will be set.

    On download only the parameters will be set which are not set to their default value. On online change all parameters will be set. The POUs will be created in the folder AC_Std.

  • For each defined entry point a PROGRAM POU (language ST) will be created which contains the calls of the toplevel modules. The call of this new POU will be added below the task. In case of the standard task the POU names are:

    • MODULE_CALL_<TASKNAME>_START

    • MODULE_CALL_<TASKNAME>_END

    The POUs will be created in the folder AC_Std.

  • For toplevel modules in the POUs pool the task calls will be created in all applications.

Creation of the I/O assignment

Depending on the type of the I/O assignment the following actions will be performed:

  • [I/O channel]: In the corresponding device channel the instance name of I/Os of the module instance will be added.

  • [ST expression]: The assignments of the expressions to the inputs or of the outputs to the expressions will for all module instances below the same toplevel instance. If there are according assignments, for each toplevel instance a function named

    • AC_Io_SetInputs_<instance name> or

    • AC_Io_SetOutputs_<instance name>

    will be created.

    The task which defines inputs and outputs will be identified by the flag UPDATE-IOS in the module description. This task will be called "I/O task" in the following description.

    The function for the inputs will be called in the I/O task before the task method of the module instance is called. (If the I/O task is a standard task, before the start method.) The function for the outputs will be called in the I/O task after the task method of the module instance. (If the I/O task is a standard task, after the end method.)

  • [Direct connection to module I/O, local]: A buffer variable of compatible type will be created in the function block of the instance of the input. The name of the buffer variable begins with the prefix AC_Io_Buffer_.

    The buffer variables will be initialized to the current values of the connected outputs during the initialization of the application. The generator handles the input- and output assignments like a ST assignment to this buffer variable (see [ST expression].

  • [Direct connections to module I/O, remote]: For each output which is connected to an input of a module instance from another application, a buffer variable with compatible type will be created in the corresponding send network GVL. The name of the buffer variable begins with prefix AC_RemoteIo_Buffer_ and will be built from the instance path and the variable path of the output. The buffer variables will be initialized with the initialization expression from the output variable, if it exists. If the value of this initialization expression is not contained in the precompile information (because the expression uses example: variables, functions and constants), an error is created.

    The generator handles the output assignment like an assignment to this buffer variable. The input assignment in the other application is handled like an assignment from the corresponding variable in the receiver NVL (see [ST expression]).

    Note: The synchronization between the task, in which the network variable shall be updated and the I/O task of the module is not realized yet. Therefore it may be possible that values have been written incompletely while the I/O task reads it.

Creation of the communication infrastructure

Definition: In the following description the application A1 sends to application A2 (or A2 receives from A1) if the following conditions are met:

  • A module instance which is assigned to application A1 references a module instance which is assigned to application A2 or vice versa.

  • An output of a module instance which is assigned to A1 is connected to a module instance which is assigned to A2 by use of a direct module I/O connection.

All objects mentioned below will be created in the folder AC_RMP for each application created by the generator.

  • A communication task will be created. (Cycle time and priority according to the settings of the generator configuration). In this task the proxy instances will be called and the mirrored module proxy FB variables will be read resp. written.

  • For each application which sends to the current application, a (send) GVL will be created and the network settings will be defined. (Protocol "UDP", cyclic transmission, checksum, cycle time according to the settings, communication task). The "list identifier" which must be an integer value between 1 and 2^15-1 will be determined by random at the beginning of the generation and increased by 1 after each send GVL. This value is at least 128 and within the valid range. If there are module references between the applications a variable of type RMPExchangeData will be created in the GVL. The name of the variable contains the name of the source- and the target application. If a module instance defines variables in its proxy definition to be mirrored (MirrorVar) and is referenced from an other module instance, for each of this MirrorVars a variable will be created in the (send) GVL of the referenced module instance. Its name contains the instance path of the module instance and the TargetID of the corresponding "MirrorVar" definition.

  • For each application A2, to which the current application sends, a (receive) NVL will be created and connected to the corresponding send GVL of A2 and the communication task.

  • A function block of type RMPService will be instantiated in the GVL AC_RMP and initialized in the declaration (with attribute init_on_onlchange). Two arrays of type RMPConnection will be created which refer to the created variables of type RMPExchangeData in the GVLs and NVLs.

  • A program AC_PRG_RMP will be created which calls the function block of type RMPService. This program will be added to the communication task. Additionally the value of the mirrored variables ("MirrorVars") will be set and read in the AC_PRG_RMP program. This means that the proxy "MirrorVars" will be assigned to the corresponding variables of the (receive) GVL. Then the Main method of the proxy instance is called and finally the corresponding variables of the (sender) GVL of the "MirrorVars" module. This happens according to the send direction of module instances to proxies.

: