Einrichtung - SyncUnits

SyncUnits müssen nur angelegt werden, wenn mit dem Ausfall eines EtherCAT Slaves gerechnet wird.

Zyklische Daten Mit der Einrichtung von SyncUnits kann nur die Kommunikation durch die zyklischen Daten beeinflusst werden, die azyklische Kommunikation z. B. per Mailbox wird immer vom System Manager verwaltet.

Standardmäßig versucht der System Manager alle IO-Daten in so wenig wie möglich Ethernet/EtherCAT-Frames zu integrieren. D.h. die maximale Framegröße von 1518 Byte je Ethernet Frame bzw. 15 Datagrammen wird möglichst ausgeschöpft. Dadurch wird eine effiziente und optimierte, den Feldbus wenig belastende Kommunikation erreicht.
Ein Datagramm ist Telegramm mit explizit einem Lese/Schreibauftrag. Ein Datagramm kann z. B. ein Lesebefehl über 2 Byte von einer analogen Eingangsklemme sein oder ein Schreibbefehl von 400 Byte Daten an 10 Servoantriebe.

In Abb. Aufbau Ethernet Frame mit EtherCAT Protokolldaten wir dies verdeutlicht: Der Ethernet Frame (Zeile 1) besteht aus Header (blau), Daten (gelb) und der Checksumme CRC (blau). Wenn der Ethernet Frame EtherCAT-Protokolldaten trägt, setzen sich diese Daten wiederum zusammen aus einem EtherCAT Header (rot) und den 1 bis 15 Datagrammen (grün). Diese wiederum bestehen jeweils aus Header und Daten und einem WorkingCounter (WC).

Der Working Counter ist dabei für das Kabelredundanzprinzip entscheidend. Der Working Counter ist eine 16 bit Zahl, die mit dem Wert "0" vom EtherCAT Master abgeschickt wird. Jeder EtherCAT Slave, der von diesem Datagramm schreibend oder lesend angesprochen wird, erhöht diese Zahl um 1, 2 oder 3, je nach Art des Zugriffs. Wenn das Datagramm die gesamte Konfiguration durchlaufen hat, kommt der Working Counter also mit einem Wert größer 0 zum Master zurück. Der Master wiederum hat einen Erwartungswert, denn ihm ist ja bekannt, wie viele Slaves dieses Datagramm bearbeitet haben müssen. Wenn der WC des Datagramms nicht mit dem Erwartungswert übereinstimmt, hat einer der angesprochenen Slaves seinen Arbeitsauftrag nicht aufgeführt. Es obliegt dann dem Master im Weiteren durch besondere Maßnahmen herauszufinden, welcher Slave betroffen ist und ob ggf. das Datagramm wiederholt werden soll.

Im TwinCAT System Manager (Reiter EtherCAT des EtherCAT Gerätes) ist der der aktuellen Konfiguration entsprechende aktuelle Frameaufbau der zyklischen Daten einzusehen.

Hier ein Beispiel mit einer kleinen Konfiguration:

Für die zyklischen IO-Daten ist hier nur ein Ethernet Frame im Einsatz (rot), der 3 EtherCAT Datagramme trägt, und zwar 2x LRD (LogicalRead) und 1x BRD (BroadcastRead).
Der Frame ist bei 59 Byte Daten 6.72 µs lang und nutzt damit 0.17% der Zykluszeit von 4 ms.

Das erste Datagramm hat einen erwarteten Working Counter von 1, das BRD-Kommando von 2, siehe Spalte WC.

In einer deutlich größeren Konfiguration wird der Frameaufbau komplexer:

Bei 1 ms Zykluszeit sind nun 3 Ethernet Frames unterwegs, die insgesamt 9 Datagramme tragen, mit jeweils erwarteten Working Countern von 3 bis 52. Diese Konfiguration nutzt im Übrigen bereits 35.94% der zur Verfügung stehenden Bandbreite von 100 MBit FastEthernet bei der Zykluszeit von 1 ms.

Anwendung auf die Kabelredundanz bei Slaveausfall

Wenn ein Datagramm mit einem "falschen" Working Counter zum Master zurückkommt, kann dieser im ersten Moment nicht feststellen, welcher Slave keine Daten lieferte - der Master muss also alle Eingangsdaten in diesem Datagramm für ungültig erklären. D.h. bei allen betroffenen Slaves geht die WC-Anzeige auf 1=invalidData.

Diese WC-Anzeige bildet der System Manager sofort beim Empfang aus den empfangenen Datagrammen für den jeweiligen Slave. In Abb. WC = 1 zeigt invalidData an ist dies für eine EL3162 dargestellt, die Eingangsdaten sind eingefroren, WcState = 1 und der State entsprechend der Bitbedeutungen von 0x0101 "Slave in INIT" und "Slave not present".

Bei Ausfall eines EtherCAT Slave, z. B. einer analogen Eingangsbox EP3174, würden somit auch andere Eingangsdaten verworfen, die durch den effizienten Frameaufbau im selben Datagramm liegen. Als Abhilfe kann anwenderseitig jeder Slave manuell einer sogenannten SyncUnit zugeordnet werden. Im Extremfall könnte jeder Slave eine eigene SyncUnit bekommen, mit den entsprechend nachteiligen Folgen für die Feldbuseffizienz bis hin zu hoher Busauslastung.

Der entsprechende Dialog ist über den Reiter EtherCAT zugänglich, s. Abb. TwinCAT Darstellung Frameaufbau - größere Topologie.

Ein Slave wird einer SyncUnit zugeordnet, s. Abb. Eintragen der SyncUnits bei Default-Frameaufbau

• durch Anklicken in der Spalte
• Eintragen des gewünschten Namens (beliebige Bezeichnung) bei SyncUnitNames

Wird eine Bezeichnung mehrmals vergeben, werden entsprechend auch die Slaves in einem Datagramm (logisch SyncUnit) betrieben.

Dadurch ergibt sich ein neuer Aufbau der zyklischen Ethernet-Frames nach Abb. Neuer Frameaufbau mit SyncUnits:

Teilnehmer, die nicht manuell gesetzt werden, werden weiterhin vom System Manager automatisch in Datagrammen zusammengefasst und ggf. mit <default> gekennzeichnet.

Typischerweise werden Baugruppen als eine eigene SyncUnit definiert, die über Ethernet-Kabelverbindung kommunizieren:

• Koppler EK11xx inkl. den anhängende Klemmen EL/ES/EMxxxx
• EP-Boxen
• AX-Antriebe
• ...

Fällt jetzt eine solche Station aus der Kommunikation, sind nur die Daten dieser SyncUnit ungültig, alle anderen Stationen nehmen unbeeinflusst am Datenaustausch teil.