Applying the TcCOM Wrapper FB

There are two ways to call a TcCOM object from the PLC:

Configuration of the TcCOM Wrapper function block in Simulink^®

Navigate to Configuration Parameters > Code Generation > TC TcCom Wrapper. Check the TcCom Wrapper FB checkbox here. The checkbox is unchecked in the standard configuration. You can use the TcCom Wrapper FB properties checkbox to configure whether the model parameters on the function block are to be created as properties.

In the "advanced" configuration level, the monitoring attribute of the properties can also be specified. In the default case, "No Monitoring" is set, i.e. no attribute is set.

Monitoring attributes influence the visibility of the attribute values in the online view, i.e. when you have logged into the PLC and want to monitor the current values of the properties on the FB.

• No Monitoring: the values are not visible in the online view.
• Cyclic Update: the values of the properties are updated and displayed cyclically.
  In the logged-in state in the PLC additional code is executed.
• Execution Update: the values of the properties are only updated in the online view if getter/setter methods for the properties are called in the execution code. This quickly leads to irritation and is only relevant in rare cases.

Create instance of the TcCOM Wrapper function block

Version 1: referencing a static module instance

The function block 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 function block instance. See red area in graphic below.

The instance of the TcCOM object and the calling PLC must run in the same task. On the instance of the TcCOM object, make sure that under Parameter (Init) the entry ModuleCaller is set to Module and not to CyclicTask. In this case, the required memory for the TcCOM is obtained from the non paged pool of the system.

Version 2: dynamic instantiation and referencing from the PLC

The function block can also be used in such a way that a TcCOM object is generated from the PLC and linked to the wrapper. In the graphic below, this is the green area as a minimum example and the blue area with extended parameterization.

The TaskOid of the PLC task must be used to specify the real-time task in which the wrapper is called. The ModuleCaller must also be set to Module here (via the Init structure). In this case, the required memory for the TcCOM is obtained from the router memory.

Graphic in the web browser view Right-click on the image and select "open image in new tab" to better read the image.

The source code for the graph shown above is available in MATLAB^® via the Command Window:

TwinCAT.ModuleGenerator.Samples.Start('TcComWrapper TemperatureController')

Working with the properties of the TcCOM Wrapper FB

Properties on the FB provide an easy way to interact with module parameters of a TcCOM, see also Best Practice: access to TcCOM data.

Sample

By setting the Parameter: Initial Values under Tc TcCom Interfaces, the model parameters are created as module parameters (switched on by default). Now create the "TcCom Wrapper FB" with the option "TcCom Wrapper FB properties". Set the property monitoring to "CyclicUpdate" to see the value change of the property directly in the online view.

Then you can access the module parameters as follows, for example:

PROGRAM MAIN
VAR
   
   // dynamic instance: create TcCOM from PLC
   InitStrDyn : ST_FB_TempCtrl_TcCOM_InitStruct_InitStruct := (
               TaskOid:= 16#02010030,                    // take TaskOID of PlcTask
               eModuleCaller:= ModuleCaller.Module );        // set module caller to "call by module"
   fbTempCtrDyn : FB_TempCtrl_TcCOM_InitStruct(InitStrDyn);
   
   Outputs    : ExtY_TempCtrl_T;   // input
   Inputs     : ExtU_TempCtrl_T;   // output
   Parameters : P_TempCtrl_T;      // parameter

   bChange: BOOL;
END_VAR

fbTempCtrDyn(TempCtrl_U := Inputs, TempCtrl_Y => Outputs);

IF bChange THEN
   Parameters.Kp := 10;
   fbTempCtrDyn.TempCtrl_P := Parameters;
END_IF

Working with the ADI Interface

The following is a sample of how to access the DataArea of the BlockIO in read-only mode:

stInitTemp : ST_Funktionsblock_SimpleTempCtrl_TcCOM_InitStruct := (nOid := 16#01010010);
FunktionsblockTempCtr  : Funktionsblock_SimpleTempCtrl_TcCOM_InitStruct(stInitTemp);   
stTempCtr_BlockIO  : ST_B_SimpleTempCtrl_T;
pStTempCtr_BlockIO : POINTER TO ST_B_SimpleTempCtrl_T;
hr : HRESULT;

(* read data are via ADI Interface *)
// get a pointer to Data Area
hr := FunktionsblockTempCtr.ipADI.GetImagePtr(size := SIZEOF(stTempCtr_BlockIO), offs := 0, adi_x := 2, ppData := ADR(pStTempCtr_BlockIO));
IF hr = 0 THEN
   // copy data to a local variable
   MEMCPY(ADR(stTempCtr_BlockIO), pStTempCtr_BlockIO, SIZEOF(stTempCtr_BlockIO));
   // always release the pointer!
   FunktionsblockTempCtr.ipADI.ReleaseImagePtr(pData := pStTempCtr_BlockIO);
END_IF;

Among other things, adi_x and offs are passed to the GetImagePtr method. These determine the DataArea itself, in this case DataArea number 2 (SimpleTempCtrl_B), and the data area in the area to be read/written, in this case without offset and the total size of the DataArea (i.e. the entire DataArea).

When writing, the source and destination must be swapped accordingly at MEMCPY in the above sample.

For further instructions on how to interact with the TcCOM, refer to Best Practice: access to TcCOM data.