EtherCAT als Antriebsbus

Spezielle Anforderungen aus der Antriebstechnik

• Zykluszeit
• Synchronität
• Gleichzeitigkeit

Typische Werte für benötigte Zykluszeiten liegen zwischen 1 und 4 ms bei zyklischer Lagevorgabe mit Lageregelung im Antrieb. Als ausreichende Anforderung an die Synchronität wird in der Antriebstechnik häufig eine Mikrosekunde angegeben.

Während die Synchronität den zeitlichen Jitter der Abarbeitung der Funktionen in den beteiligten Teilnehmern (Antriebe und Steuerung) angibt, definiert die Gleichzeitigkeit das Maß des zeitlichen Versatzes dieser Funktionen. Die Synchronität ist für den einzelnen Teilnehmer wichtig, damit eigene, unterlagerte Regel- kreise sich auf das zyklische Signal entsprechend genau synchronisieren können. Die Gleichzeitigkeit erlaubt zudem, verteilte Teilnehmer an einer gemeinsamen Aufgabe, mit der absolut selben Zeitbasis, arbeiten zu lassen.

Verteilte Uhren – Eigenschaften des EtherCAT-Slave-Controllers

EtherCAT nutzt zur Synchronisationsregelung einen Ansatz, der auf verteilten Uhren basiert: Alle Teilnehmer besitzen eine eigenständige Uhr, auf Basis derer die lokalen Zyklen und Ereignisse ablaufen. Entscheidend dabei ist, dass alle Uhren gleich schnell laufen und die gleiche Basiszeit besitzen. Eine im EtherCAT-Slave-Controller (ESC) integrierte Regelung stellt sicher, dass alle Uhren sich an einer Referenz-Uhr orientieren und unabhängig von Temperatur und Herstell-Toleranzen synchron laufen.

Multiprotokollfähigkeit

Weitere wichtige Kriterien eines Feldbussystems zur Unterstützung der Antriebstechnik sind das verwendete Kommunikationsprotokoll und -profil, die für die Kompatibilität und den effizienten Datenaustausch zwischen Steuerung und Antrieb verantwortlich sind. Statt hier das Rad neu zu erfinden, setzt EtherCAT in diesem Bereich auf bewährte Technik.

Die Kommunikationsanforderungen moderner Feldbusse (Prozessdaten, Parameterdaten, paralleles TCP/IP, Firmwareupdates, Routing zu unterlagerten Bussystemen, etc.) werden von keinem verfügbaren Protokoll allein unterstützt. Daher setzt EtherCAT auf Multiprotokollfähigkeit und führt die unterschiedlichen Protokolle in einer einheitlichen Mailbox zusammen. Dies erleichtert u. a., bestehende Geräte schnell und vollständig auf EtherCAT umzusetzen. Für die Antriebstechnik relevant sind die Protokolle CANopen over EtherCAT (CoE) und Servo Profile over EtherCAT (SoE), die es jeweils ermöglichen, die Vorteile von EtherCAT, bezüglich der Übertragungseigenschaften, mit den bewährten profilspezifischen Antriebsfunktionen zu kombinieren. Die Protokolle Ethernet over EtherCAT (EoE) und File Access over EtherCAT (FoE) ermöglichen optional z. B. einen Webserver im  Antrieb zu integrieren oder die Firmware bzw. Kurvenscheibentabellen effizient über den Bus auszutauschen.

Servo Profile over EtherCAT

Das Protokoll Servo Profile over EtherCAT (SoE) erlaubt die Nutzung des sehr bewährten, auf die anspruchsvolle Antriebstechnik spezialisierten und in der IEC 61491 genormten SERCOS-Geräteprofils . Der SERCOS-Servicekanal, und damit der Zugriff auf alle antriebsinternen Parameter und Funktionen, wird auf die EtherCAT-Mailbox abgebildet. Auch hier stehen sowohl die Kompatibilität zum bestehenden Protokoll (Zugriff auf Wert, Attribute, Namen, Einheiten etc. der SERCOS-Identifier) als auch die Erweiterungsmöglichkeit bezüglich der Datenlängenbeschränkung im Vordergrund. Die Prozessdaten, bei SERCOS in Form von AT- und MDT-Daten, werden wiederum mit den Mitteln des EtherCAT Slave - Controllers übertragen; das entsprechende Mapping erfolgt SERCOS-konform über die Identifier S-0-0015, S- 0-0016 und S-0-0024. Zur Synchronisierung werden – wie auch beim CoE-Protokoll – die bereits erläuterten Synchronisationseigenschaften des EtherCAT-Slave-Controllers genutzt. Diese umfassen – entsprechend qualitativ verbessert – auch die von Standard-SERCOS, so dass hier eine Umsetzung entsprechend leichtfällt. Die bereits erläuterte EtherCAT-Slave-State-Machine lässt sich ebenfalls gut auf die Phasen des SERCOS-Protokolls abbilden. „Pre-Operational“ entspricht SERCOS-Phase 2, und erlaubt Servicekanalkommunikation ohne Prozessdatenaustausch.„ Safe-Operational“ ist mit Phase 3 vergleichbar. Es findet die notwendige Synchronisierung statt, allerdings müssen bei EtherCAT bereits gültige Eingänge übertragen werden. „Operational“ entspricht wiederum exakt der Phase 4, in der der normale, zyklische Datenaustausch stattfindet. Die EtherCAT-Slave-State-Machine ist, wie der Name schon sagt, auf einen Slave bezogen und erlaubt somit – im Gegensatz zu SERCOS – einzelne Antriebe unabhängig von anderen Teilnehmern neu zu parametrisieren und in Betrieb zu nehmen.

Fazit

EtherCAT ist kein reiner Antriebsbus, erfüllt aber die entsprechenden Anforderungen mindestens um eine Größenordnung besser als bekannte, spezialisierte Systeme. Eine Trennung von Antriebs-, I/O- und Kommunikationsbus ist nicht mehr notwendig. Selbst anspruchsvollere Aufgaben, wie z.B. aus der Messtechnik, lassen sich integrieren und erlauben, neue Funktionalitäten mit klassischer Steuerungstechnik zu nutzen. Durch Verwendung bewährter Kommunikationsprofile ist eine Migration bestehender Geräte und Applikationen sehr einfach möglich. Insbesondere in der Antriebstechnik haben sich hier einige wenige Profile über Jahre hinweg entwickelt und bewährt. Außerdem können so die gesamte Toolkette und vorhandene Erfahrungen zur Parametrierung entsprechender Antriebe erhalten bleiben.

Verwendete IDNs

Dies ist ein Beispiel für den Aufbau und die Beschreibung einer IDN. Eine Auflistung und Beschreibung aller relevanten IDN´s finden Sie in der separaten IDN Beschreibung (chm).

S-0-0001, Control unit cycle time (TNcyc)

The control unit cycle time defines the cyclic intervals during which the control unit makes new command values available. The control unit cycle time shall be transferred from the master to the slave during CP2 and becomes active in the slave during CP3. The control unit cycle time should be an integer multiple of the communication cycle time. tNcyc = tScyc * n [n =1,2,3,4...]