EtherCAT in Echtzeit unter Linux ausführen
Ein praktischer Leitfaden für EC-Master unter Linux
Einführung
EtherCAT ist eines der anspruchsvollsten industriellen Feldbus-Protokolle in Bezug auf Timing-Anforderungen. Einen leistungsstarken EtherCAT-MainDevice-(Master-)Stack auf einem Allzweck-Betriebssystem wie Linux zu betreiben, stellt echte Herausforderungen dar – aber mit dem richtigen Ansatz kann Linux das deterministische Verhalten liefern, das die industrielle Automatisierung fordert. Dieser Artikel beschreibt, wie ein Linux-System für die EtherCAT-Kommunikation mit dem acontis EC-Master-Stack optimiert wird, welche Ethernet-Treiberarchitekturen verfügbar sind und wie reale Leistungswerte auf einer Reihe gängiger Hardware-Plattformen aussehen.
EC-Master unter Linux
acontis EC-Master ist ein professioneller EtherCAT-MainDevice-Protokoll-Stack, der als Software-Bibliothek und Entwicklungskit verfügbar ist. Er unterstützt eine Vielzahl von Betriebssystemen und Hardware-Plattformen und ist in Branchen wie Robotik, Maschinenbau, Automatisierung und Medizintechnik weit verbreitet. Der Stack kommuniziert mit EtherCAT-SubDevices, indem er EtherCAT-Frames über einen Standard-Ethernet-MAC-Controller sendet und empfängt, und unterstützt erweiterte Funktionen wie die Distributed-Clocks-Synchronisierung.
EC-Master ist so konzipiert, dass er vollständig im Linux-Userspace läuft, was eine schnelle und komfortable Entwicklung ermöglicht und gleichzeitig GPL-konform bleibt. Um die extrem kurzen Zykluszeiten zu erreichen, für die er bekannt ist, darf die Implementierung im zyklischen Teil keine blockierenden Kernel-Funktionen (APIs) verwenden. In Verbindung mit Echtzeit-Usermode-Treibern garantiert diese Architektur die bestmögliche deterministische Echtzeit-Performance.
EC-Master EtherCAT MainDevice Software unterstützt Linux auf x86-, x64-, ARM-, AArch64/ARM64- und RISC-V-Architekturen. Dank seiner Skalierbarkeit und modularen Bauweise kann EC-Master auf Low-End-Systemen von einem Cortex-M7-Mikrocontroller bis hin zu High-End-Intel® Core™ i7-CPUs betrieben werden.
Linux-System für EtherCAT optimieren
Schritt 1: Den richtigen Linux-Kernel wählen — PREEMPT_RT
Die Grundlage jedes Echtzeit-Linux-Systems für EtherCAT ist ein Kernel mit Echtzeit-Preemption-Unterstützung. Nach mehr als zwei Jahrzehnten Entwicklung wurde PREEMPT_RT offiziell in den Mainline-Linux-Kernel Version 6.12 integriert – es ist daher nicht mehr notwendig, einen Patch manuell einzuspielen und den Kernel neu zu kompilieren.
Viele Board- und Chip-Hersteller liefern inzwischen gebrauchsfertige RT-Kernel zusammen mit ihrer Hardware aus, darunter:
- Intel Linux
- NVIDIA Jetson Linux
- NXP i.MX Linux
- Qualcomm Linux
- Raspberry Pi Linux
- Texas Instruments Linux
Dies senkt die Einstiegshürde erheblich für Entwickler eingebetteter Systeme, die bisher eigene Kernel-Patches pflegen mussten.
Schritt 2: Linux für den Echtzeit-Betrieb konfigurieren
Zwei wichtige Kernel-Boot-Parameter helfen dabei, unerwünschte Latenzen durch das Energiemanagement zu eliminieren:
- cpuidle.off=1 — Deaktiviert das CPU-Idle-State-Management vollständig und verhindert, dass die CPU zwischen Aufgaben in Schlafzustände wechselt. Dadurch wird die Aufwachlatenz eliminiert, die Jitter in zyklischen Echtzeit-Aufgaben verursachen kann.
- cpufreq.off=1 — Deaktiviert die dynamische CPU-Frequenzskalierung. Die CPU läuft mit einer festen (typischerweise maximalen) Frequenz, wodurch Latenzspitzen durch Frequenzwechsel entfallen.
Diese Parameter sind entscheidend für konsistente Zykluszeiten in EtherCAT-Anwendungen.
Schritt 3: CPUs für Echtzeit-Aufgaben isolieren
Auf einem Mehrkern-System können Sie einen oder mehrere CPU-Kerne ausschließlich für Echtzeit-Aufgaben wie den EtherCAT-Job-Task reservieren und so verhindern, dass der Linux-Scheduler allgemeine Prozesse auf diesen Kernen platziert.
Die relevanten Kernel-Parameter sind:
- isolcpus=3 — Entfernt CPU 3 aus dem Load-Balancing des allgemeinen Schedulers. Der Kernel platziert keine regulären Prozesse auf dieser CPU, sofern nicht explizit angewiesen.
- irqaffinity=0-2 — Beschränkt die Hardware-Interrupt-Verarbeitung auf CPUs 0–2. CPU 3 bleibt frei von Interrupt-Last, was ihre Echtzeit-Reaktionsfähigkeit weiter verbessert.
Das Ergebnis: CPU 3 führt ausschließlich Ihren EtherCAT-Task mit minimaler Beeinflussung durch das restliche System aus.
Schritt 4: Die richtige Ethernet-Treiberarchitektur wählen
Hier hebt sich EC-Master unter Linux wirklich ab. Der Stack unterstützt vier verschiedene Architekturen zur Steuerung des Ethernet-Controllers, jede mit unterschiedlichen Kompromissen zwischen Einfachheit, Leistung und Hardware-Anforderungen.
Architektur 1: SOCK_RAW (Linux-Netzwerk-Stack)
Der einfachste Ansatz. EC-Master kommuniziert über den Standard-Linux-Netzwerk-Stack mittels Raw-Sockets (SOCK_RAW). Dies ist hardware-unabhängig und funktioniert auf nahezu jeder Linux-Distribution ohne Kernel-Modifikationen.
Kompromiss: Da der Linux-Netzwerk-Stack durchlaufen wird, sind CPU-Ausführungszeit und Frame-Jitter im Vergleich zu hardwarenäheren Ansätzen höher.
Architektur 2: acontis Echtzeit-Treiber (atemsys)
Der empfohlene Ansatz für produktive Echtzeit-Systeme. Der acontis-Treiber läuft vollständig im Userspace und greift direkt auf den Ethernet-MAC zu, wobei der Linux-Netzwerk-Stack vollständig umgangen wird. Dies wird durch ein kleines, GPL-lizenziertes Kernel-Modul namens atemsys ermöglicht, das dem Userspace-Treiber direkten Hardware-Zugriff gewährt.
Der Standard-Linux-Ethernet-Treiber muss vor der Verwendung dieser Architektur vom Adapter getrennt werden (über sysfs oder den Device Tree auf Embedded-Plattformen). Das atemsys-Kernel-Modul ist Open Source und verfügbar unter github.com/acontis/atemsys.
Kompromiss: Erfordert die Lizenzierung des Echtzeit-Treibers und die Kompilierung des atemsys-Kernel-Moduls. Liefert den besten Jitter und die beste Round-Trip-Performance.
Architektur 3: AF_XDP (XDP-Sockets)
Ein neuerer Ansatz, der das Linux eXpress Data Path (XDP)-Framework nutzt. EC-Master verwendet die AF_XDP-Socket-Schnittstelle, die eine bessere Leistung als SOCK_RAW bietet und dabei weiterhin auf den Standard-Linux-Ethernet-Treiber setzt.
Kompromiss: XDP erfordert zusätzliche Komponenten (libxdp und libbpf), und der Linux-Ethernet-Treiber muss ebenfalls XDP unterstützen, was bei vielen Treibern noch nicht der Fall ist. Zudem erfordert XDP eine sorgfältige Konfiguration.
Architektur 4: DPDK (Data Plane Development Kit)
Der acontis DPDK-Treiber (emlldpdk) nutzt das Data Plane Development Kit der Linux Foundation für hochleistungsfähige Paketverarbeitung. DPDK stellt eigene Hardware-Treiber bereit (unter vollständiger Umgehung der Linux-Ethernet-Treiber) für Controller wie Intel Gigabit und NXP ENETFEC.
Kompromiss: DPDK erfordert Ethernet-Controller-spezifische Treiber, die im Linux-Userspace laufen. Diese Treiber müssen parallel zu den Standard-Kernel-Space-Treibern entwickelt werden. Bisher haben nur wenige Hersteller solche Treiber für eine begrenzte Anzahl von Controllern veröffentlicht.
Leistungsmessung
EC-Master enthält die Demo-Anwendung EcMasterDemoSyncSm, die eine integrierte Leistungsmessung von drei kritischen Kennwerten bietet:
- Zykluszeit — Genauigkeit des durch CLOCK_MONOTONIC ausgelösten EtherCAT-Job-Tasks. Jitter hier spiegelt die allgemeine Echtzeit-Fähigkeit der OS-Konfiguration wider.
- Task-Dauer — Gesamte CPU-Zeit für EC-Master-Jobs und die Anwendung.
- Round-Trip-Zeit (TX+RX) — Die verstrichene Zeit vom Senden eines EtherCAT-Frames bis zum Empfang der Antwort. Dies ist die Summe aus Software-Ausführungszeit, DMA/NIC-Hardware-Latenz und OS-Scheduler-Overhead. Die maximale Round-Trip-Zeit bestimmt direkt die minimal erreichbare EtherCAT-Zykluszeit für eine gegebene Netzwerkkonfiguration.
Die Beispielanwendung EcMasterDemoSyncSm enthält eine Messfunktion zur Bestimmung der Zykluszeit und Round-Trip-Zeit. Die Messung kann mit dem Kommandozeilenparameter -perf aktiviert werden und gibt diese Daten regelmäßig aus:
0226810177: PerfMsmt 'Cycle Time ' (min/avg/max) [usec]: 977.3/1000.0/1023.8
0226810177: PerfMsmt 'Task Duration (JOB_Total + App)' (min/avg/max) [usec]: 71.4/ 72.8/ 100.4
0226810177: PerfMsmt 'JOB_Total ' (min/avg/max) [usec]: 3.7/ 4.6/ 31.4
0226810177: PerfMsmt 'JOB_ProcessAllRxFrames Duration' (min/avg/max) [usec]: 0.1/ 0.1/ 20.5
0226810177: PerfMsmt 'JOB_SendAllCycFrames Duration ' (min/avg/max) [usec]: 1.8/ 2.1/ 27.8
0226810177: PerfMsmt 'JOB_MasterTimer Duration ' (min/avg/max) [usec]: 0.5/ 0.8/ 21.1
0226810177: PerfMsmt 'JOB_SendAcycFrames Duration ' (min/avg/max) [usec]: 0.4/ 0.7/ 20.5
0226810177: PerfMsmt 'myAppWorkPd ' (min/avg/max) [usec]: 0.1/ 0.4/ 19.8
0226810177: PerfMsmt 'RoundTrip (TX+RX) ' (min/avg/max) [usec]: 58.7/ 68.3/ 87.8
Reale Leistungsergebnisse
Die folgenden Messungen wurden mit 7 Beckhoff EtherCAT-SubDevices, 512 Byte Prozessdaten, Distributed-Clocks-Synchronisierung und einer Ziel-Zykluszeit von 1000 µs durchgeführt. Alle Systeme liefen unter gleichzeitiger Last (stress + iperf3), um reale Produktionsbedingungen zu simulieren.
Jitter-Messergebnisse der Zykluszeit (Betriebssystem)
| System | Linux-Kernel | Linux-Treiber | acontis-Treiber | Avg [us] | Min [us] | Max [us] | Jitter [us] nach 24h |
| Intel PC i3-9100 mit I210 | 6.18.0-rt3 #1 SMP PREEMPT_RT | --- / atemsys | emllIntelGbe | 1000 | 978 | 1020 | 22 |
| Nvidia Jetson Orin AGX | 5.15.148-rt-tegra #1 SMP PREEMPT_RT | --- / atemsys | emllDW3504 | 1000 | 968.1 | 1034.8 | 34 |
| Nvidia Jetson AGX Thor Dev. Kit | 6.8.12-rt-tegra #1 SMP PREEMPT_RT | --- / atemsys | emllRtl8169 | 1000 | 987.9 | 1012.9 | 12.9 |
| Qualcomm IQ-9075 Evaluation Kit | 6.6.97-rt57-qli-1.6-ver.1.2.1-dirty #1 SMP PREEMPT_RT | --- / atemsys | emllDW3504 | 1000 | 865 | 1134 | 135 |
| RevPi Connect 5 | 6.12.56 #1 SMP PREEMPT_RT | --- / atemsys | emllGem | 1000 | 978.2 | 1024.9 | 24.9 |
| Raspberry Pi Compute Module 5 | 6.12.34-v8-16k+ #4 SMP PREEMPT_RT | --- / atemsys | emllGem | 1000 | 978 | 1017 | 22 |
Round-Trip-Zeit-Messergebnisse
| System | Treiber- Architektur |
Netzwerk- schnittstelle |
Linux-Treiber | acontis-Treiber | Avg [us] n. 24h |
Max [us] n. 30min |
Max [us] n. 6h |
Max [us] n. 24h |
| Intel PC i3-9100 | 1 | Intel i210 | igb | emllSockRaw | 71.8 | 185.8 | 213.4 | 213.7 |
| 2 | Intel i210 | ---/atemsys | emllIntelGbe | 68.3 | 83.3 | 85.5 | 89.7 | |
| 3 | Intel i210 | igb | emllXdp | 76.1 | 208.5 | 208.9 | 303.9 | |
| 4 | Intel i210 | igb | emllDpdk | 68.5 | 82.6 | 86.4 | 87.3 | |
| Nvidia Jetson Orin AGX | 1 | On-Chip DWC QOS | nvethernet | emllSockRaw | 389.6 | 1363.0 | 1363.0 | 1690.3 |
| 2 | On-Chip DWC QOS | ---/atemsys | emllDW3504 | 105.2 | 165.7 | 165.7 | 165.7 | |
| 1 | On-Chip DWC XGMAC | mgbe | emllSockRaw | 692.8 | 2781.2 | 2781.2 | 2781.2 | |
| 2 | On-Chip DWC XGMAC | ---/atemsys | emllDwXgmac | 78.0 | 85.7 | 133.8 | 136.5 | |
| Nvidia Jetson AGX Thor Dev. Kit | 1 | Realtek 8126 | enP2p1s0 | emllSockRaw | 110.4 | 713.6 | 791.1 | 833.9 |
| 2 | Realtek 8126 | ---/atemsys | emllRtl8169 | 65.6 | 75.6 | 80.1 | 84.6 | |
| 1 | On-Chip DWC XGMAC | mgbe | emllSockRaw | demnächst | demnächst | demnächst | demnächst | |
| 2 | On-Chip DWC XGMAC | ---/atemsys | emllDwXgmac | demnächst | demnächst | demnächst | demnächst | |
| Qualcomm IQ-9075 Evaluation Kit | 1 | On-Chip Synopsys IP | dwmac_qcom_ethqos | emllSockRaw | 314.4 | 1203.8 | 2082 | Frameverlust |
| 2 | On-Chip Synopsys IP | ---/atemsys | emllDW3504 | 81.4 | 94.1 | 101.4 | 102.4 | |
| RevPi Connect 5 | 1 | On-Chip Cadence MACB | macb | emllSockRaw | 113.3 | 1815.3 | 2041.1 | 2041.1 |
| 2 | On-Chip Cadence MACB | ---/atemsys | emllGem | 62.0 | 69.4 | 71.6 | 76.1 | |
| Raspberry Pi Compute Module 5 | 1 | On-Chip Cadence MACB | macb | emllSockRaw | 121.5 | 178.0 | 178.0 | 178.0 |
| 2 | On-Chip Cadence MACB | ---/atemsys | emllGem | 62.3 | 70.7 | 70.7 | 74.8 |
Fazit
Linux hat sich zu einer leistungsfähigen Echtzeit-Plattform für EtherCAT-MainDevice-Anwendungen entwickelt, insbesondere mit der Integration von PREEMPT_RT in Kernel 6.12. Produktionsreife Timing-Qualität erfordert jedoch mehr als nur einen RT-Kernel – es braucht eine sorgfältige Systemkonfiguration und die richtige Ethernet-Treiberarchitektur.
Für Ingenieure, die industrielle Automatisierungs-, Robotik- oder Bewegungssteuerungssysteme unter Linux entwickeln, bietet der acontis EC-Master in Verbindung mit dem atemsys-basierten Echtzeit-Ethernet-Treiber einen bewährten, leistungsstarken Weg zu deterministischer EtherCAT-Kommunikation auf einer breiten Palette von Hardware – von x86-Industrie-PCs bis hin zu ARM-basierten Embedded-Plattformen.