Aufruf des generierten Moduls aus einem SPS-Projekt
Wurde der Aufruf-Parameter „CallBy" auf den Wert „Module“ gesetzt, rufen die zugewiesenen Tasks das Modul nicht automatisch auf. Um das generierte TcCom-Modul stattdessen über ein anderes Modul aufzurufen, kann auf dessen Schnittstellen zugegriffen werden. Das kann aus einem C++-Modul geschehen oder, wie im Folgenden gezeigt, aus der TwinCAT SPS.
Bei der Codegenerierung wird eine PLCopen-XML-Datei erzeugt. Sie finden diese Datei im Build-Verzeichnis <MODEL_DIRECTORY>\<MODEL_NAME>_tct und - wenn das Modul über den Publish-Step exportiert wurde - auch im Publish-Verzeichnis des Moduls. Die Datei enthält POUs, die den Aufruf eines Simulink-Objektes aus der SPS vereinfachen, indem sie das Handling der Interface-Pointer kapseln. Die POUs können über Import PLCopenXML im Kontextmenü eines SPS-Projektknotens importiert werden.
Die folgenden Beschreibungen gelten ab der Version 1.2.1216.0 des TE1400! |
Konfiguration in Simulink
In den Einstellungen unter Tc Advanced wird zunächst CallBy auf Module gestellt (kann auch im TwinCAT Engineering nachträglich geändert werden).
Ab TE1400 Version 1.2.1230 ist der Parameter Skip caller verification sichtbar.
Ab TE1400 Version 1.2.1216.0 finden Sie den Parameter PLC Function Block (TcCOM wrapper):
Hier kann zwischen folgenden Optionen gewählt werden:
Option | Beschreibung |
---|---|
None | Es wird keine PlcOpen-XML-Datei generiert |
Generic FB only | Es wird nur der für alle mit dem TE1400 generierten Module gültige Funktions-Baustein FB_TcMatSimObject (siehe auch hier) sowie davon verwendete Datentypen generiert. Der Datenaustausch erfolgt über generische Methoden. Der Anwender muss hierzu modulspezifische Daten, wie beispielsweise Byte-Größen, Parameter-Index-Offsets oder DataArea-IDs kennen. Versionshinweis: Bis einschließlich TE1400 1.2.1216.0 ist dieser generische FB nur sinnvoll nutzbar, wenn ein davon abgeleiteter FB implementiert wird, welcher die Initialisierung interner Variablen übernimmt. |
Module specific FB | Zusätzlich zum generischen FB_TcMatSimObject, werden der modulspezifische Baustein FB_<ModuleName> und zugehörige Datentypen erzeugt. Die Struktur der Ein- und Ausgangsvariablen entspricht genau der Struktur der zugehörigen DataAreas des Moduls. Zum Datenaustausch können daher die Ein- und Ausgangsvariablen direkt zugewiesen werden, ohne beispielsweise die Größe der DataAreas oder die DataArea-IDs explizit angeben zu müssen. |
Module specific FB with properties for all parameters | Der modulspezifische Baustein FB_<ModuleName> erhält zusätzliche Properties. Über diese Properties können Parameter des Moduls ausgelesen und ggf. geschrieben werden. Für jeden Modul-Parameter erhält der Baustein jeweils zwei Properties: „ParameterName_Startup“ und „ParameterName_Online“. |
Der modulspezifische Funktions-Baustein
FB_<ModuleName> ist abgeleitet von FB_TcMatSimObject, stellt also auch die oben beschriebenen Methoden und Properties zur Verfügung. Zusätzlich sind hier folgende Properties implementiert:
Public Properties:
Methode | Datentyp | Beschreibung |
---|---|---|
InitData | ST_<ModuleName>_InitData | Speichert die Startup-Werte der Modulparameter zur Initialisierung einer Modul-Instanz. Die Werte werden während der Zustandsübergänge des Moduls von INIT nach PREOP per SetObjState() an das Modul übertragen. Erforderlich bei dynamischer Instanziierung. |
<ParameterName>_Startup | <ParameterType> | Bei entsprechender Konfiguration des Coders für alle Parameter verfügbar. Erlaubt einen übersichtlicheren Zugriff auf das entsprechende Element der InitData-Struktur (lesend und schreibend). |
<ParameterName>_Online | HRESULT | Bei entsprechender Konfiguration des Coders für alle Parameter verfügbar. Liest oder schreibt Online-Werte des entsprechenden Modulparameters. |
Hinweise bezüglich FB with properties for all parameters
Wird unter Tc Interfaces im Bereich Parameter access der Punkt Process image auf Internal DataArea gesetzt, wird eine Property für die Gesamtheit aller Parameter angelegt. Diese müssen dann als Gesamtheit gelesen und geschrieben werden:
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;
Wird unter Tc Interfaces im Bereich Parameter access der Punkt Process image auf No DataArea gesetzt, wird für jeden Modelparameter eine eigene Property erzeugt. Diese können dann direkt ohne lokale PLC Variable gelesen und geschrieben werden.
Fb<ModelName>.ModelParameters_<ParameterName>_Online
Referenzieren einer statischen Modul-Instanz:
Der FB kann genutzt werden, um auf vorher im XAE z. B. unter System > TcCOM Objects angelegte Modulinstanzen zuzugreifen. Für diesen statischen Fall muss die Objekt-ID der entsprechenden Modulinstanz bei der Deklaration der FB-Instanz übergeben werden:
fbStatic : FB_<ModuleName>(oid:=<ObjectId>);
Die Objekt-ID finden Sie in der Instanz des TcCOM unter dem Reiter Object.
Bespielcode
Das folgende Code-Beispiel zeigt die Verwendung eines modulspezifischen Funktionsbausteins in einem einfachen SPS-Programm in ST-Code am Beispiel eines Objektes der Modulklasse „TempContr“ mit der ObjectID 0x01010010
:
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
Erzeugen und Referenzieren einer dynamischen Modul-Instanz:
Für den Fall <ObjectId> = 0, versucht der FB dynamisch eine Instanz des TcCom-Moduls zu erzeugen:
fbDynamic : FB_<ModuleName>(oid:=0);
In diesem Fall taucht die Modulinstanz nicht im Konfigurations-Baum des XAE auf, sondern erscheint erst zur Laufzeit (also nach der Initialisierung der SPS-Instanz) in der „Project Objects“-Tabelle des Knotens System > TcCOM Objects.
Voraussetzung für die dynamische Instanziierbarkeit eines TcCOM-Moduls ist, dass die zugehörige „Class Factory“ geladen ist. Dazu muss für die „Class Factory“ des Moduls unter dem Karteireiter Class Factories des Knotens System > TcCOM Objects die Checkbox Load (oder bei Verwendung des „TwinCAT Loaders“ die Checkbox TC Loader) gesetzt sein. Der Name der „Class Factory“ eines aus Simulink generierten TcCOM-Moduls ist in der Regel gleich dem Modulnamen, wobei der ClassFactory-Name allerdings auf weniger Zeichen begrenzt ist.
Weitere Voraussetzung für das dynamische Instanziieren eines Moduls ist die ausreichende Verfügbarkeit dynamischen Speichers. Dazu muss der ADS-Router-Speicher ausreichend groß gewählt sein.
Beispielcode:
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-Kontext-Einstellung
In den Kontexteinstellungen einer statischen Modulinstanz muss die SPS-Task konfiguriert sein, aus welcher der Aufruf erfolgt.
Einer dynamischen Modulinstanz muss die Objekt-ID der SPS-Task über die InitData-Struktur übermittelt werden. Falls vorhanden, kann das entsprechende InitData-Element über das Property „ContextInfoArr_<contextId>_TaskOid_Startup“ gesetzt werden.
Beim Aufruf des TcCOM Moduls wird eine Kontext-Verifikation durchgeführt und ein entsprechender Fehler ausgegeben, wenn der Kontext nicht korrekt ist. Diese Verifikation benötigt Zeit und wird bei jedem Call durchgeführt. Aus diesem Grund kann diese Verifikation über die Checkbox Skip caller verification im Tc Advanced Dialog, siehe Skip caller verification, deaktiviert werden.
Import mehrerer PLCopen-XML: FB_TcMatSimObject
Der generische Baustein FB_TcMatSimObject ist für alle mit dem TE1400 (ab V1.2.12016.0) generierten Module gleich. Auch bei der Verwendung für unterschiedliche Module muss er nur einmal in das SPS-Project importiert werden.
Beschreibung des Funktionsbausteins:
Public Methods
Methode | Rückgabe-Datentyp | Beschreibung |
---|---|---|
Execute | HRESULT | Kopiert die Daten der InputDataArea-Strukturen vom FB zur Modulinstanz (des Objektes), ruft die zyklischen Methoden des Objektes auf und kopiert die Daten aus den Output-DataAreas zurück in die zugehörigen Datenstrukturen des FB |
GetObjPara | HRESULT | Liest Parameter-Werte per PID (Parameter ID = ADS Index Offset) aus dem Objekt aus |
SetObjPara | HRESULT | Schreibt Parameter-Werte per PID (Parameter ID = ADS Index Offset) in das Objekt |
ResetHresult |
| Quittiert Fehlercodes, die bei der Initialisierung des FB oder beim Aufruf von „Execute()“ aufgetreten sind. |
SaveOnlineParametersForInit | HRESULT | Liest die aktuellen Online-Werte der Parameter aus dem Objekt und speichert sie in der Parameter-Struktur hinter der FB-Variablen pInitData, falls diese existiert |
SetObjState | HRESULT | Versucht den TCOM_STATE des Objektes schrittweise zum Sollzustand zu führen |
AssignClassId |
| Ab TE1400 1.2.1217.0: |
SetInitDataInfo |
| Ab TE1400 1.2.1217.0: |
SetDataAreaInfo |
| Ab TE1400 1.2.1217.0: |
Public Properties
Methode | Datentyp | Beschreibung |
---|---|---|
ClassId | CLSID | Gibt die ClassId des Moduls zurück |
Error | BOOL | Gibt TRUE zurück, wenn aktuell ein Fehler ansteht, der Quittiert werden muss |
ErrorCode | HRESULT | Gibt den aktuellen Fehlercode zurück |
State | TCOM_STATE | Gibt den aktuellen TCOM_STATE des Objektes zurück oder versucht ihn schrittweise zum Sollzustand zu führen |
Referenzierung einer Modul-Instanz
Auch FB_TcMatSimObject kann, genau wie der von ihm abgeleitete modulspezifische FB, mit der Objekt-ID einer statischen Modulinstanz oder mit 0 instanziiert werden:
fbStatic : FB_TcMatSimObject(oid:=<ObjectId>); // Referenz auf statisches TcCom-Objekt
fbDynamic : FB_TcMatSimObject(oid:=0); // Erzeugen eines dynamisches TcCom-Objektes