EtherCAT Master in TwinCAT

Der EtherCAT Master als virtuelles Software Gerät

EtherCAT als Ethernet-basierender Echtzeit-Feldbus ist zur Verbindung mit der I/O-Umgebung auf eine physikalische Ethernet-Schnittstelle an der Steuerung und einen Echtzeit-Trigger nach Anforderung angewiesen. Dadurch kann der EtherCAT Master mit dem angeschlossenen EtherCAT Umfeld kommunizieren.

Der EtherCAT Master als Software-Gerät in TwinCAT

• kann aus den angelieferten Prozessdaten der PLC/NC/Task die Ethernet-Telegramme mit den EtherCAT-Datagrammen zusammensetzen und über den zugewiesenen Ethernet Port verschicken.
• kann aus dem I/O-Umfeld empfangene Prozessdaten entpacken und wieder an die Tasks zurückreichen.
• kümmert sich um die Konstruktion von zyklischen und azyklischen Telegrammen.
• regelt die Distributed-Clocks-Synchronisation.
• wertet die Diagnose-Informationen der EtherCAT Slaves aus.
• führt anlassbezogene Diagnose durch oder reagiert auf veränderte Topologien.
• kann nur ein EtherCAT-System mit bis zu 65535 Slaves verwalten und wird dazu mit einer Ethernet-Schnittstelle ("RJ45 Port") verlinkt. Zum Zwecke der Kabelredundanz kann dem EtherCAT-Master noch ein zweiter Port zugeteilt werden.
• verwaltet die Kommunikation mit anderen EtherCAT Mastern im gleichen TwinCAT-System, falls mehrere in der Konfiguration angelegt werden.
• ist der alleinige Erzeuger von EtherCAT-Telegrammen in einem EtherCAT System.
• ....

EtherCAT Kommunikation besteht aus zyklischen und azyklischen Ethernet-Telegrammen.

Die zyklischen bilden die normalen Prozessdaten ab und sind zur Anlagenlaufzeit üblicherweise nicht veränderlich. Aus der bekannten Konfiguration, d.h. der Menge der angeschlossenen EtherCAT Slaves, ergibt sich immer der gleiche Mindestumfang an Prozessdaten, die zur zyklischen Kommunikation der Teilnehmer mit dem Master verschickt werden müssen. Die zyklisch (also in konstantem Abstand) ausgeführte triggernde Task, z. B. ein PLC-Task mit 10 ms Laufzeit) stößt die Kommunikation mit dem EtherCAT-Feld an und erhält nach Abschluss der Kommunikation die Prozessdaten vom EtherCAT Master zurückgeliefert. TwinCAT arbeitet auf IPC/Embedded-Systemen üblicherweise mit konstanten Zykluszeiten von z. B. 50 µs ... > 100 ms. Innerhalb dieser Zykluszeit müssen die Rechenoperationen der Task abgeschlossen sein. Die hohe Kommunikationsleistung von EtherCAT (hoher 100 MBit/S Datendurchsatz) ermöglicht es auch in großen Konfiguration von > 1000 Teilnehmern, dass die versandten EtherCAT Telegramme schon vor Beginn des nächsten Zyklus wieder in der Steuerung angelangt sind. Deshalb ist die Taskausführung und die Buskommunikation als synchrone Aufgabe in TwinCAT angelegt. Für die hochqualitative Ausführung entscheidend ist dabei ein geringer Jitter, d.h. die Tasks sollen mit hoher zeitlicher Präzision ausgeführt bzw. wiederholt gestartet werden.

In Abb. Synchrone Ausführung von Task und EtherCAT Kommunikation erfolgt der Start der Kommunikation nach der Task. Auch eine Frame-Versendung gleichzeitig zum Task-Startzeitpunkt ist möglich ("I/O at task begin").

Die azyklischen Telegramme werden vom EtherCAT Master nach Erfordernis erstellt und in den Pausen zwischen den zyklischen Daten versendet bzw. empfangen. Mit diesen Telegrammen werden Diagnoseinformationen eingeholt, Mailbox-Kommunikation zu einzelnen Teilnehmern transportiert z. B. zum Firmware-Update oder zu einem unterlagerten Feldbus. Die azyklischen Telegramme werden ohne Echtzeitanspruch in der Reihenfolge ihrer Anforderung je nach verfügbarem Platz aus einer Pipeline versendet und werden daher auch "queued frames" (aneinandergereihte Frames) genannt.

Auch der TwinCAT System Manager bildet diese Zeitverhältnisse in jeder erstellten Konfiguration ab. In Abb. Konfigurationsabhängige Zeitaufteilung im System Manager ist die eine 100 µs-Task zu sehen, die mit ca. 20 Slaves kommuniziert und dazu einen Ethernet-Frame (rot) mit mehreren Datagrammen zur zyklischen Kommunikation benötigt.

Die Echtzeitumgebung

Der EtherCAT Master selbst regelt "nur" den Aufbau und die Interpretation der EtherCAT Telegramme. Eine TwinCAT-basierende Steuerung stützt sich auf wiederholte zyklische Ausführung einer Task mit konstanter Wiederholrate, der so genannten Zykluszeit. Üblich im TwinCAT Umfeld sind Zykluszeiten von 50 µs über 1 ms bis zu mehreren 100 ms. Die Zykluszeit wird bei der Konfigurationserstellung gewählt in Abhängigkeit von der Rechenleistung der verwendeten Steuerung, den Busteilnehmern, den ausgeführten Programmen, den applikativen Anforderungen u.a.

Als Task wird dabei jede zyklisch auszuführende Aufgabe bezeichnet, z. B.: NC-Berechnungen, PLC-Code, eine Visualisierung oder vom Kunden erstellte und angetriggerte R3-Applikationen. Die Tasks können unterschiedliche Zykluszeiten besitzen, müssen aber in einer Priorität gewichtet sein. Höherpriore Tasks können den Ablauf von niederprioren Taks unterbrechen und damit pausieren lassen. Die niederpriore Task wird fortgesetzt, sobald die Prioritätsliste dies erlaubt. Werden mehr als ein CPU-Core genutzt (erst mit TwinCAT 3 möglich), können auch mehrere Tasks parallel ausgeführt werden.

In einem korrekt dimensionierten und parametrierten TwinCAT System können alle angelegten Tasks auch bei unterschiedlichen Prioritäten in der vorgesehenen Zykluszeit einmal je Gesamtzyklus durchgeführt werden. Die automatischen Einstellungen des System Manager bei Konfigurationserstellung gewährleisten in der Regel einen stabilen Betrieb der Konfiguration. Als Gesamtzyklus wird hier die langsamste Task bezeichnet. Z. B. muss bei einer 1 ms und einer auf dem gleichen System befindlichen 100 ms Task die schnelle Task 100-mal ausgeführt werden, bis die langsame Task einmal ausgeführt wird.

Die Echtzeiteigenschaften von TwinCAT auf Windows-basierenden Systemen (2000, NT, XP, 7, CE; WES, WEC) gewährleisten auch ohne dezidierte Timing-Hardware einen geringen Jitter und damit hohe Konstanz und exaktes Timing auch bei kürzesten Zykluszeiten von 50 µs.

Prinzipiell kann jede Task ihr eigenes I/O-Abbild haben und so einen eigenen Feldbus-Zyklus mit den Teilnehmern führen. In Abb. 2 Tasks mit eigenen Ethernet-Frames (Task 1 ms: „roter“ Frame, Task 10 ms: „gelber“ Frame) sind 2 Tasks (1 + 10 ms) zusehen die jeweils eigene I/O-Zyklen auslösen und damit eigene Ethernet-Frames bewirken.

Die Ethernet Schnittstelle

EtherCAT ist aktuell (2011) auf ISO/OSI Layer 2 mit FastEthernet = 100 MBit/s bis in die Slave-Ebene standardisiert. Die Schnittstelle muss also mindestens FastEthernet unterstützen. Siehe dazu auch Hinweise zur EtherCAT Infrastruktur.

Die dem EtherCAT Master zugeteilte Ethernet Schnittstelle muss im Weiteren den Ansprüchen der Applikation genügen:

• äußere Anforderungen: Temperatur, Vibration, Ausziehschutz, Knickschutz, Verschmutzung.
• Als Verbindung zur Steuerung/IPC kommt üblicherweise ein RJ45, M12 oder M8-Übergang zum Einsatz.
• Echtzeitfähigkeit
  Die Ethernet Schnittstelle muss in ihren zeitkritischen Eigenschaften den Ansprüchen der Applikation gerecht werden und sollte zeitrichitg versandte Telegramme des EtherCAT Masters nicht verzögern. Dies betrifft die Software-Implementierung (Treiber, Stack-Verwaltung) wie die elektronische Ausführung (PCI- oder USB-Anbindung, DMA, NDIS-Verwaltung, vorgeschalteter Switch).

EtherCAT Slaves

Bei der Zusammenstellung der Konfiguration sind einige Faktoren zu beachten:

• Die Eigenschaften eines EtherCAT Slaves werden für den EtherCAT Master in der Gerätebeschreibungsdatei ESI (EtherCAT Slave Information) definiert. Diese XML-Datei ist vom jeweiligen Gerätehersteller bereitzustellen.
  Der TwinCAT System Manager sucht diese ESI-Dateien standardmäßig unter C:\TwinCAT\IO.
  Eine ESI-Datei kann mehrere Gerätebeschreibungen und -revisionen enthalten.
• Bei im Klemmenstrang aneinandergereihten Klemmen (EL/ES) in der so genannten LVDS-Physik ist der Bedarf an E-Bus-Strom zu beachten. Der System Manager rechnet anhand des in der ESI-Beschreibung angegebenen Strombedarfs mit und warnt bei Überlastgefahr des vorangehenden Kopplers. Diese haben üblicherweise 2A Versorgungsvermögen. Negative Werte in der Spalte "E-Bus" sind nicht zulässig und führen zu u.U. schwer zu reproduzierbaren Fehlern!



• zwischen Teilnehmern auf FX/TX-Ebene (Ethernet Kabel, Glasfaser, POF) dürfen die lt. Übertragungsphysik vorgegebenen max. Kabellängen und Dämpfungswerte nicht überschritten werden.
• die Anzahl und Anordnung der EtherCAT Slaves (max. 65535) hat Einfluss auf die Durchlaufzeit der EtherCAT Telegramme.
• es ist auf funktionssichere Schirmanbindung der Koppler/Klemmen und Erdung der Gesamtapplikation zu achten.
• Zuleitungen/Sensorleitungen sind ggf. gesondert zu schirmen.