TwinCAT-Modul Eigenschaften

Ein TcCOM-Modul hat eine Reihe formal definierter, vorgeschriebener und optionaler Eigenschaften. Die Eigenschaften sind so weit formalisiert, dass eine Verwendung untereinander möglich ist. Jedes Modul hat eine Modulbeschreibung, die die Eigenschaften des Moduls beschreibt. Diese werden für eine Konfiguration der Module und deren Beziehungen untereinander verwendet.

Wenn ein Modul in der TwinCAT Runtime instanziiert wird, dann meldet es sich selber bei einer zentralen Systeminstanz, dem ObjectServer, an. Dadurch wird es für andere Module und auch für allgemeine Tools erreichbar und parametrierbar. Module können unabhängig voneinander kompiliert und demzufolge auch entwickelt, getestet und aktualisiert werden. Module können sehr einfach konzipiert sein, z.B. nur eine kleine Funktion wie einen Tiefpassfilter enthalten. Sie können aber auch intern sehr komplex sein und z.B. das gesamte Steuerungssystem einer Maschinenunterbaugruppe beinhalten.

Es gibt sehr viele Anwendungen für Module; alle Aufgaben eines Automatisierungssystems können in Module spezifiziert werden. Demzufolge wird nicht unterschieden, ob das Modul primär die Grundfunktionen eines Automatisierungssystems darstellt, wie Echtzeit-Tasks, Feldbus-Treiber oder ein SPS-Laufzeitsystem, oder eher benutzer- und anwendungsspezifische Algorithmen für die Steuerung oder Regelung einer Maschineneinheit.

Die Abbildung unten zeigt ein gewöhnliches TwinCAT-Modul mit seinen wichtigsten Eigenschaften. Die dunkelblauen Blöcke definieren vorgeschriebene, die hellblauen Blöcke optionale Eigenschaften.

Modulbeschreibung

Jedes TcCOM Modul hat einige allgemeine Beschreibungsparameter. Dazu gehört eine ClassID, die die Klasse des Moduls eindeutig referenziert. Sie wird durch die passende ClassFactory instanziiert. Jede Instanz eines Moduls hat eine ObjectID, die in der TwinCAT Runtime eindeutig ist. Darüber hinaus gibt es eine Parent-ObjectID, die auf einen möglichen logischen Parent verweist.

Modulbeschreibung, Zustandsmaschine und Parameter des unten beschriebenen Moduls können über die ITComObject-Schnittstelle erreicht werden (Siehe „Schnittstellen“).

Klassenbeschreibungsdateien (*.tmc)

Die Klassen der Module werden in den Klassenbeschreibungsdateien (TwinCAT Module Class; *.tmc) beschrieben.

In dieser Datei beschreibt der Entwickler Eigenschaften und Schnittstellen des Moduls, so dass andere es nutzen und einbetten können. Neben den allgemeinen Informationen (Herstellerangaben, Klassen-ID des Moduls, usw.) werden optionale Eigenschaften des Moduls beschrieben.

• unterstützte Kategorien
• implementierte Schnittstellen
• Datenbereiche mit entsprechenden Symbolen
• Parameter
• Schnittstellenzeiger
• Datenzeiger, die gesetzt werden können

Die Klassenbeschreibungsdateien werden vom Konfigurator des Systems in erster Linie als Grundlage für die Einbindung einer Instanz des Moduls in die Konfiguration, zum Festlegen der Parameter und zwecks Konfiguration der Verbindungen mit anderen Modulen verwendet.

Sie enthalten zudem die Beschreibung aller Datentypen in den Modulen, die dann vom Konfigurator in sein allgemeines Datentypsystem aufgenommen werden. Damit werden also alle Schnittstellen der im System vorhandenen TMC Beschreibungen für alle Module nutzbar.

Auch komplexere Konfigurationen mehrerer Module können in den Klassenbeschreibungsdateien beschrieben werden, die für eine spezifische Anwendung vorkonfiguriert und verbunden sind. Demzufolge kann ein Modul für eine komplexe Maschineneinheit, die intern aus einer Reihe von Untermodulen besteht, bereits im Verlauf der Entwicklungsphase als ein Ganzes definiert und vorkonfiguriert werden.

Instanzenbeschreibungsdateien (*.tmi)

Ein Instanz eines bestimmten Moduls wird in der Instanzenbeschreibungsdatei (TwinCAT Module Instance; *.tmi) beschrieben. Die Instanzbeschreibungen sind durch ein ähnliches Format beschrieben, enthalten entgegen den Klassenbeschreibungsdateien aber bereits konkrete Festlegungen der Parameter, Schnittstellenzeiger usw. für die besondere Instanz des Moduls innerhalb eines Projekts.

Die Instanzenbeschreibungsdateien werden vom TwinCAT Engineering (XAE) erstellt, wenn eine Instanz einer Klassenbeschreibung für ein konkretes Projekt erstellt wird. Sie dienen hauptsächlich dem Datenaustausch zwischen allen an der Konfiguration beteiligten Tools. Allerdings können die Instanzenbeschreibungen auch projektübergreifend genutzt werden, wenn z.B. ein besonders parametriertes Modul in einem neuen Projekt erneut verwendet werden soll.

Zustandsmaschine

Jedes Modul enthält eine Zustandsmaschine, die den Initialisierungszustand des Moduls und die Mittel, mit denen dieser Zustand von außen verändert werden kann, beschreibt. Diese Zustandsmaschine beschreibt die Zustände, die beim Starten und Beenden des Moduls durchlaufen werden. Dieses betrifft die Modulerzeugung, -parametrierung und Herstellung der Verbindung mit den anderen Modulen.

Anwendungsspezifische Zustände (z.B. von Feldbus oder Treiber) können in ihren eigenen Zustandsmaschinen beschrieben werden. Die Zustandsmaschine der TcCOM-Module definiert die Zustände INIT, PREOP, SAFEOP und OP. Auch wenn es dieselben Zustandsbezeichnungen sind wie unter EtherCAT-Feldbus sind es doch nicht die gleichen Zustände. Wenn das TcCOM-Modul einen Feldbustreiber für EtherCAT implementiert, hat es zwei Zustandsmaschinen (Modul- und Feldbuszustandsmaschine), die nacheinander durchlaufen werden. Die Modulzustandsmaschine muss den Betriebszustand (OP) erreicht haben, bevor die Feldbuszustandsmaschine überhaupt starten kann.

Die Zustandsmaschine ist im Detail separat beschrieben.

Parameter

Module können Parameter haben, die während der Initialisierung oder später während der Laufzeit (OP-Zustand) gelesen oder geschrieben werden können. Jeder Parameter ist durch eine Parameter-ID gekennzeichnet. Die Eindeutigkeit der Parameter-ID kann global, eingeschränkt global oder modulspezifisch sein. Mehr hierzu im Abschnitt „ID Management“. Neben der Parameter-ID enthält der Parameter die aktuellen Daten; der Datentyp hängt vom Parameter ab und ist für die jeweilige Parameter-ID eindeutig definiert.

Schnittstellen

Schnittstellen bestehen aus einem definierten Satz an Methoden (Funktionen), die Module anbieten und über die sie z.B. von anderen Modulen kontaktiert werden können. Schnittstellen sind durch eine eindeutige ID charakterisiert, wie oben beschrieben. Ein Modul muss mindestens die ITComObject-Schnittstelle unterstützen, kann aber daneben so viele Schnittstellen wie gewünscht beinhalten. Eine Schnittstellen-Referenz kann durch Aufruf der Methode „TcQueryInterface“ mit Angabe der entsprechenden Schnittstellen-ID abgefragt werden.

Schnittstellenzeiger

Schnittstellenzeiger verhalten sich wie das Gegenstück von Schnittstellen. Wenn ein Modul eine Schnittstelle eines anderen Moduls nutzen möchte, muss es einen Schnittstellenzeiger des entsprechenden Schnittstellentyps haben und dafür sorgen, dass dieser auf das andere Modul zeigt. Danach können die Methoden des anderen Moduls verwendet werden.

Schnittstellenzeiger werden normalerweise beim Start der Zustandsmaschine gesetzt. Beim Übergang von INIT zu PREOP (IP) empfängt das Modul die Objekt-ID des anderen Moduls mit der entsprechenden Schnittstelle, beim Übergang PREOP zu SAFEOP (PS) oder SAFEOP zu OP (SO) wird die Instanz des anderen Moduls mit dem ObjectServer durchsucht und die entsprechende Schnittstelle mit der Methode Query Interface gesetzt. Beim Zustandsübergang in die entgegengesetzte Richtung, von SAFEOP zu PREOP (SP) oder OP zu SAFEOP (OS) muss die Schnittstelle wieder freigegeben werden.

Datenbereiche

Module können Datenbereiche enthalten, die von der Umgebung verwendet werden können (z.B. von anderen Modulen oder zum IO Bereich von TwinCAT). Diese Datenbereiche können beliebige Daten enthalten. Sie werden oft für Prozessabbilddaten (Ein- und Ausgänge) genutzt. Die Struktur der Datenbereiche wird in der Gerätebeschreibung des Moduls definiert. Wenn ein Modul Datenbereiche hat, die es für andere zugänglich machen möchte, implementiert es die ITcADI-Schnittstelle, die den Zugriff auf die Daten ermöglicht. Datenbereiche können Symbolinformationen enthalten, die die Struktur des jeweiligen Datenbereichs im Einzelnen beschreiben.

Datenbereichszeiger

Wenn ein Modul auf den Datenbereich anderer Module zugreifen möchte, kann es Datenbereichszeiger enthalten. Diese werden normalerweise während der Initialisierung der Zustandsmaschine auf Datenbereiche oder Datenbereichsabschnitte anderer Module gesetzt. Es handelt sich dabei um einen direkten Zugriff auf den Speicherbereich, so dass bei Bedarf entsprechende Schutzmechanismen für konkurrierende Zugriffe eingesetzt werden müssen. Häufig bietet sich deshalb besser an, eine entsprechende Schnittstelle zu nutzen.

Kontext

In diesem Zusammenhang ist Kontext als Echtzeit-Task Kontext zu verstehen. Kontexte werden u.a. für die Konfiguration der Module benötigt. Einfache Module arbeiten normalerweise in einem einzigen Zeitkontext, demzufolge muss er nicht näher spezifiziert werden. Andere Module können teilweise in mehreren Kontexten aktiv sein (z.B. ein EtherCAT Master kann mehrere unabhängige Echtzeit Tasks unterstützten, oder eine Regelschleife kann Regelschleifen der darunterliegenden Ebene in anderer Zykluszeit abarbeiten). Wenn ein Modul mehr als einen zeitabhängigen Kontext hat, muss das in der Modulbeschreibung angegeben werden.

Kategorien

Module können Kategorien anbieten indem sie das Interface ITComObjectCategory implementieren. Kategorien werden vom ObjectServer enumeriert und Objekte, die sich hierrüber Kategorien zuordnen, können durch den ObjectServer (ITComObjectEnumPtr) abgefragt werden.

ADS

Jedes Modul, das beim ObjectServer eingetragen ist, kann per ADS erreicht werden. Der ObjectServer nutzt dabei die ITComObject Schnittstelle der Module, um z.B. Parameter zu lesen oder zu schreiben oder auch um auf die Zustandsmaschine zuzugreifen. Es gibt zusätzlich die Möglichkeit der Implementierung eines eigenes ADS Ports, über den eigene ADS Kommandos empfangen werden können.

Systemmodul

Die TwinCAT Laufzeit stellt darüber hinaus eine Reihe sogenannter Systemmodule zur Verfügung, die die grundlegenden Dienste der Laufzeit für andere Module zur Verfügung stellen. Diese Systemmodule haben eine feste, konstante ObjectID, über welche die anderen Module auf sie zugreifen können. Ein Beispiel eines solchen Systemmoduls ist das Echtzeitsystem, das die grundlegenden Dienste des Echtzeitsystems, d.h. die Generierung von Echtzeit-Tasks, via ITcRTime-Schnittstelle zur Verfügung stellt. Auch der ADS Router ist als Systemmodul implementiert, so dass andere Module an dieser Stelle ihren ADS Port anmelden können.

Erstellung von Modulen

Module können sowohl in C++ als auch in IEC 61131-3 erstellt werden. Die objektorientierten Erweiterungen der TwinCAT PLC werden hierzu verwendet. Module aus den beiden Welten können über Schnittstellen auf die gleiche Weise wie reine C++ Module untereinander interagieren. Mit Hilfe der objektorientierten Erweiterung werden die gleichen Schnittstellen bereitgestellt wie in C++.

Die SPS-Module melden sich ebenfalls selber beim ObjectServer an und sind demzufolge über ihn erreichbar. Die Komplexität von SPS-Modulen ist unterschiedlich. Es macht keinen Unterschied, ob nur ein kleines Filtermodul generiert oder ein komplettes SPS-Programm in ein Modul hineingepackt wird. Jedes SPS-Programm ist aufgrund der Automation ein Modul im Sinne der TwinCAT-Module. Jedes klassische SPS-Programm wird automatisch in ein Modul gepackt und meldet sich selber beim ObjectServer und bei einem oder mehreren Task-Modulen an. Der Zugriff auf die Prozessdaten eines SPS-Moduls (z.B. Mapping in Bezug auf einen Feldbus-Treiber) wird ebenfalls über die definierten Datenbereiche und ITcADI gesteuert.

Dieses Verhalten bleibt transparent und unsichtbar für den SPS-Programmierer, so lange bis er beschließt ausdrücklich Teile des SPS-Programms als TwinCAT-Module zu definieren, damit er diese mit geeigneter Flexibilität nutzen kann.