Erweiterte Einstellungen (Tc Advanced)
In den erweiterten Einstellungen lassen sich Parameter einstellen, die zum einen das Ausführungs- und Aufrufverhalten des Moduls und zum anderen die Darstellungen und Eigenschaften des exportierten Blockdiagramms beeinflussen:
Ausführungsverhalten des generierten Moduls
In TwinCAT 3 kann ein Simulink-Modul direkt von einer zyklischen Echtzeit-Task oder von einem anderen TwinCAT-Modul, z. B. einer SPS, aufgerufen werden. Das Verhalten der generierten Modul-Klasse kann in Simulink unter Tc Advanced parametriert werden. Um das Verhalten der einzelnen Modulinstanzen ggf. abweichend vom Verhalten der Klasse festzulegen, kann die Art der Ausführung in der TwinCAT 3-Entwicklungsumgebung über die TcCOM-Parameterliste im Karteireiter Parameter (Init) oder über den Parameterbereich im Blockdiagramm angepasst werden.
Konfiguration der Standardeinstellungen in Simulink
Die Standardwerte der Aufruf-Parameter können in den Simulink-Codereinstellungen konfiguriert werden, um den Aufwand für die Parametrierung der einzelnen Objekte (Modulinstanzen) zu verringern:
Task Zuweisung
Unter Task assignment kann die Zuweisungsart einer Task in TwinCAT definiert werden.
Einstellung "Depend On" | Beschreibung |
|---|---|
Manual Config | Die Tasks können in der Kontexttabelle manuell zugewiesen werden, indem in der Spalte "Task" die Objekt-IDs der Tasks ausgewählt oder eingetragen werden. Die ausgewählten Tasks müssen alle Kriterien erfüllen, die über die "Aufruf-Parameter" konfiguriert wurden. |
Parent Object | Kann nur verwendet werden, wenn der Eltern-Knoten der Modulinstanz im Projektbaum eine Task ist. In diesem Fall dient das Parent-Object als zyklischer Aufrufer des Moduls. |
Task Properties | Die Tasks werden dem Modul automatisch zugewiesen, wenn Zykluszeit und Priorität den in Simulink festgelegten Werten entsprechen. Gibt es keine entsprechende Task, können unter dem Knoten "System Configuration -> Task Management" neue Tasks erstellt und entsprechend parametriert werden. |
Ist die Option Task properties aktiv, ist die Priorität der entsprechenden Task anzugeben.
Zyklischer Aufruf
Wurde für den Aufruf-Parameter "CallBy" der Wert "CyclicTask" gesetzt, erfolgt beim Start des Moduls eine Verifizierung aller Task-Zykluszeiten. Über den Aufruf-Parameter "Step size" können die Bedingungen der Zykluszeiten der zugeordneten Tasks festgelegt werden. Erfüllen alle Zykluszeiten ihre Bedingungen, kann das Modul starten. Anderenfalls bricht der Start des Moduls und der TwinCAT-Laufzeit mit entsprechenden Fehlermeldungen ab.
Aufruf aus einem anderen TwinCAT-Modul
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 aus einer TwinCAT SPS, wie in „Aufruf des generierten Moduls aus einem SPS-Projekt“ gezeigt.
Ausführungsreihenfolge
In Modulen, die mit TE1400 ab Version 1.1 erstellt wurden, kann eine Ausführungsreihenfolge festgelegt werden, um Jitter und Reaktionszeiten für die jeweilige Anwendung zu optimieren. Ältere Versionen verwenden immer die Reihenfolge "StateUpdateAfterOutputMapping". Die folgende Tabelle veranschaulicht die Vor- und Nachteile der unterstützten Aufrufreihenfolgen:
- IoAtTaskBegin
- Längste Reaktionszeit aller Optionen
+ Kleinstmöglicher Jitter in der Reaktionszeit - StateUpdateAfterOutputMapping
+ Kürzeste Reaktionszeit
o Mittlerer Jitter in der Reaktionszeit
 | Ergebnisse aus „Minor Time Steps“ werden per ADS übermittelt Per ADS übermittelte Signalwerte können von den Werten abweichen, die via „Output mapping“ auf andere Prozessabbilder kopiert wurden. Grund hierfür ist, dass bei „State update“ je nach gewähltem Solver Werte überschrieben werden können. Siehe Übermittlung der Ergebnisse aus „Minor Time Steps“ für weitere Informationen. |
- StateUpdateBeforeOutputUpdate
o Mittlere Reaktionszeit
- größter Jitter in der Reaktionszeit, da abhängig von Ausführungszeiten für „State update“ und „Output update“
Schrittweiteneinstellung (Step size)
Hier wird das Verhalten des generierten TcCOM bezüglich der Schrittweite (in TwinCAT entsprechend die Cycle Time) definiert.
- RequireMatchingTaskCycleTime
Das Modul erwartet als Zykluszeit der zugeordneten Task die in Simulink festgelegte "Fixed Step Size". Wird eine andere Zykluszeit eingestellt, wird die Startsequenz des TcCOM mit einer Fehlermeldung abgebrochen. Multitasking-Module erwarten, dass alle zugewiesenen Tasks mit den zugehörigen Simulink-Sampletimes konfiguriert wurden. - UseTaskCycleTime
Das Modul erlaubt Zykluszeiten, die von der in Simulink festgelegten "Fixed Step Size" abweichen. Bei Multitasking-Modulen müssen alle Task-Zykluszeiten das gleiche Verhältnis zur zugehörigen Simulink-Sampletime aufweisen. Bei abweichender Zykluszeit von der Simulink-Sampletime wird eine Warnung in TwinCAT ausgegeben, welche auf die Abweichung hinweist. - UseModelStepSize
Das Modul verwendet für alle internen Berechnungen die in Simulink eingestellte Sampletime. Diese Einstellung ist vornehmlich für die Verwendung in Simulationen innerhalb der TwinCAT-Umgebung gedacht und kann zur beschleunigten oder auch verlangsamten Simulation eingesetzt werden.
Auto start cyclic execution
Ist diese Option aktiviert (default), wird das Tc-COM Modul beim Aufstarten in den OP-State gesetzt und der generierte Modellcode direkt ausgeführt. Ist diese Option deaktiviert, wird das Modul ebenfalls in den OP-State versetzt, jedoch wird der Modellcode nicht abgearbeitet. Diese Option ist im instanziierten Modul im Karteireiter Parameter (init) und im Parameterbereich des Blockdiagrams unter Module parameters als Variable „ExecuteModelCode“ zu finden und kann hier ebenfalls angepasst werden.
Anpassung der Darstellung, Debugging und Parametrierbarkeit
Aus Simulink erzeugte Module erlauben auch nach der Codegenerierung und Instanziierung noch weitreichende Möglichkeiten zur Parametrierung der Modul- und Modellparameter. Die Parametrierungsmöglichkeiten können vor der Codegenerierung angepasst werden, so dass z. B. in der Entwicklungsphase Debug-Möglichkeiten erlaubt und auch Parameter maskierte Subsysteme aufgelöst werden, welche in einer Release Version versteckt werden sollen. Die Nutzung von Modulen in TwinCAT 3 setzt eine entsprechend der Anforderungen konfigurierbare Darstellung voraus. So können z. B. Debug-Informationen im Blockdiagramm mit exportiert werden.
Die folgenden Coder-Parameter erlauben die Anpassung des Blockdiagramm-Exports, der Parameter- und Signaldarstellung sowie erweiterter Funktionen:
Parameter | Beschreibung | Defaultwert | |
|---|---|---|---|
Monitoring execution times | TRUE | Die Ausführungszeiten des TC-Moduls werden berechnet und zur Überwachung als ADS-Variable bereitgestellt. | FALSE |
FALSE | Berechnung der Ausführungszeiten deaktiviert. | ||
Export block diagram | TRUE | Das Simulink-Blockdiagramm wird exportiert und nach der Instanziierung des Moduls in XAE unter dessen Karteireiter "Block Diagram" angezeigt. | TRUE |
FALSE | Das Simulink-Blockdiagramm wird nicht exportiert und der Karteireiter "Block Diagram" wird in XAE nicht angezeigt. | ||
Resolve masked Subsystems | Nur relevant, wenn "Export block diagram"=TRUE. | FALSE | |
TRUE | Maskierte Subsysteme werden aufgelöst. Alle Inhalte maskierter Subsysteme sind für Benutzer des generierten Moduls in XAE sichtbar. | ||
FALSE | Maskierte Subsysteme werden nicht aufgelöst. Die Inhalte der maskierten Subsysteme sind für Benutzer des generierten Moduls unsichtbar. | ||
Access to VariableGroup, not referenced by any block | Assign to parent block | Variablen dieser Gruppe, die zu einem Block innerhalb eines nicht aufgelösten Subsystems gehören, werden dem nächsthöheren, sichtbaren Subsystem zugeordnet. |
|
Hide in block diagram | Variablen dieser Gruppe, die keinem Simulink-Block zugeordnet werden können, werden im Blockdiagramm nicht angezeigt. | ||
Hide, No access | Variablen dieser Gruppe, die keinem Simulink-Block zugeordnet werden können, werden versteckt und unzugänglich gemacht. Dies ist nur möglich, wenn für das Prozessabbild dieser Variablen-Gruppe „No DataArea“ ausgewählt wurde (Konfiguration in Simulink). | ||
Export block diagram debug information | TRUE | Debug-Informationen zum Blockdiagramm werden generiert, die eine Zuordnung von Zeilennummern im genierten Code zu dargestellten Blöcken erlauben. Wird für das Debuggen benötigt. | TRUE |
FALSE | Keine Debug-Informationen werden generiert | ||
Show parameters table in XAE | TRUE | Der Karteireiter "Parameter (Init)" wird in XAE angezeigt und erlaubt die Parametrierung des Moduls über die Parameterliste. | TRUE |
FALSE | Der Karteireiter "Parameter (Init)“ wird in XAE nicht angezeigt. | ||
Use original input and output block names | FALSE | Ein- und Ausgänge des Moduls tragen den Namen, der vom Simulink Coder als Variablenname angelegt wurde. Leer- und Sonderzeichen sind dort nicht erlaubt. | FALSE |
TRUE | Ein- und Ausgänge des Moduls tragen genau den Namen, der im Simulink Modell verwendet wurde. Die Namen können Leer- und Sonderzeichen enthalten. | ||
Set testpoints at Simulink Scope signals before code generation |
| Scope-Blöcke werden vom Simulink-Coder ignoriert, d. h. die Signale stehen im Allgemeinen im generierten TwinCAT-Modul nicht zur Verfügung und können nicht angezeigt werden. Um die Generierung von Variablen für diese Signale zu erzwingen, können im Simulink-Modell „Testpoints“ definiert werden. Dieser Parameter kann genutzt werden, um automatisiert „Testpoints“ für alle Scope-Eingangssignale zu erstellen. |
|
Maximum number of visible array elements |
| Gibt die maximale Anzahl der in der TwinCAT-Entwicklungsumgebung darzustellenden Array-Elemente an. Größere Arrays können nicht aufgeklappt und die Elemente z. B. nicht einzeln verknüpft werden. |
|
Hide Datatypes defined in TMC
In jeder TMC-Datei werden die benötigten Datentypen spezifiziert und durch Import in TwinCAT 3 im System bekannt gemacht. Den Datentypen wird dabei eine eindeutige GUID zugeordnet. Entsprechend bleibt die GUID unverändert, wenn eine TMC-Datei neu importiert wird, bei der sich ein Datentyp nicht verändert hat. Bei der Verwendung von z. B. Enums oder Strukturen, kann durch Veränderungen (z. B. zusätzlicher Modellparameter in einer Struktur) der Fall auftreten, dass der Datentypname des veränderten Datentyps und der des vorherigen Datentyps identisch sind, jedoch unterschiedliche GUIDs haben. Diese eindeutige Zuordnung über GUIDs existiert in der PLC nicht, sondern hier wird über den Datentypnamen identifiziert. Bei Aufruf einer TcCOM Instanz aus der PLC heraus ist entsprechend ein Mechanismus vorzuhalten, der Mehrdeutigkeiten vorbeugt.
Über den Punkt Hide Data Types defined in TMC wird die zuletzt importierte TMC bzw. deren Datentypnamen und Datentypen für die PLC verwendet. Bereits existierende Datentypnamen mit anderen Datentypen werden für die PLC versteckt. Siehe dazu auch Wie löse ich Datentyp-Konflikte im SPS-Projekt?.
Skip caller verification
Diese Option deaktiviert Abfragen bei dem Aufruf eines TcCOM aus der SPS, siehe Aufruf des generierten Moduls aus einem SPS-Projekt. Dies führt zu einer schnelleren Abarbeitung des Modulaufrufs, auf der anderen Seite muss dann vom Anwender zwingend sichergestellt sein, dass der Aufruf korrekt und aus dem richtigen Kontext heraus erfolgt.
Diese Option sollte erst dann aktiviert werden, wenn es aus Performanz-Gründen notwendig ist und unter zuvor das Projekt mit aktivierten Abfragen entsprechend getestet wurde.
PLC Function Block
Der POU-Typus zum Aufruf eines Simulink-Objektes aus der SPS kann hier näher definiert werden. Eine ausführliche Beschreibung ist unter „Aufruf des generierten Moduls aus einem SPS-Projekt“ zu finden.
OEM Lizenzcheck
Optional kann ein generiertes TcCOM an eine OEM-Lizenz gebunden werden. Diese OEM-Lizenz wird beim Starten des TcCOM (neben der Beckhoff Runtime-Lizenz TC1220 oder TC1320) in TwinCAT 3 überprüft. Ist keine gültige Lizenz vorhanden startet das Modul nicht auf und es erscheint eine entsprechende Fehlermeldung.
Wie Sie OEM Zertifikate erstellen und diese dann verwalten finden Sie beschrieben unter TwinCAT3 > TE1000 XAE > Technologien > Security Management.
In Simulink können Sie den OEM Lizenzcheck einfügen über Benennung Ihrer OEM ID und Ihrer abzufragenden Lizenz ID bzw. mehrerer Lizenz IDs. Ihre OEM ID finden Sie in der Security Management Konsole (Extended Info aktiviert), die Lizenz ID können Sie einsehen durch Doppelklick auf den entsprechenden Lizenzeintrag in TwinCAT unter System > License. Beide IDs sind ebenfalls im generierten License Request File enthalten, wenn ein Request File mit Ihrer OEM Lizenz generiert wird.
| GUID Form beachten Die einzutragenden IDs sind als String in GUID-Form zu übergeben, d.h. in Simulink sind die Angaben in Hochkommata zu setzen. Ebenfalls sind keine Leerzeichen in den Angaben erlaubt. |
Beispieleintrag:
OEM ID: '{B0D1D1B7-99AB-681G-F452-F4B3F1A993C0}'
License ID: 'Name1,{6B4BD993-B7C3-4B72-B3D1-681FE7DDF3D1}'