Calling the generated module from a PLC project

If the call parameter "CallBy" was set to the value "Module", the assigned tasks do not call the module automatically. To call the generated TcCom module via another module instead, the interfaces of that module can be accessed. This can be done from a C++ module or, as shown below, from the TwinCAT PLC.
A PLCopen XML file is generated during code generation. This file can be found in the build directory <MODEL_DIRECTORY>\<MODEL_NAME>_tct and - if the module was exported via the Publish step - also in the Publish directory of the module. The file contains POUs that simplify calling a Simulink object from the PLC by encapsulating the handling of the interface pointers. The POUs can be imported via Import PLCopenXML in the context menu of a PLC project node.

Calling the generated module from a PLC project  1:

The following descriptions apply from version 1.2.1216.0 of TE1400!

Configuration in Simulink

In the settings under Tc Advanced, CallBy is initially set to Module (can be changed later in TwinCAT Engineering).

The parameter Skip caller verification is visible from TE1400 version 1.2.1230.

The parameter PLC Function Block (TcCOM wrapper) is available from TE1400 version 1.2.1216.0:

Calling the generated module from a PLC project  2:

The following options are available for selection:

Option

Description

None

No PLCopen XML file is generated

Generic FB only

Only the function block FB_TcMatSimObject (see also here), which applies to all modules generated with TE1400 and data types used by it, is generated. The data exchange takes place via generic methods. The user must know module-specific data such as byte-sizes, parameter index offsets or DataArea IDs.

Version note: Up to and including TE1400 1.2.1216.0, this generic FB can only be used in a meaningful way, if an FB derived from it is implemented, which deals with the initialization of internal variables.
From version 1.2.1217.0 additional methods are available, which enable direct initialization, i.e. without derived FB.

Module specific FB

In addition to the generic FB_TcMatSimObject, the module-specific function block FB_<ModuleName> and associated data types are generated. The structure of the input and output variables exactly matches the structure of the corresponding data areas of the module. For exchanging data, the input and output variables can be assigned directly, without having to explicitly specify the size of the data areas or the DataArea IDs, for example.

Module specific FB with properties for all parameters

The module-specific function block FB_<ModuleName> is assigned additional properties. Based on these properties, module parameters can be read and also written, if appropriate. For each module parameter the function block is assigned two properties: "PrameterName_Startup" and "ParameterName_Online".

The module-specific function block

FB_<ModuleName> is derived from FB_TcMatSimObject and provides the methods and properties described above. In addition, the following properties are implemented:

Public Properties:

Method

Data type

Description

InitData

ST_<ModuleName>_InitData

Stores the startup values of the module parameters for initializing a module instance. During module state transitions the values are transferred to the module from INIT to PREOP via SetObjState(). Required for dynamic instantiation.

<ParameterName>_Startup

<ParameterType>

Available for all parameters, if the coder is configured accordingly. Enables transparent access to the corresponding element of the InitData structure (read/write).

<ParameterName>_Online

HRESULT

Available for all parameters, if the coder is configured accordingly. Reads or writes the online values of the corresponding module parameter.

Notes regarding FB with properties for all parameters

If Process image is set to Internal DataArea under Tc Interfaces in the Parameter access area, a property is created for all parameters. These must then be read and written as an entity:

PROGRAM MAIN
VAR
// declare function block (details see below)
fbControl : FB_TctSmplTempCtrl(oid := 16#01010010);
// local PLC variable
ModelParameters : P_TctSmplTempCtrl_T;
END_VAR

// read all model parameters
ModelParameters := fbControl.ModelParameters_Online;
// change value
ModelParameters.Kp := 20;
// write all model parameters
fbControl.ModelParameters_Online := ModelParameters;

If Process image is set to No DataArea under Tc Interfaces in the Parameter access area, a separate property is created for each model parameter. These can then be read and written directly without a local PLC variable.

Fb<ModelName>.ModelParameters_<ParameterName>_Online

Referencing a static module instance:

The FB can be used to access module instances previously created in the XAE, e.g. under System > TcCOM Objects. For this static case, the object ID of the corresponding module instance must be transferred during declaration of the FB instance:

fbStatic : FB_<ModuleName>(oid:=<ObjectId>);

The object ID can be found in the instance of TcCOM under the Object tab.

Sample code

The following code sample illustrates the application of a module-specific function block in a simple PLC program in ST code, using an object of module class "TempContr" with ObjectID 0x01010010 as an example:

PROGRAM MAIN
VAR
// declare function block with ID of referenced Object
fbTempContr : FB_TempContr(oid:= 16#01010010 );
// input process image variable
nInputTemperature AT%I* : INT;
// output process image variable
bHeaterOn AT%Q* : BOOL;
END_VAR
IF (fbTempContr.State = TCOM_STATE.TCOM_STATE_OP) THEN
// set input values
fbTempContr.stInput.FeedbackTemp := nInputTemperature;
// execute module code
fbTempContr.Execute();
// get output values
bHeaterOn := fbTempContr.stOutput.HeaterOn;
END_IF

Generating and referencing a dynamic module instance:

If <ObjectId> = 0, the FB attempts to generate an instance of the TcCom module dynamically:

fbDynamic : FB_<ModuleName>(oid:=0);

In this case, the module instance does not appear in the XAE configuration tree, but only appears at runtime (i.e. after the initialization of the PLC instance) in the "Project Objects" table of the System > TcCOM Objects node.

A prerequisite for dynamic instantiation of a TcCOMmodule if that the corresponding "Class Factory" is loaded. To this end, the Load checkbox (or the TC Loader checkbox if the "TwinCAT Loader" is used) must be set for the "Class Factory" of the module under the Class Factories tab of the System > TcCOM Objects node. The name of the "Class Factory" of a TcCOM module generated from Simulink usually matches the module name, although the ClassFactory name is limited to fewer characters.

A further condition for dynamic instantiation of a module is adequate availability of dynamic memory. To this end, the ADS router memory must be set to an adequate size.
Sample code:

PROGRAM MAIN
VAR
// declare function block
fbTempContr_Dyn : FB_TempContr(oid:= 0 );
// input process image variable
nInputTemperature AT%I* : INT;
// output process image variable
bHeaterOn AT%Q* : BOOL;
// reset error code and reinitialize Object
bReset: BOOL;
// initialization helpers
stInitData : ST_TempContr_InitData;
bInitialized : BOOL;
END_VAR
IF (NOT bInitialized) THEN
stInitData := fbTempContr_Dyn.InitData; // read default parameters
// adapt required parameters:
stInitData.ContextInfoArr_0_TaskOid := 16#02010020; // oid of the plc task
stInitData.ContextInfoArr_0_TaskCycleTimeNs := 10 * 1000000; // plc task cycle time in ns
stInitData.ContextInfoArr_0_TaskPriority := 20; // plc task priority
stInitData.CallBy := TctModuleCallByType.Module;
stInitData.StepSize := TctStepSizeType.UseTaskCycleTime;
// set init data, copied to module the next time it switches from INIT to PREOP:
fbTempContr_Dyn.InitData := stInitData;
bInitialized := TRUE;
ELSIF (fbTempContr_Dyn.State<TCOM_STATE.TCOM_STATE_OP) THEN
// try to change to OP mode
fbTempContr_Dyn.State := TCOM_STATE.TCOM_STATE_OP;
ELSIF (NOT fbTempContr_Dyn.Error) THEN
// set input values
fbTempContr_Dyn.stInput.FeedbackTemp := nInputTemperature;
// execute module code
fbTempContr_Dyn.Execute();
// get output values
bHeaterOn := fbTempContr_Dyn.stOutput.HeaterOn;
END_IF

IF (bReset) THEN
IF (fbTempContr_Dyn.Error) THEN
fbTempContr_Dyn.ResetHresult();
END_IF
fbTempContr_Dyn.State := TCOM_STATE.TCOM_STATE_INIT;
END_IF

Task context setting

The PLC task from which the call is made must be configured in the context settings of a static module instance.

Calling the generated module from a PLC project  3:

The object ID of the PLC task must be transferred to a dynamic module instance via the InitData structure. If available, the corresponding InitData element can be set via the property "ContextInfoArr_<contextId>_TaskOid_Startup".

When the TcCOM module is called, a context verification is performed. An error message is displayed if the context is not correct. This verification takes time and is performed with each call. For this reason, the verification can be deactivated via the checkbox Skip caller verification in the Tc Advanced dialog, see Skip caller verification.

Import of several PLCopen-XML: FB_TcMatSimObject

The generic function block FB_TcMatSimObject is identical for all modules generated with TE1400 (from V1.2.12016.0). Even if it is used for different modules, it only has to be imported once into the PLC project.

Description of the function block:

Public Methods

Method

Return data type

Description

Execute

HRESULT

Copies the data of the InputDataArea structures from the FB to the module instance (of the object), calls the cyclic methods of the object and copies the data from the output data areas back into the corresponding data structures of the FB

GetObjPara

HRESULT

Reads parameter values from the object via PID (Parameter ID = ADS Index Offset)

SetObjPara

HRESULT

Writes parameter values to the object via PID (Parameter ID = ADS Index Offset)

ResetHresult

 

Acknowledges error codes that have occurred during initialization of the FB or when calling "Execute()".

SaveOnlineParametersForInit

HRESULT

Reads the current online values of the parameters from the object and saves them in the parameter structure after the FB variable pInitData, if it exists

SetObjState

HRESULT

Tries to bring the TCOM_STATE of the object to the required target state, step-by-step

AssignClassId

 

From TE1400 1.2.1217.0:
Sets the expected class ID for the case of referencing a static object. This is compared with the class ID of the referenced module to avoid problems due to incompatibilities. If no class ID is assigned, this compatibility check is omitted.
To generate a dynamic object, the class ID must be defined via this method.

SetInitDataInfo

 

From TE1400 1.2.1217.0:
Transfers the pointer to the InitData structure to be used. This structure must be created when dynamic objects are used. It must be initialized with parameters, as required. For static objects, this structure is optional. It enables subsequent re-initialization of the object. In this case, the structure may also be initialized by calling "SaveOnlineParametersForInit".

SetDataAreaInfo

 

From TE1400 1.2.1217.0:
Transfers the pointer to an array of DataArea information of type ST_TcMatSimObjectDataAreaInfo, and the number of elements in that array. This information is required for cyclic data exchange within the "Execute" method.

Public Properties

Method

Data type

Description

ClassId

CLSID

Returns the ClassId of the module

Error

BOOL

Returns TRUE if a pending error requires acknowledgement

ErrorCode

HRESULT

Returns the current error code

State

TCOM_STATE

Returns the current TCOM_STATE of the object, or tries to bring it into the target state, step-by-step

Referencing a module instance

Just like the module-specific FB derived from it, FB_TcMatSimObject can be instantiated with the object ID of a static module instance or with 0:

fbStatic : FB_TcMatSimObject(oid:=<ObjectId>); // Referenz auf statisches TcCom-Objekt 
fbDynamic : FB_TcMatSimObject(oid:=0); // Erzeugen eines dynamisches TcCom-Objektes