Distributed-Clocks
Die Synchronisation der Teilnehmer wird bei EtherCAT in den Teilnehmern durchgeführt. Hierfür wird die Uhrzeit des ersten zu synchronisierenden Teilnehmers zyklisch an alle anderen Synch-Slaves verteilt. Dadurch haben fast alle Teilnehmer die gleiche Uhrzeit: Ein Unterschied zur Masteruhr entsteht noch aus der Verzögerungszeit durch die Leitungen und durch die Slave-Durchlaufzeiten. Dieser Unterschied kann aber – unterstützt durch die ESCs – hochgenau ausgemessen werden, da jeder Frame den Teilnehmer einmal in der Hinrichtung und später auch wieder auf dem Rückweg durchläuft. Damit ist die Verzögerungszeit genau zu bestimmen und kann individuell in den Teilnehmern berechnet und als Offset ausgeglichen werden. Messungen ergaben eine Synchronisationsgenauigkeit von ~20ns bei 300 verteilten Knoten und 120m Leitungslänge. Da der maximale Jitter aber von vielen Randbedingungen abhängt (z.B. Anzahl Knoten, Leitungslänge, Temperaturverlauf etc.), wird er konservativ mit <<1µs angegeben. Hochauflösende verteilte Uhren dienen aber nicht nur der Synchronisierung, sondern können auch exakte Informationen zum lokalen Zeitpunkt der Datenerfassung liefern. Steuerungen berechnen beispielsweise häufig Geschwindigkeiten aus nacheinander gemessenen Positionen. Speziell bei sehr kurzen Abtastzeiten führt schon ein kleiner zeitlicher Jitter in der Wegerfassung zu großen Geschwindigkeitssprüngen. Konsequenterweise werden mit EtherCAT auch Timestamp-Datentypen eingeführt. Mit dem Messwert wird die hochauflösende Systemzeit verknüpft die große Bandbreite von Ethernet macht das möglich. Da bei EtherCAT hochgenau abgeglichene verteilte Uhren zum Einsatz kommen, muss der Kommunikationszyklus nicht absolut äquidistant sein – ein kleiner Jitter ist hier erlaubt. Damit kann der EtherCAT-Master auf spezielle Hardware verzichten und als reine Softwarelösung implementiert werden.
Konfiguration
Die Konfiguration eines EtherCAT-Netzwerkes ist sehr einfach. Dies trifft insbesondere auf die Netzwerkplanung zu: Da die Prozessdaten-Performance nicht von den ausgewählten Geräten abhängt und auch die Topologie praktisch keinen Einfluss hat, ist hier kaum etwas zu berücksichtigen. Ebenso kann das bei vielen Feldbussen und Industrial-Ethernet-Lösungen erforderliche \’Netzwerk-Tuning\‘ fast immer vollständig entfallen: EtherCAT ist mit den Default-Einstellungen meist schnell genug. Zum Zugriff auf Konfigurations- und Serviceparameter der Teilnehmer ist das CANopen-Kommunikationsprofil auf EtherCAT abgebildet. CANopen-Geräteprofile stehen für eine große Vielfalt von Geräteklassen zur Verfügung. EtherCAT kann die gleichen Kommunikationsmechanismen bereitstellen, wie sie von CANopen bekannt sind: Objektverzeichnis, PDO (Prozess-Daten-Objekte) und SDO (Service-Daten-Objekte) – selbst das Netzwerkmanagement ist vergleichbar. Beliebige Ethernet-Protokolle werden bei EtherCAT volltransparent getunnelt – und damit wird ein Verfahren angewendet, das bei Ethernet und den Internet-Technologien üblich ist: Jedes Modem tunnelt Ethernet-Frames ebenso wie WLAN; VPN nutzt diese Technik ebenso wie TCP/IP selbst.
Implementierung
EtherCAT verwendet Standard-Ethernet-Controller dort, wo es tatsächlich Kosten spart: im Master. Da in der Regel nur ein Ethernet-Frame je Zyklus abgeschickt werden muss, kann auf Kommunikations-Coprozessoren verzichtet werden. Es sind also keine Master-Einsteckkarten erforderlich, der On-Board-Ethernet-Controller oder die günstige Standard-NIC-Karte genügen. Im Slave-Gerät kommt ein kostengünstiges ASIC oder FPGA zum Einsatz. Für einfache Geräte ist kein zusätzlicher µ-Controller erforderlich. Bei komplexeren Geräten ist die Kommunikations-Performance bei EtherCAT nahezu unabhängig von der Leistungsfähigkeit des verwendeten Controllers die Anschaltung wird entsprechend günstig. Die Kommunikationsfunktionalität im Slave-Gerät ist in Hardware implementiert – damit entfallen aufwändige Stack-Integration und -Kosten. Ein kostengünstiges Evaluierungs-Kit samt Slave-Beispielcode steht zur Verfügung, ebenso ein Master-Beispielcode.
