Technische Einführung
Der TwinCAT 3 EventLogger überträgt sogenannte Ereignisse (engl. Events). Ein Ereignis ist dabei eine Nachricht oder ein Alarm.
Diese technische Einführung fokussiert die Daten, die als Inhalt eines Ereignisses übertragen werden, denn diese sind für das Verständnis des Ablaufs nötig. In den API-Beschreibungen für SPS und C++ sowie in den Beispielen wird das Senden und Empfangen eines Ereignisses detailliert erläutert.
Ereignisse
Ein Ereignis selbst wird nicht direkt verwendet, sondern die abgeleiteten Typen „Nachrichten“ oder „Alarme“.
Ein Ereignis stellt die folgenden gemeinsamen Elemente von Nachrichten und Alarmen bereit:
EventClass (GUID) | Ereignisklassen sind eine Gruppierung von Events (möglicherweise zu einem Thema). |
Event-ID (UDINT) | Innerhalb einer Eventklasse identifiziert eine Event-ID das Ereignis eindeutig. |
Text (String) | Beschreibung des Ereignisses. Die Beschreibung ist für Menschen gedacht und kann somit auch internationalisiert werden. Zur Laufzeit können Argumente eingefügt werden, um den Text individuell anpassbar zu machen. |
Source Info | Quelle des Auftretens eines Ereignisses. Source besteht dabei aus drei Elementen. Diese können beliebig genutzt werden; es gibt aber eine entsprechende Empfehlung, wie sie zu verwenden sind.
|
JSON Attribute (STRING) | Kann beliebig verwendet werden. Während der „Text“ (siehe oben) für Menschen als Empfänger gedacht ist, ist das JSON-Attribut für den pogrammatischen Empfang vorgesehen. Ein JSON-String kann einfach erzeugt (serialisiert) und auch verarbeitet (deserialisiert) werden. TwinCAT bietet hierfür die JsonXml-Bibliothek in der Echtzeit an (siehe Dokumentation SPS-Bibliothek Tc3_JsonXml). |
Neben diesen Elementen besitzen Ereignisse weitere Elemente, die im TMC Editor beschrieben sind.
Nachrichten
Nachrichten sind zustandslos. Sie werden bei einem Aufruf gesendet und den entsprechend registrierten Komponenten zugestellt.
Identifikation
Nachrichten werden anhand der EventClass und Event-ID identifiziert.
Alarm
Ein Alarm ist im Gegensatz zu einer Nachricht nicht zustandslos.
Er besitzt folgende Alarmzustände:
- Not-Raised
- Raised
Zusätzlich kann eine Bestätigung verlangt werden. Folgende Bestätigungszustände werden unterschieden:
- WaitForConfirmation
- Confirmed oder Reset
Ein Aufruf der entsprechenden Methoden versendet ein Ereignis und überführt den Alarm in den entsprechenden Zustand.
- Wird eine Quittierung über Confirm() vorgenommen, wird der Zustand in Confirmed überführt.
- Wird eine Quittierung über Clear(TRUE) vorgenommen, wird der Zustand in Reset überführt.
Ist der Aufruf einer Methode im aktuellen Zustand nicht gültig, wird dies durch einen Rückgabewert angezeigt.
Beim Herunterfahren von TwinCAT (Übergang RUN → CONFIG) wird für alle Alarme im Zustand Raised intern ein Dispose ausgeführt, das einen Clear-Zeitstempel setzt. Eine Bestätigung für diese Alarme entfällt.
Identifikation
Der TwinCAT 3 EventLogger identifiziert einen Alarm anhand der EventClass, Event-ID und Source Info. Damit kann ein Alarm (Kombination aus EventClass und Event-ID) an unterschiedlichen Stellen im Programm verwendet werden. Beispielsweise kann ein Alarm „Lager leer“ für unterschiedliche Lager verwendet werden, da unterschiedliche „Source Infos“ zur Laufzeit bereitgestellt werden (siehe auch Umgang mit Quellen).
Architektur
Der TwinCAT 3 EventLogger überträgt Ereignisse zentral zwischen anderen Komponenten. Zu den Komponenten gehören die Echtzeit-Programmierschnittstellen SPS oder C++ als primäre Quelle von Ereignissen.
Während der Entwicklung können die Nachrichten im TwinCAT Engineering (XAE) angezeigt werden.
Ein HMI kann Nachrichten beispielsweise empfangen und entsprechend anzeigen. Weitere Komponenten können durch den Kunden selbst erstellt werden, um Ereignisse zu empfangen.
Der TwinCAT 3 EventLogger hält dabei eine begrenzte Anzahl der letzten Ereignisse in einem Cache. Dieser kann z. B. nach einem Neustart aus dem Engineering heraus abgefragt werden und so eine Diagnose ermöglichen. Der Cache hängt vom gesicherten Herunterfahren des Rechners ab.
 | Cache unter Windows CE nicht persistent Ab TwinCAT 3.1 Build 4024.25 wird der Cache der Ereignisse unter Windows CE Systemen aus Performancegründen nicht persistiert. |
Workflow
Der allgemeine Workflow zum Aufbau einer asynchronen Kommunikation zwischen Komponenten sieht wie folgt aus:
- Erstellung eines neuen TwinCAT-Projekts.
- Definition von Eventklassen und Events im TwinCAT-Typsystem.
- Ausführung der automatischen Code-Generierung, um den Quellcode für die Echtzeit-Programmiersprachen in TwinCAT bereitzustellen.
- Implementierung der Verwendung und somit des Sendens und Empfangens von Ereignissen.
Siehe auch: