EtherCAT-Netzwerkdiagnose und Fehlererkennung

Einführung

EtherCAT-Netzwerke sind das Rückgrat der modernen industriellen Automatisierung – sie ermöglichen deterministische, hochgeschwindige Kommunikation zwischen Steuerungen und Feldgeräten. Aber was passiert, wenn etwas schiefläuft? Ein getrenntes Kabel, ein vertauschtes Kabel, ein falsch konfiguriertes SubDevice, ein SubDevice-Firmware-Absturz, ein sporadischer Frameverlust – das sind alltägliche Realitäten für Ingenieure, die EtherCAT-Systeme einsetzen und warten.

Dieser Artikel beschreibt die häufigsten EtherCAT-Netzwerkfehler, wie der acontis EC-Master-Stack sie erkennt und meldet, und wie Tools wie EC-Engineer dabei helfen, Ursachen schnell zu lokalisieren. Basierend auf der acontis AT3014-Testfallsuite behandeln wir reale Fehlerszenarien mit echten Log-Ausgaben, damit Sie genau wissen, worauf Sie achten müssen.

Testsystemarchitektur

Bevor wir uns den Fehlerkategorien widmen, ist es hilfreich zu verstehen, wie die Diagnosekomponenten zusammenspielen. Der EC-Master-Stack läuft parallel zur Echtzeitanwendung und stellt einen RAS-Server bereit. EC-Engineer verbindet sich als RAS-Client über TCP/IP – ohne Projektdateien, nur mit einer IP-Adresse – und kann die vollständige Topologie, Zustände, Prozessdaten und Fehlerzähler in Echtzeit anzeigen.

In diesen Szenarien werden drei Testnetzwerke verwendet:

  • Netzwerk 1: Beckhoff EK1100-Buskoppler mit EL2004-, EL4132- und EL1004-Klemmen – eine typische I/O-Konfiguration mit zwei Abzweigen.
  • Netzwerk 2: Drei Bosch Rexroth ctrlX DRIVE XCS Servoantriebe in einer Daisy-Chain – repräsentiert ein Mehrachsen-Bewegungssteuerungsszenario.
  • Netzwerk 3: Netzwerk 1 erweitert um einen „EC-Training Disturber" – ein acontis SubDevice auf einem Infineon XMC4800-Board, das auf Abruf Firmware-Abstürze, Frameverluste und unerwartete Zustandsänderungen simulieren kann.

acontis SubDevice EC-Training Disturber

Bestimmte Fehlerzustände lassen sich mit Standard-SubDevices gar nicht oder nur mit großem Aufwand nachbilden. Aus diesem Grund hat acontis eine spezielle Firmware für das Infineon XMC4800 Relax Kit entwickelt, um diese Fehler einfach auslösen zu können. Die entsprechende Funktion wird mit Taste 1 ausgewählt und mit Taste 2 aktiviert.

Folgende Funktionen sind implementiert:

  • Funktionscode 1 — Unerwarteten SubDevice-Zustand erzeugen
  • Funktionscode 2 — Keine Frames werden zurückgegeben
  • Funktionscode 3 — Firmware-Absturz, der zu einem PDI-Watchdog-Fehler führt
  • Funktionscode 4 — Einige Frames werden verworfen, um ein schlechtes Kabel oder einen schlechten Stecker zu simulieren

Die drei Kategorien von EtherCAT-Fehlern

Jeder Fehler, dem ein EtherCAT-MainDevice begegnet, fällt in eine von drei Kategorien – je nachdem, wann er auftritt und wie dauerhaft er ist.

Kategorie 1 — Dauerhafte Fehler beim Netzwerkstart. Diese verhindern, dass das Netzwerk den Betriebszustand (Operational) überhaupt erreicht. Die ENI-Konfigurationsdatei fehlt möglicherweise, die physische Verkabelung stimmt nicht mit der geplanten Topologie überein, oder ein SubDevice lehnt seine Initialisierungsbefehle ab. Diese Fehler treten sofort beim Start der MainDevice-Anwendung auf.

Kategorie 2 — Dauerhafte Fehler während des Betriebs. Das Netzwerk lief einwandfrei, dann ist etwas kaputt gegangen: Ein Kabel wurde gezogen, ein SubDevice verlor die Stromversorgung oder die Firmware eines Geräts ist abgestürzt. Diese Fehler erfordern einen Eingriff – das Problem löst sich nicht von selbst.

Kategorie 3 — Sporadische Fehler während des Betriebs. Das Netzwerk läuft noch, aber nicht einwandfrei. Einige Frames gehen verloren, oder in den zyklischen Prozessdaten treten Working-Counter-(WKC-)Abweichungen auf. Diese sind oft am schwierigsten zu diagnostizieren, da sie vorübergehend und hardwarebedingt sein können.

Kategorie 1: Startfehler — Wenn das Netzwerk nicht hochfährt

Fehlende ENI-Konfiguration

Der einfachste Fehlerfall: Die EtherCAT-Netzwerkinformationsdatei befindet sich nicht an dem Ort, den die Anwendung erwartet. EC-Master meldet Configuration not found (0x98110070) und die Demo-Anwendung beendet sich sofort.

Topologie-Abweichung

Die ENI-Datei erwartet fünf SubDevices, aber nur drei sind physisch verbunden – beispielsweise weil das Kabel zwischen zwei SubDevices entfernt wurde. EC-Master scannt den Bus, vergleicht den Befund mit der Konfiguration und meldet die genaue Position der Abweichung.

Vertauschte SubDevices

Ein subtileres Problem – alle fünf SubDevices sind vorhanden, aber eines wurde physisch an eine andere Position in der Kette verschoben. Die Anzahl der SubDevices stimmt, aber die Topologie ist falsch. EC-Master erkennt einen unerwarteten Gerätetyp an einer bestimmten Position.
Der Network Mismatch Analyzer von EC-Engineer (erreichbar über Netzwerk → Network Mismatch Analyzer) zeigt einen direkten Vergleich zwischen konfigurierten und gefundenen Geräten und hebt Abweichungen in Rot hervor.

IN/OUT-Port-Vertauschung — Ein gefährlicher Verkabelungsfehler

Dieses Szenario ist besonders gefährlich bei Servoantrieben, aber auch in anderen Konfigurationen. Beim Bosch Rexroth ctrlX DRIVE befindet sich der EtherCAT-IN-Anschluss beispielsweise an der Unterseite des Geräts. Wenn jemand die IN- und OUT-Kabel an einem Antrieb vertauscht, kann die dritte Achse als zweite Achse erscheinen – was die Y- und Z-Achse einer Maschine stillschweigend vertauscht. Dies kann zu ernsthaften physischen Schäden führen.
Der Line Crossed Analyzer von EC-Engineer markiert das falsch angeschlossene SubDevice visuell in Rot und macht das Problem sofort erkennbar.

SubDevice-Initialisierungsfehler

Wenn die Sync-Manager-Konfiguration oder das PDO-Mapping eines SubDevices nicht mit den Erwartungen seiner Firmware übereinstimmt, lehnt das SubDevice den Zustandsübergang von PREOP nach SAFEOP ab. Dies äußert sich als AL-Status-Fehler mit einem spezifischen Fehlercode (z. B. Invalid Output Configuration (0x001D) oder Object does not exist in object dictionary (0x9811004A)).
Diese Fehler entstehen typischerweise durch Abweichungen zwischen der ESI-(EtherCAT SubDevice Information-)Datei, der ENI-Konfiguration und der tatsächlichen Firmware-Version des SubDevices.

Kategorie 2: Laufzeitfehler — Wenn ein betriebenes Netzwerk ausfällt

MainDevice-Trennung und Wiederverbindung

Das Ziehen des Ethernet-Kabels am MainDevice unterbricht sofort die gesamte Kommunikation. EC-Master erkennt den Link-Down-Zustand, meldet Frameverlustfehler und markiert alle SubDevices als nicht erreichbar.
Bei Wiederanschluss erkennt EC-Master den Link-Up, scannt den Bus erneut und meldet alle SubDevices wieder als vorhanden. Beachten Sie, dass einige SubDevices während des Ausfalls in den SAFEOP-Zustand gefallen sein können – die Anwendung muss sie explizit wieder in den OP-Zustand versetzen.

SubDevice-Trennung und Wiederverbindung

Das Trennen eines Kabels zwischen SubDevices ist differenzierter – nur die Geräte hinter der Unterbrechung sind betroffen. EC-Master meldet WKC-Fehler bei den betroffenen Prozessdatenbefehlen und identifiziert genau, welche SubDevices nicht mehr erreichbar sind.
Nach der Wiederverbindung erkennt der automatische Bus-Scan von EC-Master die Topologieänderung und benachrichtigt die Anwendung.
Wichtig: EC-Master stellt SubDevices nicht automatisch in den OP-Zustand zurück. Dies ist eine bewusste Designentscheidung – die Anwendung muss selbst entscheiden, ob eine Wiederaufnahme des Betriebs sicher ist.

Stromausfall und Wiederherstellung

Wenn SubDevices die Stromversorgung verlieren, verhält sich dies ähnlich wie eine Kabelunterbrechung, mit einem wichtigen Unterschied: Wenn die Stromversorgung zurückkehrt, starten die SubDevices im INIT-Zustand (nicht in ihrem vorherigen Zustand). Die Anwendung muss sie erneut vollständig durch die Zustandsmaschine führen.

Unerwarteter SubDevice-Zustand

Ein SubDevice kann aufgrund eines internen Fehlers eigenständig in einen niedrigeren Zustand fallen. Der EC-Training Disturber simuliert dies, indem er einen Synchronisierungsfehler (0x1A) meldet und von OP nach SAFEOP ERROR wechselt. EC-Master erkennt die AL-Statusänderung und stellt den spezifischen Fehlercode der Anwendung über EC_NOTIFY_SLAVE_ERROR_STATUS_INFO zur Verfügung.

Totaler Frameverlust durch SubDevice-Ausfall

Eines der anspruchsvollsten Szenarien: Ein SubDevice leitet keine Frames mehr weiter, aber sein Link-Status bleibt aktiv. Da das vorgelagerte SubDevice keinen Link-Down erkennt, kann es die Schleife nicht schließen, und alle Frames gehen verloren – auch für funktionierende SubDevices weiter vorne in der Kette.
Die EC-Master-API ecatRescueScan() ist genau für diese Situation ausgelegt. Sie prüft SubDevices einzeln, um festzustellen, welches Gerät die Frame-Weiterleitung blockiert, und ermöglicht es der Anwendung, das fehlerhafte Gerät zu identifizieren, selbst wenn die normale Kommunikation vollständig ausgefallen ist.

Unbekanntes SubDevice angeschlossen

Das Anschließen eines Geräts, das nicht Teil der ENI-Konfiguration ist, löst eine Bus-Konfigurationsabweichungs-Benachrichtigung aus. EC-Master identifiziert das unbekannte Gerät und meldet dessen Hersteller-ID und Produktcode. Das unbekannte SubDevice verbleibt im INIT-Zustand – es werden keine Daten mit ihm ausgetauscht.
Um proaktiv zu verhindern, dass unbekannte Geräte die Kommunikation stören, stellt EC-Master APIs für „Border Close" bereit – das Schließen ungenutzter Ports am letzten konfigurierten SubDevice, um neu angeschlossene Geräte abzuweisen.

PDI-Watchdog — Erkennung von Firmware-Abstürzen

Wenn die Firmware eines SubDevices abstürzt und nicht mehr auf sein Process Data Interface zugreift, erkennt die EtherCAT Slave Controller (ESC)-Hardware dies über den PDI-Watchdog-Timer. EC-Master liest diesen Status aus und benachrichtigt die Anwendung. Die Wiederherstellung erfordert einen Neustart des SubDevices durch INIT und zurück zu OP.

Kategorie 3: Sporadische Fehler — Die schwer fassbaren

Working-Counter-(WKC-)Fehler

Jeder zyklische EtherCAT-Befehl trägt einen Working Counter, der von jedem SubDevice, das ihn erfolgreich verarbeitet, inkrementiert wird. Stimmt der tatsächliche WKC nicht mit dem erwarteten Wert überein, hat mindestens ein SubDevice den Befehl nicht korrekt verarbeitet. EC-Master vergleicht WKC-Werte in jedem Zyklus und meldet Abweichungen über EC_NOTIFY_CYCCMD_WKC_ERROR, einschließlich Befehlstyp, logischer Adresse sowie erwartetem und tatsächlichem WKC-Wert.

Gelegentlich werden einige Frames nicht an das MainDevice zurückgegeben

Der EC-Training Disturber kann Frames selektiv verwerfen und so EMI-Störungen oder fehlerhafte Kabel simulieren. EC-Master verfolgt jeden gesendeten Frame und markiert alle, die nicht innerhalb des erwarteten Zeitrahmens zurückkehren. EC-Master liest kontinuierlich die SubDevice-Fehlerregister (Register 0x0300 ff.), um zu ermitteln, wo im Netzwerk Fehler auftreten. Die API emGetSlaveStatistics() stellt diese Zähler bereit, und der Extended-Diagnosis-Tab von EC-Engineer zeigt sie pro SubDevice und Port – mit Invalid-Frame/CRC-Fehlern, RX-Fehlern, Lost-Link-Zählern und weitergeleiteten RX-Fehlern.

Diagnose-Tools und Best Practices

EC-Master-Integration – Entwicklung von MainDevice-Anwendungen

EC-Master umfasst eine Vielzahl von Funktionen und Informationen, die Sie bei der Erstellung robuster, hochwertiger MainDevice-Anwendungen unterstützen. Bei der Integration sollten folgende Regeln und Richtlinien beachtet werden:

  • Das Netzwerk sollte schrittweise durch die Zustände INIT, PREOP und SAFEOP in den OP-Zustand überführt werden. Dies hat den Vorteil, dass die Zustände der SubDevices nie höher sind als der Zustand des MainDevices und dass die Anwendung nach Erreichen eines definierten Zustands (z. B. PREOP) notwendige weitere Initialisierungen durchführen kann (z. B. Parameterübertragung).
  • Alle EC-Master-API-Funktionen geben einen Rückgabewert zurück, der überprüft und behandelt werden sollte.
  • Die MainDevice-Anwendung wird vom EC-Master sofort über alle auftretenden Ereignisse informiert. Bestimmte Ereignisse sind rein informativer Natur, aber im Allgemeinen handelt es sich um Fehler, die während des Betriebszustands auftreten. Die Anwendung muss dann entscheiden, ob ein bestimmter Fehler so schwerwiegend ist, dass beispielsweise das System sofort gestoppt werden muss, kurz danach (am Ende des Zyklus oder der Schicht) gestoppt werden muss oder der Fehler nur protokolliert werden muss.
  • EC-Master kann umfangreiche Diagnoseinformationen zu internen Daten und Prozessen bereitstellen. Der Umfang der Daten kann über den Verbositätsgrad festgelegt werden. Dieser Grad sollte ohne Neukompilierung der MainDevice-Anwendung einfach über einen Parameter einstellbar sein.
  • EC-Master und die enthaltenen Beispielanwendungen können, wenn aktiviert, die für jede EC-Master-Funktion benötigte Verarbeitungszeit präzise messen und ausgeben. Damit lässt sich die durch EC-Master verursachte Systemlast ermitteln. In Verbindung mit der ebenfalls gemessenen Zykluszeit kann das Netzwerk-Timing exakt bestimmt werden. Die Ausgabe der Messdaten sollte ohne Neukompilierung der MainDevice-Anwendung einfach über einen Parameter aktivierbar sein.

EC-Engineer-Diagnosefunktionen

EC-Engineer bietet mehrere spezialisierte Analysewerkzeuge zur Fehlerbehebung:

  • Network Mismatch Analyzer: Vergleicht konfigurierte und angeschlossene SubDevices direkt nebeneinander.
  • Line Crossed Analyzer: Identifiziert SubDevices mit vertauschter IN/OUT-Verkabelung.
  • Rescue Scan: Prüft das Netzwerk gerätweise, wenn die normale Kommunikation vollständig ausgefallen ist.
  • Extended Diagnosis: Zeigt portbezogene Fehlerzähler aus ESC-Registern zur Lokalisierung von Kommunikationsqualitätsproblemen.
  • Hardware-Diagnose: Echtzeitüberwachung von Frame-Zählern (TX, RX, Lost), Topologiestatus und Link-Zustand.

Erfahren Sie mehr über die Diagnosefunktionen von EC-Engineer in diesem Blog-Beitrag.

Empfehlungen für eine robuste Fehlerbehandlung

  • Registrieren Sie immer Benachrichtigungs-Callbacks für die oben aufgeführten wichtigen Fehlerbenachrichtigungen.
  • Implementieren Sie automatische Wiederherstellungslogik für vorübergehende Fehler – verlangen Sie jedoch eine Bestätigung durch den Bediener, bevor SubDevices nach schwerwiegenden Fehlern wie Stromausfall oder Firmware-Abstürzen neu gestartet werden.
  • Verwenden Sie Border Close auf Produktionssystemen, um zu verhindern, dass nicht autorisierte Geräte das Netzwerk stören.
  • Überwachen Sie Fehlerzähler kontinuierlich über emGetSlaveStatistics(), um eine nachlassende Kabelqualität zu erkennen, bevor es zu Ausfällen kommt.
  • Testen Sie Ihre Fehlerbehandlung anhand der in diesem Artikel beschriebenen Testfälle. Der acontis EC-Training Disturber oder ähnliche Tools ermöglichen es Ihnen, reale Fehlerbedingungen in einer kontrollierten Umgebung zu simulieren.

Fazit

Der deterministische Charakter von EtherCAT bedeutet, dass Fehler klar definiert und erkennbar sind – aber nur, wenn die MainDevice-Software sie korrekt behandelt. Der acontis EC-Master-Stack bietet umfassende Fehlererkennung, von Bus-Scan-Abweichungen beim Start bis hin zu portbezogenen CRC-Fehlerzählern im Betrieb. In Kombination mit den visuellen Diagnosewerkzeugen von EC-Engineer können Ingenieure Netzwerkprobleme schnell identifizieren und beheben.

Ob Sie eine neue Maschine in Betrieb nehmen, ein Problem im Feld beheben oder eine robuste Fehlerbehandlung in Ihre Anwendung integrieren – das Verständnis dieser Fehlerkategorien und ihrer Diagnosemuster ist unverzichtbares Wissen für jeden EtherCAT-Entwickler.

Detaillierte Testfallspezifikation anfordern