Industrieprotokolle. Prüfstandsmessung
Auf unserem Prüfstand gemessenLatenz, Jitter und Paketverlust auf einem EtherCAT-Bus messen
19,2 µs mittlerer Umlauf · Jitter ≤ 1 µs · 0 % Paketverlust
TI Sitara AM572x IDK · TI-RTOS · Acontis EC-Master v3.2 · TMS320F28388D
01Problem
Warum EtherCAT? Wo Standard-Ethernet nicht ausreicht
Damit sich die Achsen einer Maschine gemeinsam bewegen, müssen die Daten in jedem Zyklus in derselben Zeit hin- und zurücklaufen. Standard-Ethernet garantiert das konstruktionsbedingt nicht: Ein Paket landet in einer Switch-Queue, wartet auf den Scheduler des Betriebssystems, und seine Ankunftszeit verschiebt sich mit der Last. EtherCAT beseitigt beide Unsicherheiten, ein einzelner Frame durchläuft den gesamten Bus, jeder Slave verarbeitet seine Daten in Hardware im Vorbeilauf, und im Pfad liegt kein Switch. Wir haben den Bus aufgebaut und gemessen, wie gut das in der Praxis trägt.
- 01Bei Standard-Ethernet hängt die Ankunftszeit von Switch-Queuing und Betriebssystem-Scheduling ab, ein garantiertes Zyklusbudget gibt es nicht
- 02Läuft eine Queue über, gehen Pakete verloren; die Neuübertragung lässt die Latenz springen und der Regelkreis verpasst einen Zyklus
- 03Protokolle mit einem eigenen Paket je Gerät lassen die Zykluszeit linear mit der Gerätezahl wachsen
- 04Der TCP/IP-Stack ist für zyklische Prozessdaten zu schwer. Header-Overhead und Kopiervorgänge verlängern den kritischen Pfad
- 05Proprietäre Feldbus-Hardware löst das Determinismusproblem, bindet aber an ein Herstellerökosystem und erhöht die Kosten
02Prüfstandsaufbau
03Messergebnisse
Ein Zyklus auf dem Bus
Der Master legt einen Frame auf den Bus; jeder Slave liest und schreibt seine Daten „on the fly“, während der Frame ihn durchläuft. Vom Ende der Linie kehrt der Frame zum Master zurück. Gemessen wird die Zeit vom Sendebeginn bis zum Eintreffen des letzten Bytes.
Vergleich mit Standard-Ethernet
| Kennwert | Standard-Ethernet | EtherCAT (unsere Messung) |
|---|---|---|
| Jitter | Nicht garantiert, abhängig von Switch-Queuing und Betriebssystem-Scheduling | Maximal 1 µs |
| Paketverlust | Pakete gehen bei Queue-Überlauf verloren; Neuübertragung lässt die Latenz springen | 0 % in unseren Messungen |
| Datenlatenz / Zykluszeit | Unter Last variabel; kann den Millisekundenbereich erreichen | 19,2 µs im Mittel, konstant von 1 kHz bis 10 kHz |
Die EtherCAT-Spalte wurde auf unserem eigenen Prüfstand gemessen. Die Ethernet-Spalte ist keine Messung von uns, sie beschreibt das strukturelle Verhalten eines Standard-Switched-Ethernet/TCP-IP-Stacks und dient als Referenz.
Einfluss der Datengröße auf die Latenz
1 Slave · 10 kHz · bidirektionale Datengröße
Die Datengröße ist der dominierende Faktor. Der Großteil der Zeit entfällt auf die Übertragung; eine Gb/s-Schnittstelle statt 100 Mb/s senkt diesen Anteil direkt.
| Datengröße | Min | Mittel | Max | Gesamt | Bandbreite |
|---|---|---|---|---|---|
| 32 B | 17,40 | 18,00 | 27,70 | 24,30 | 5,798 Mb/s |
| 64 B | 18,50 | 19,20 | 29,10 | 25,50 | 8,230 Mb/s |
| 128 B | 20,40 | 21,20 | 32,10 | 27,30 | 13,122 Mb/s |
| 512 B | 33,20 | 34,10 | 43,40 | 40,30 | 42,419 Mb/s |
| 1024 B * | 49,60 | 50,60 | 62,00 | 56,80 | 54,321 Mb/s |
* Die bidirektionale Nutzlast überschreitet einen einzelnen EtherCAT-Frame und wird auf zwei Frames aufgeteilt. Die Werte gelten für einen der beiden Frames; die Zyklusfrequenz wurde für stabilen Transport gesenkt (1024 B → 6,6 kHz, 2×512 B → 5 kHz).
Einfluss der Slave-Anzahl auf die Latenz
2 Slaves · 10 kHz · bidirektionale Datengröße je Slave
Bei gleicher Gesamtlast fügt der zweite Slave im Mittel nur 0.1 µs hinzu (2 × 32 B: 19,3 µs gegenüber 1 × 64 B: 19,2 µs), unter dem von Acontis genannten Richtwert von ~1 µs je Slave.
| Datengröße | Min | Mittel | Max | Gesamt | Bandbreite |
|---|---|---|---|---|---|
| 2 × 32 B | 18,50 | 19,30 | 33,30 | 25,50 | 8,230 Mb/s |
| 2 × 64 B | 20,40 | 21,20 | 35,10 | 27,40 | 13,122 Mb/s |
| 2 × 128 B | 24,50 | 25,50 | 40,00 | 31,80 | 22,888 Mb/s |
| 2 × 512 B * | 49,50 | 50,50 | 64,30 | 56,70 | 40,740 Mb/s |
* Die bidirektionale Nutzlast überschreitet einen einzelnen EtherCAT-Frame und wird auf zwei Frames aufgeteilt. Die Werte gelten für einen der beiden Frames; die Zyklusfrequenz wurde für stabilen Transport gesenkt (1024 B → 6,6 kHz, 2×512 B → 5 kHz).
Einfluss der Zyklusfrequenz auf die Latenz
1 Slave · 64 B bidirektional
Von 1 kHz bis 10 kHz bewegt sich die mittlere Latenz von 19,7 µs auf 19,2 µs, praktisch konstant. Ein schnellerer Zyklus kostet keine Latenz.
| Frequenz / Zyklus | Min | Mittel | Max | Gesamt | Bandbreite |
|---|---|---|---|---|---|
| 1 kHz · 1000 µs | 19,10 | 19,70 | 28,50 | 26,10 | 0,823 Mb/s |
| 2 kHz · 500 µs | 18,60 | 19,40 | 29,30 | 25,70 | 1,646 Mb/s |
| 5 kHz · 200 µs | 18,50 | 19,20 | 28,70 | 25,50 | 4,115 Mb/s |
| 10 kHz · 100 µs | 18,50 | 19,20 | 30,90 | 25,50 | 8,230 Mb/s |
04Was diese Zahlen bedeuten
Der gemessene Bus liefert auf Standard-Ethernet-Hardware ein vorhersagbares Zyklusbudget: Über einen 100-Mb/s-Link laufen die Daten im Mittel in 19,2 µs hin und zurück; inklusive Master-Software sieht die Anwendung 25,5 µs. Entscheidend ist weniger die Größe dieser Zahlen als ihre geringe Streuung, für den Regelungstechniker zählt Gleichmäßigkeit ebenso viel wie Kürze.
- 01Die Erhöhung des Zyklus von 1 kHz auf 10 kHz kostet keine Latenz, ein schnellerer Regelkreis ist hier gratis
- 02Ein zweiter Slave erhöht den Mittelwert um 0,1 µs; die Zykluszeit wächst mit dem Bus nicht linear
- 03Die Datengröße ist der dominierende Faktor, ein verschlanktes PDO-Mapping bringt unmittelbar Zeit
- 04Ein Gb/s-Interface anstelle des 100-Mb/s-Links senkt die Übertragungszeit direkt; der Slave-ESC auf diesem Prüfstand ist auf 100 Mb/s begrenzt
- 05Standard-Ethernet-PHY statt proprietärem Feldbus-Silizium. Lieferflexibilität und BOM-Kosten bleiben erhalten
Um Ihren Bedarf an Industrieprotokolle. Prüfstandsmessung auf Ihrer eigenen Plattform zu bewerten, planen Sie ein Embedded-Architektur-Audit oder bestimmen Sie Ihre Plattformklasse mit dem System-Anforderungsrechner.
Methodik und Geltungsbereich
- Die Messungen erfolgten auf dem Master-Gerät; die Werte beschreiben den Frame, der den gesamten Bus durchläuft
- Latenz ist die Zeit vom Sendebeginn bis zur Rückkehr des letzten Bytes. Die Spalte „Gesamt“ addiert die mittlere Ausführungszeit der Master-Software
- Der Jitter (Slave-Synchronisationsfehler) beträgt maximal 1 µs; er ist nicht identisch mit der Min-Max-Spanne in den Latenztabellen
- Der Master-Stack ist EC-Master v3.2 Class B und nutzt keine Distributed Clocks (DC), deshalb veröffentlichen wir keinen DC-Synchronisationswert
- In nahezu allen Tests trat kein Paketverlust auf. Ausnahme sind Fälle, in denen die bidirektionale Nutzlast einen einzelnen EtherCAT-Frame überschreitet; eine niedrigere Frequenz stellt stabilen Transport wieder her
- Der Vergleich mit Standard-Ethernet ist keine Messung von uns; er beschreibt das strukturelle Verhalten des Protokolls und ist in der Tabelle so gekennzeichnet
- Die Ergebnisse sind nicht endgültig, sie hängen von Board, Anwendungscode und Busaufbau ab
Probleme mit Zykluszeit oder Synchronisation auf Ihrem Bus?
Kostenlose technische Bewertung, gemeinsam analysieren wir Latenz- und Determinismusprobleme in Ihrem System.
Die Leistungsdaten wurden auf unserem eigenen Prüfstand im oben dokumentierten Aufbau gemessen. Testbedingungen und Rohtabellen sind auf dieser Seite veröffentlicht; das Methodikdokument ist auf Anfrage erhältlich.