Bei EtherCAT schickt der Master pro Zyklus einen einzigen Ethernet-Frame, den sich alle Geräte der Linie teilen. Während der Frame ein Gerät durchläuft, liest dessen EtherCAT Slave Controller (ESC) die eigenen Ausgangsdaten, schreibt die Eingangsdaten in denselben Frame und leitet ihn ohne Anhalten weiter, vollständig in Hardware. Das letzte Gerät schickt den Frame zurück, und der Master prüft am Working Counter, ob jedes Gerät seinen Anteil verarbeitet hat. Auf unserem Prüfstand (TI AM572x als Master, ein Slave, 64 Byte Prozessdaten, 10 kHz) dauerte es vom Senden bis zur vollständigen Rückkehr des Frames im Mittel 19,2 µs und höchstens 30,9 µs.

Kurz gesagt

  • Die ganze Linie teilt sich einen Frame: Dank FMMU trägt ein Datagramm die Prozessdaten aller Geräte, und jedes Gerät liest und schreibt seinen Anteil im Durchlauf in Hardware.
  • Der Working Counter zählt die Geräte, die ein Datagramm verarbeitet haben; stimmt er nicht, sind die Daten dieses Zyklus nicht frisch.
  • Klassisches CAN überträgt höchstens 8 Byte pro Frame, CAN FD bis zu 64 Byte; den Bus teilen sich die Knoten über eine ID-basierte Arbitrierung. Für verteilte Steuergeräte im Fahrzeug bleibt CAN das richtige Werkzeug.
  • Auf unserem Prüfstand (1 Slave, 64 B, 10 kHz): 19,2 µs im Mittel, 30,9 µs maximal, 25,5 µs gesamt mit Master-Software. Die Datenmenge bewegte die Latenz weit stärker als die Zyklusfrequenz.

Warum braucht eine Maschine ein gemeinsames „Wann“?

Der 80-Sekunden-Film oben auf dieser Seite beginnt mit einem Satz: Eine Maschine besteht aus Teilen, die sich einig sein müssen, wann etwas geschieht. Bewegen sich die sechs Achsen eines Roboterarms nicht mit den Befehlen desselben Zyklus, verlässt das Werkzeug die programmierte Bahn.

Im klassischen Ethernet-Ansatz bekommt jedes Gerät sein eigenes Paket und sendet seine eigene Antwort. Die Pakete stehen im Switch in der Warteschlange, die Latenz hängt von deren Füllstand ab, und jeder Ethernet-Frame ist mindestens 64 Byte lang, auch wenn ein Gerät nur wenige Byte braucht. Die Antwort von EtherCAT ist ein Frame pro Zyklus mit einem Platz für jedes Gerät.

Rechenbeispiel (keine Messung): 30 Geräte, jedes erhält 4 Byte Befehl und liefert 4 Byte Status; Präambel und Interframe-Gap bleiben unberücksichtigt. Mit einem Frame pro Gerät verlassen 30 × 64 = 1.920 Byte den Master. Ein EtherCAT-Frame umfasst 14 + 2 + 10 + 240 + 2 + 4 = 272 Byte (Ethernet-Header, EtherCAT-Header, Datagramm-Header, 30 × 8 = 240 Byte Daten, Working Counter, FCS) und kommt mit den Antworten zurück. Der Master sendet knapp ein Siebtel der Bytes. Das Verhältnis beschreibt die Leitungsausnutzung, nicht die Latenz.

Der Film verfolgt diese Idee durch ein Werk: Der Frame verlässt den Schaltschrank, steuert die Servoantriebe, die sechs Achsen des Arms, der eine Karosserie schweißt, und die dreißig Gelenke eines humanoiden Roboters und endet in dem Auto, das diese Linie gebaut hat. Schaltschrank, Arm, Humanoid und Auto sind unsere eigenen 3D-Illustrationen; die dreißig Gelenke sind keine Produktaussage. Die Prüfstandswerte sind echt und stammen von uns (Filmseite).

Was steckt in dem einen Frame?

EtherCAT legt seine Daten in einen Standard-Ethernet-Frame mit dem EtherType 0x88A4. Laut Beckhoffs ESC-Datenblatt folgen auf den 14-Byte-Ethernet-Header ein 2-Byte-EtherCAT-Header (Länge und Typ), ein Datagrammbereich von 14–1.498 Byte und eine 4-Byte-FCS. Im Datagrammbereich stehen ein oder mehrere Datagramme, jedes mit 10-Byte-Header (Kommando, Adresse, Länge), 0–1.486 Byte Daten und 2-Byte-Working-Counter.

Für Konfiguration und Status dient die Geräteadressierung. Prozessdaten nutzen die logische Adressierung: Alle Geräte teilen sich einen logischen Adressraum von 4 GB, und die FMMU (Fieldbus Memory Management Unit) jedes Slaves bildet einen Ausschnitt dieses Prozessabbilds auf den eigenen Speicher ab, bei Bedarf bitweise. Der Master richtet die Zuordnungen beim Hochlauf ein. So erreicht ein LRW-Datagramm (logical read-write) ESCs an beliebigen Stellen der Linie in einem Durchlauf, und der Master sammelt die Daten nicht Gerät für Gerät ein.

Verarbeitung im Durchlauf: Der Frame wartet nirgends

Nach der Beschreibung der ETG liest jeder Slave die an ihn adressierten Daten „on the fly“ und fügt seine eigenen ein, während der Frame weiterläuft; verzögert wird der Frame nur um die Signallaufzeit der Hardware. Beckhoffs Datenblatt ergänzt die Hardwareseite: Der ESC speichert den Frame nicht, Daten werden gelesen und geschrieben, während die Bits durchlaufen, und es gibt nicht einmal einen Sende-FIFO. Deshalb braucht jeder Slave einen ESC: als ASIC, als FPGA oder als Block in einem Mikrocontroller. Im TMS320F28388D auf unserem Prüfstand sitzt der ESC im C2000-Mikrocontroller.

Den Verkehr zwischen ESC-Speicher und Slave-Prozessor regelt der SyncManager. Zyklische Prozessdaten (PDO) laufen im gepufferten Modus (drei Puffer), sodass der Leser immer die jüngsten konsistenten Daten erhält. Konfiguration und Diagnose laufen außerhalb des Zyklus im Mailbox-Modus mit Handshake; CoE transportiert darüber Objektverzeichnis, PDO-Mapping und SDOs von CANopen. Eine Pufferänderung wird nur übernommen, wenn die FCS des Frames stimmt; ein beschädigter Frame hinterlässt keinen halb geschriebenen Puffer.

Auch der Rückweg liegt in der Hardware. Die Leitung arbeitet im Vollduplex. Ein geschlossener Port sendet nichts nach außen und reicht den Frame intern an den nächsten Port weiter; im automatischen Modus gilt ein Port ohne Link als geschlossen. Am letzten Gerät ist der freie Port geschlossen, und der Frame kehrt von selbst um. Ein ESC mit zwei Ports verarbeitet den Frame auf dem Hinweg und leitet ihn auf dem Rückweg nur weiter.

Working Counter: Woher weiß der Master, dass die Arbeit getan ist?

Jedes Datagramm endet mit einem 16-Bit-Working-Counter (WKC). Der ESC erhöht ihn bei Erfolg in Hardware: um 1 beim Lesen, um 1 beim Schreiben und bei Lese-Schreib-Kommandos um bis zu 3 (1 für das Lesen, 2 für das Schreiben). Der Master berechnet den erwarteten Wert vorab. Werden zwei Slaves im selben LRW-Datagramm gelesen und beschrieben, erwartet er 3 + 3 = 6; verarbeitet einer seinen Anteil nicht, kommt 3 zurück. Der Zähler zählt Geräte, keine Bytes.

/* Gerüst eines Master-Zyklus (Pseudocode) */
for (;;) {
    wait_cycle_tick();                      /* z. B. 10 kHz: alle 100 µs */
    put_outputs(&frame, app_outputs);       /* ein LRW-Datagramm */
    send(&frame);
    if (!wait_return(&frame, deadline)) {   /* Frame kam nicht zurück */
        lost_frames++;
        keep_last_valid_inputs();
        continue;
    }
    if (frame.wkc != expected_wkc) {        /* ein Gerät hat nicht verarbeitet */
        mark_inputs_stale();                /* alte Daten nie als frisch ausgeben */
        if (++wkc_errors >= WKC_LIMIT)      /* Grenze legt die Maschine fest */
            enter_safe_state_and_diagnose();
        continue;
    }
    wkc_errors = 0;
    app_update(get_inputs(&frame));         /* nur konsistente Zyklen */
}

Warum nutzt das Auto einen anderen Bus?

Im Film endet die Reise des Frames im Auto, und dort übernimmt ein anderer Bus: CAN sendet acht Byte pro Nachricht, immer nur eine Nachricht, und alles andere wartet, bis es an der Reihe ist. Der Vergleich ist strukturell, keine Messung.

Im klassischen CAN (CAN CC) trägt ein Frame 0 bis 8 Byte Daten. Der 11- oder 29-Bit-Identifier (ID) beschreibt den Inhalt und legt die Priorität fest; der kleinste Wert gewinnt. Starten mehrere Knoten gleichzeitig, werden ihre Identifier Bit für Bit verglichen; die Verlierer werden Empfänger des laufenden Frames, und der Gewinner-Frame läuft unbeschädigt weiter. Die Empfänger bestätigen den korrekten Empfang mit einem dominanten Bit im ACK-Slot. CAN FD erweitert das Datenfeld auf 64 Byte und kann in der Datenphase auf eine höhere Bitrate umschalten, während die Arbitrierung auf 1 Mbit/s begrenzt bleibt. Laut CiA sind beide gemeinsam in ISO 11898-1:2024 genormt; CAN XL erweitert das Datenfeld auf 2.048 Byte.

Das passt zum Auto: Steuergeräte senden zu unabhängigen Zeitpunkten, eine dringende Nachricht setzt sich über ihren Identifier durch, und jede Nachricht erreicht alle Knoten. Die CiA bezeichnet CAN als das dominierende serielle Netz für eingebettete Steuerungen in Pkw. Beide Busse können sich sogar einen Chip teilen: Der TMS320F28388D auf unserem Prüfstand hat neben dem ESC zwei CAN-Module und ein CAN-FD-Modul (MCAN).

EtherCAT Klassisches CAN / CAN FD
Wer sendet Nur der Master Jeder Knoten; gleichzeitige Starts gehen in die Arbitrierung
Daten pro Frame Bis zu 1.486 Byte pro Datagramm 0–8 Byte; mit CAN FD bis zu 64
Bestätigung WKC: verarbeitende Geräte ACK: mindestens ein Empfänger hat korrekt empfangen
Entwurfsziel Eine Steuerung führt eine Maschine Zyklus für Zyklus Verteilte Steuergeräte mit unabhängigen Nachrichten

Welcher Bus wohin passt, diskutieren wir in unserem Rahmen für die Auswahl industrieller Protokolle (auf Türkisch).

Was haben wir auf dem Prüfstand gemessen?

Wir verkaufen keinen EtherCAT-Master. Wir bringen Linien auf TI-Silizium in Betrieb und charakterisieren ihr Zeitverhalten; das ist unsere Arbeit im Bereich industrielle Protokolle, und die Zahlen im Film sind ein Prüfstandsprotokoll davon.

  • Master: TI Sitara AM572x IDK (PRU-ICSS), TI-RTOS; ein kommerzieller Class-B-EtherCAT-Master-Stack. Nach ETG.1500 ist Class B die „Minimum“-Masterklasse, in der die Unterstützung von Distributed Clocks (DC) an eine Bedingung geknüpft ist; unser Aufbau nutzt kein DC.
  • Slave: TI Delfino TMS320F28388D (integrierter ESC), Beckhoff SSC v5.13.
  • Leitung und Werkzeuge: 100 Mb/s Vollduplex; Code Composer Studio 12.8.1, Blackhawk XDS560v2.
1 Slave, 64 B Prozessdaten, 10 kHz Wert
Frame, vom Senden bis zur vollständigen Rückkehr (min / Mittel / max) 18,5 / 19,2 / 30,9 µs
Gesamt inklusive Master-Software 25,5 µs
Synchronisationsfehler des Slaves maximal 1 µs
Paketverlust 0 % in unseren Messungen

Wir veröffentlichen nicht nur den Mittelwert, sondern auch das Maximum. In einem Regelkreis beruhigt Sie der Mittelwert; ob die Maschine ausgeliefert wird, entscheidet das Maximum.

Die Übertragungslatenz reicht vom Senden des Frames bis zu seiner vollständigen Rückkehr, ohne Master-Software. Gesamt addiert die mittlere Laufzeit der Master-Software zur mittleren Übertragungslatenz; das ist die Zeit, die die Anwendung sieht. Die Differenz ist der Softwareanteil: hier 25,5 − 19,2 = 6,3 µs, und über alle unsere Tabellen liegt er zwischen 6,1 µs (128 B: 27,3 − 21,2 = 6,1 µs) und 6,4 µs (1 kHz: 26,1 − 19,7 = 6,4 µs). Mit den Bedingungen wächst die Übertragung, der Softwareanteil bleibt nahezu konstant.

Was wir als Jitter angeben, ist der Synchronisationsfehler des Slaves (maximal 1 µs). Die Min/Max-Spanne ist kein Jitter, sondern die Streuung der Umlaufzeit, und die 1 µs sind kein DC-Ergebnis. Die Methode steht in unserem Beitrag zur Messmethodik (auf Türkisch), unsere TI-Arbeit auf der Plattformseite zu Texas Instruments.

Was sagen die Zahlen dem Anlagenplaner?

Die Zeilen stammen aus unseren drei Messtabellen; die Größe ist die Angabe der bidirektionalen Prozessdaten aus dem Prüfstandsprotokoll.

Bedingung Mittel (µs) Max (µs) Gesamt (µs)
1 Slave, 64 B, 1 kHz 19,7 28,5 26,1
1 Slave, 64 B, 10 kHz 19,2 30,9 25,5
1 Slave, 32 B, 10 kHz 18,0 27,7 24,3
1 Slave, 128 B, 10 kHz 21,2 32,1 27,3
1 Slave, 512 B, 10 kHz 34,1 43,4 40,3
2 Slaves × 32 B, 10 kHz 19,3 33,3 25,5
2 Slaves × 64 B, 10 kHz 21,2 35,1 27,4

Die Frequenz erhöht die Latenz nicht. Von 1 kHz auf 10 kHz sinkt der Mittelwert von 19,7 µs auf 19,2 µs; das Maximum bewegt sich zwischen 28,5 und 30,9 µs, und wir lesen daraus keinen Trend. Was schrumpft, ist der Zyklus: Die Periode sinkt von 1.000 µs auf 100 µs und mit ihr die Zeit für die Anwendung. Geschwindigkeit bezahlen Sie im Zeitbudget des Zyklus.

Die Datenmenge bestimmt die Latenz. Von 32 auf 512 Byte steigt der Mittelwert von 18,0 µs auf 34,1 µs und das Maximum von 27,7 µs auf 43,4 µs. Jedes Byte im PDO-Mapping läuft in jedem Zyklus mit; ungenutzte Signale gehören nicht ins Mapping.

Das zweite Gerät versteckt sich im Mittelwert. Bei gleicher Gesamtdatenmenge fügt der zweite Slave dem Mittelwert 19,3 − 19,2 = 0,1 µs hinzu, und 2 × 64 B liegen im Mittel gleichauf mit einem Slave mit 128 B (21,2 µs). Das Maximum widerspricht: 33,3 µs gegenüber 30,9 µs und 35,1 µs gegenüber 32,1 µs. Die Ursache können diese Daten nicht zeigen, wohl aber das Risiko, eine Linie nach dem Mittelwert auszulegen.

Die Grenze von 1.498 Byte. Der Datagrammbereich eines Frames umfasst höchstens 1.498 Byte, Header inklusive. Bei 1 Slave × 1024 B und bei 2 × 512 B überschritten die bidirektionalen Daten diese Grenze, die Übertragung wurde auf zwei Frames aufgeteilt, und bei 10 kHz gingen Pakete verloren; wir mussten auf 6,6 kHz beziehungsweise 5 kHz heruntergehen. Legen Sie das PDO-Mapping mit der Summe beider Richtungen aus und halten Sie Abstand zur Grenze.

Wo es schiefgeht

  • Den Mittelwert als einzige Zahl angeben. Dieselbe Bedingung (1 Slave, 64 B, 10 kHz) steht in zwei unserer Tabellen: Mittelwert in beiden 19,2 µs, Maximum einmal 30,9 µs und einmal 29,1 µs. Das Maximum einer Messreihe ist keine Worst-Case-Grenze, sondern nur der schlechteste Wert dieser Reihe.
  • Von einem Stack ohne DC eine DC-Zahl verlangen. Ein DC-Synchronisationswert aus einem Aufbau ohne DC kann nicht gemessen sein.
  • Ein PDO-Mapping, das größer ist als ein Frame. Auf unserem Prüfstand führte das bei 10 kHz zu Paketverlust und erzwang eine niedrigere Frequenz.
  • Eine Anwendung, die den WKC ignoriert. Sie hält einen Zyklus, in dem ein Gerät seinen Anteil nicht verarbeitet hat, für frische Daten.
  • Verkabelungs- und Topologiefehler. Beckhoff-ESCs werten keine MAC-Adressen aus, deshalb darf zwischen Master und erstem Slave oder zwischen Slaves kein unmanaged Switch sitzen, und ein ESC im Büronetz löst einen Broadcast-Sturm aus. Nutzen Sie für die Diagnose Stationsadressen statt Positionsadressen; Positionen verschieben sich, wenn Ports vorübergehend schließen.

Was dieser Beitrag nicht sagen kann

  • Wir haben mit einem und zwei Slaves gemessen, nicht an einer Linie mit Hunderten Geräten; die 0,1 µs im Mittel mit hundert zu multiplizieren, geben diese Daten nicht her.
  • Wir haben keine DC-Messung.
  • Wir haben keine vergleichende Messung gegen Standard-Ethernet; die Ethernet-Spalte in unserer EtherCAT-Fallstudie ist eine strukturelle Beschreibung, keine Messung.
  • Wir haben keinen Worst-Case-Wert inklusive Softwarepfad: 25,5 µs ist die Summe zweier Mittelwerte.
  • Auf der CAN-Seite haben wir nichts gemessen; im Film sind nur die Prüfstandswerte Messungen.
  • Ein anderes Board, eine andere Stack-Version oder ein anderes PDO-Mapping ergibt andere Zahlen.

Häufig gestellte Fragen

Was bedeutet „Processing on the fly“ bei EtherCAT?

Der Frame hält an keinem Gerät an: Die ESC-Hardware jedes Slaves liest ihre Ausgangsdaten und schreibt ihre Eingangsdaten in denselben Frame, während die Bits durchlaufen, und speichert den Frame nicht.

Wofür ist der Working Counter da?

Der 16-Bit-Zähler am Ende jedes Datagramms zählt die Geräte, die es erfolgreich verarbeitet haben. Der Master vergleicht ihn mit dem erwarteten Wert; weichen beide ab, sind die Daten dieses Zyklus unvollständig oder veraltet und dürfen nicht als frisch gelten.

Warum ersetzt EtherCAT nicht CAN?

Beide wurden für unterschiedliche Aufgaben entworfen: EtherCAT für Maschinen, in denen eine Steuerung jedes Gerät in jedem Zyklus mit einem Frame erreicht, CAN für verteilte Netze, in denen jeder Knoten eigene Nachrichten senden kann und der Identifier die Priorität bestimmt.

Gelten diese Zahlen für meine Linie?

Nicht direkt. Sie charakterisieren einen Aufbau (TI AM572x als Master, ein kommerzieller Class-B-Stack, ein oder zwei TMS320F28388D als Slaves, 100 Mb/s); die Antwort für Ihre Linie ergibt sich aus Messungen auf Ihrem SoC, mit Ihrem PDO-Mapping und Ihrer Geräteanzahl.

Quellen