Funktionsgrundlagen EtherCAT-Abzweige

EtherCAT-Handling in den Slaves

Beim Einsatz von EtherCAT als Feldbusprotokoll sind viele verschiedene Bustopologien anwendbar: Linie-, Stern-, Baumtopologie und mit Redundanz-Unterstützung sogar Ringtopologie. Die einfachste Topologie ist die Linientopologie, bei der jeder EtherCAT-Slave die Daten an den einzigen nächsten weiterreicht.

Beim Einsatz von z.B. EtherCAT-Kopplern EK1100 ist auch ein Abzweig und damit eine Art Baumtopologie möglich.

Grundlegend dabei ist, dass intern der oder die Ethernet-Frame(s) mit den EtherCAT-Protokolldaten weiterhin in einem logischen Ring befördert werden:

• der EtherCAT-Master sendet den Frame auf den beiden Hin-Leitungen des Ethernet-Kabels aus
• dieser Frame durchläuft einmalig jeden Slave
• wird vom logisch letzten Slave dann gewendet und
• auf den beiden Rück-Leitungen des Ethernet-Kabels dann ohne weiteres Processing wieder durch jeden EtherCAT-Slave zum Master zurückbefördert

Bei kurzen Zykluszeiten von z.B. 50 µs sind dabei mindestens 20.000 Ethernet Frames je Sekunde im dem EtherCAT-System unterwegs, zuzüglich azyklischer Organisationsframes. Der Master erwartet dabei auf die Rückkehr der ausgesandten Frames, die z.B. die Eingangsdaten der Teilnehmer zum Master zurücktransportieren. Die Weiterleitung der Telegramme von einem Slave zum nächsten ist dabei link-basiert: nur wenn ein "Link"-Signal zum nächsten Teilnehmer besteht, sendet ein EtherCAT-Slave einen Frame weiter. Im Normalfall ist davon auszugehen, dass der nachfolgende Teilnehmer jedes EtherCAT-Telegramm auch korrekt weiterbearbeitet und am Schluss ggf. zurücksendet bzw. weiterleitet.

Entscheidend bei der Weiterleitung von EtherCAT-Telegrammen ist also, dass ein Link-Signal erst dann von einem Slave zum anderen gemeldet wird, wenn beide wirklich bereit sind in Echtzeit an der Datenverarbeitung teilzunehmen. Konkret darf ein EtherCAT-Slave also erst dann den jeweiligen Ethernet-Port öffnen, wenn er umgehend einen Ethernet-Frame annehmen und weiterleiten kann.

Um üblichen Ethernet-Verkehr weiterzuleiten wird i.d.R. ein Switch oder Router eingesetzt. Treten dort Kollisionen oder Frame-Verluste auf, wird dies von übergeordneten Protokollschichten (z.B. TCP) durch Frame-Wiederholung ausgeglichen. Diese Betriebsart ist bei EtherCAT aufgrund der kurzen Zykluszeiten und des Echtzeit-Anspruchs standardmäßig nicht im Einsatz. Einige Ethernet-Geräte wie z.B. spezielle Switche melden bereits einen Link zur Gegenstelle, obwohl sie erst in einigen Millisekunden zur Datenverarbeitung bereit sind. Besonders auffällig wird dieses Verhalten bei Medienkonvertern von 100Base-TX (Kupfer) nach 100Base-Fx (Lichtwellenleiter), die je nach Einstellung auf der Kupferseite zum vorhergehenden EtherCAT-Slave einen Link melden, obwohl die LWL-Verbindung unterbrochen ist.

Deshalb ist die schnelle Link-Detektion ein zentraler Bestandteil eines jeden ESC (EtherCAT Slave Controller, Hardwareverarbeitungseinheit des EtherCAT-Protokolls). Laut EtherCAT-Spezifikation kann ein ESC über 1 bis 4 Ports verfügen, die er von sich aus kontrolliert. Öffnet er einen Port, ist dort abgehender und ankommender Ethernet-Verkehr möglich. Die Datenflussrichtung in einem vollausgebauten ESC ist in Abb. 3. gezeigt - dabei werden die Daten in den EtherCAT-Datagrammen nur zwischen Port 0 (A) und 3 (D) in der EtherCAT-Processing-Unit verarbeitet.

Idealerweise findet die Link-Erkennung und damit das Port-Handling im ESC so schnell statt, dass selbst bei 100 µs Zykluszeit kein Lost-Frame-Ereignis auftritt. Dennoch ist zumindest ein verlorener Frame nie auszuschließen, falls nämlich eine Verbindung getrennt wird, während ein Ethernet-Frame gerade genau auf diesem Kabel bzw. in dem Bussegment hinter der Trennstelle unterwegs ist.

Umsetzung: EL-Klemme

Ein üblicher EtherCAT-Slave wie z.B. Beckhoff EL-Klemmen verfügt über 2 Ports:

• einen für ankommende Frames (Port 0 [A])
• und einen für abgehende Frames (z.B. Port [D]).

Die anderen beiden Ports sind intern im ESC geschlossen. Ein EtherCAT-Telegramm gelangt über Port 0 (A)/oben zur Processing-Unit und wird dann über Port 3 (D)/links zum nächsten Slave weitergereicht, falls ein Link zu diesem besteht - s. grüne Pfeile. Das ist dann der Fall, wenn rechts eine weitere EL-Klemme gesteckt ist.

Besteht kein Link, wird der Frame über den violetten Weg zum Port 1(B) weitergereicht. Dieser und auch Port 2 (C) haben keinen Link und reichen den Frame damit zum Port 0 (A) zurück, wo der Frame über den gleichen Ethernet-Port über den er am Slave ankam, diesen wieder verlässt. Das ist der Fall, wenn die betrachtete Klemme als Endklemme fungiert.

Ein EtherCAT-Teilnehmer mit nur einem Port ist somit nur begrenzt einsetzbar, da er nur als End-Teilnehmer eingesetzt werden kann.

Umsetzung: EK1100 EtherCAT-Koppler

Im EtherCAT-Koppler EK1100 werden 3 von den 4 verfügbaren Ports genutzt und damit ein Anschluss nach rechts zu Klemmen und über eine RJ45-Buchse zu weiteren Kopplern ermöglicht, siehe Abb. Linientopologie mit Erweiterungen. Die Processing-Unit wird im EK1100 nicht zum Prozessdatenaustausch genutzt.

Umsetzung: EK1122 EtherCAT-Abzweig

Im EK1122 können alle 4 Ports des ESC verbunden werden. Zwei über den klemmeninternen E-Bus und zwei über die RJ45-Buchsen mit Ethernet-Physik. Im TwinCAT Systemmanager werden die Link-Stati der Ports 0, 1, 2 und 3 über die Online-Anzeige mitgeteilt - dort werden sie mit Port A, B, C und D bezeichnet, siehe Abb. Topologie Anzeige bei unterbrochener Leitung.

Umsetzung: EK1521/EK1521-0010/EK1561 EtherCAT-Abzweig

Im o.g. Abzweigen können wie im EK1100 3 Ports des ESC verbunden werden. Zwei über den klemmeninternen E-Bus und einer über die SC-Buchse/Versatile Link per LWL-Leitung/POF-Leitung.

Umsetzung: CU1128 und EP9128 EtherCAT-Abzweige

Im CU1128 sind 3 ESC integriert, es können somit insgesamt 8 Ports durch Anwender belegt werden. Die 3 ESC sind untereinander über E-Bus verbunden.

Beispielkonfiguration mit EK1122

Im Folgenden soll nun beispielhaft das Linkverhalten unter TwinCAT und seine Darstellung im Systemmanager erläutert werden.

In der TwinCAT Online-Topologie ist der Verdrahtungsplan ersichtlich, siehe Abb. Online-Topologie. Markiert ist darin der EK1122, so dass weitere Informationen dargestellt werden. Die grünen Balken über den Slaves zeigen den ordnungsgemäßen RUN-State in allen Slaves an.

Nun soll ein Fehler erzeugt werden: die Verbindung der oberen RJ45-Buchse (X1) zur EL3102 wird getrennt. Innerhalb weniger µs erkennt die ESC in der EK1122 den verlorenen Link und schließt den betroffenen Port selbsttätig. Damit wird das nächste ankommende EtherCAT-Telegramm sofort zum Port D (Port 3) und der EL4732 weitergereicht. Damit fehlt hier der Link und der Systemmanager kennzeichnet dies in der Online-Anzeige, siehe Abb. Beispielkonfiguration mit unterbrochener Leitung.

Die Meldungen des Systemmanager sind wie folgt zu deuten:

• Adresse 1002 - EK1122: "OP LNK:MIS D" - Slave ist weiterhin im OP-State, vermisst aber einen laut Konfiguration vorhandenen Link an Port D (3)
• Adresse 1003 - EK1100: "INIT NO_COMM" - da keine Kommunikation mehr zu diesem Slave besteht, wird er als im INIT-State befindlich geführt
• Adresse 1004 - EL3104: dto.

Logger-Ausgabe Im unteren Teil des Systemmanagers ikann die Logger-Ausgabe eingeblendet werden (Anzeige --> Zeige Logger Ausgabe). Dort werden nicht nur bei Linkunterbrechungen hilfreiche Meldungen zur weiteren Interpretation ausgegeben.

In der Topologieansicht zeigt sich diese Unterbrechung durch eine rote Umrandung der betroffenen Slaves, siehe folgende Abb.

Man beachte die Anzeige der azyklischen Frames für Abb. Beispielkonfiguration mit EK1122 und für Abb. Beispielkonfiguration mit unterbrochener Leitung.

Im linken Bildauszug sind nur sehr wenige (2) azyklische Frames in der betreffenden Sekunde vom Master ausgesendet worden - alle Slaves sind ordnungsgemäß in Betrieb. Im rechten Bildauszug ist dagegen mit aktuell 77 azyklischen Frames/sec ein deutlicher Anstieg zu verzeichnen: der EtherCAT Master hat schnell erkannt, dass nicht alle Slaves störungsfrei am Datenaustausch teilnehmen. Nachdem er die Störung lokalisiert hat, versucht er nun fortlaufend die Verbindung wiederherzustellen.

Verbindungswiederherstellung

Wird nun in diesem Beispiel die Verbindung wiederhergestellt, meldet der EK1122 an den Master, dass am Port D (3) wieder ein Link anliegt. Der EtherCAT Master wird dann seine Prozessdaten für diesen Abschnitt wieder entsprechend bereitstellen. Wenn die Vorbereitungen abgeschlossen sind, wird er den EK1122 anweisen, den Port D (3) für den regulären Datenaustausch wieder zu öffnen. Der zyklische und azyklische Datenverkehr mit den anderen EtherCAT Slaves läuft dabei selbstverständlich weiter.

Externer Zugriff auf die EtherCAT-Diagnose Es bestehen umfangreiche Möglichkeiten, aus der SPS heraus auf Zustände, Diagnoseinformationen und Funktionen des EtherCAT-Masters zuzugreifen. Auch über ADS sind fast alle Informationen, die der Systemmanager online darstellt (s. Abbildungen auf dieser Seite) abrufbar. Ebenso können Aktionen des Systemmanagers über SPS oder ADS ausgelöst werden. Beachten Sie dazu entsprechende Informationen im Beckhoff Information System und Erläuterungen zur EtherCAT Diagnose.