Synchronisierung

CAN Zyklus (Sync Multiplier = 1)

Das folgende Flussdiagramm zeigt den Ablauf des CAN-Zyklus, wenn mit jedem EtherCAT-Zyklus auch ein CAN-Zyklus durchgeführt wird (Sync Multiplier = 1 (0x1C32:02 == 0xF800:04 oder 0x1C32:02 == 0 (default) oder 0xF800:04 == 0)). Wenn die Zykluszeit des EtherCAT Masters (0x1C32:05) nicht in den StartUp-SDOs (oder dem Backup Parameter Storage Objekt) übertragen wurde und kein Distributed Clocks Modus eingestellt ist, ist 0x1C32:05 gleich 0 und somit der Sync Multiplier gleich 1.

Synchronisation mit SM2 (SM3) Event

Beim Empfang des EtherCAT Prozessdatentelegramms wird das SM2 Event (SM3, falls keine EtherCAT Output Data konfiguriert sind, also nur CANopen Slaves ohne CAN RxPDOs) vom EtherCAT Slave Controller generiert und damit der CAN-Zyklus gestartet. Falls synchrone CAN PDOs konfiguriert sind, werden diese am Anfang behandelt. Dabei wird nach dem Vorbereiten CAN-Sende PDOs zunächst die SYNC Message gesendet. Da manche CANopen-Slaves merkwürdig reagieren, wenn deren RxPDOs empfangen werden, bevor sie ihre TxPDOs gesendet haben, kann in 0xF800:0E ein Delay für die TxPDOs eingestellt werden. Nach dem Senden der SYNC Message wartet die EL6751 dann mit dem Senden weiterer CAN Messages, bis dieses Delay abgelaufen ist. Danach werden zunächst die synchronen RxPDOs gefolgt von den asynchronen RxPDOs (wenn sie sich geändert haben oder die Event-Time abgelaufen ist) gesendet. Wenn die synchronen RxPDOs gesendet wurden, wird noch auf das Ablaufen der Input Shift Time gewartet. Anschließend wird der Empfang der synchronen TxPDOs geprüft. Falls der Transmission Type einer TxPDO auf 1 gesetzt ist, erwartet die EL6751 eine RxPDO in jedem Zyklus bis zum Zeitpunkt T4, wenn dieses nicht empfangen wurde, wird der Node State des CANopen Slaves (0xF102:yy) für einen Zyklus auf 0x28 gesetzt. Wenn das nächste SM2 (SM3)-Event empfangen wird, bevor der CAN-Zyklus fertig ist, wird der Cycle Exceed counter (0x1C32:0B bzw. 0x1C33:0B) inkrementiert und ein CAN-Zyklus ausgelassen.

Falls nur asynchrone PDOs konfiguriert sind, ist der Ablauf wesentlich einfacher. Nach dem Empfang des SM2-Events werden die zu sendenden asynchronen CAN-RxPDOs ermittelt (Daten haben sich geändert oder Event-Time ist abgelaufen) und gesendet. Dann werden die seit Ende des letzten Zyklus empfangenen CAN TxPDOs in die EtherCAT Input Data kopiert. Falls die Sync Manager 2 und 3 im 1-Buffer-Mode eingestellt sind und die Input Shift Time ungleich 0 ist, wird mit dem Kopieren des Status und der Diagnose in die EtherCAT Input Data gewartet, bis diese Zeit abgelaufen ist. Das hat den Vorteil, dass innerhalb dieses Zeitfensters empfangene CAN TxPDOs direkt in die EtherCAT Input Data kopiert werden. Allerdings ist beim Einstellen der Input Shift Time darauf zu achten, dass die EtherCAT Input Data komplett kopiert werden können, bevor der nächste EtherCAT Zyklus beginnt, andernfalls wäre der Working-Counter nicht okay.

Synchronisation mit SYNC0/SYNC1 Event

Der Distributed Clocks Modus macht nur Sinn, wenn synchrone CAN PDOs vorhanden sind. In diesem Fall würde der CAN-Zyklus durch das SYNC0-Event gestartet. Vor dem Senden der SYNC Message wird auf das SYNC1-Event gewartet, so dass das Senden der SYNC Message mit einem Jitter von maximal 500 ns erfolgt. Der weitere Ablauf des CAN-Zyklus entspricht dem bei der Synchronisation mit SM2 Event.

CAN Zyklus (Sync Multiplier > 1)

Das folgende Flussdiagramm zeigt den Ablauf des CAN-Zyklus, wenn mit jedem n. EtherCAT-Zyklus (n > 1) auch ein CAN-Zyklus durchgeführt wird (Sync Multiplier > 1 (n*0x1C32:02 == 0xF800:04 und 0x1C32:02! = 0 und 0xF800:04! = 0)). Wenn kein Distributed Clocks Modus eingestellt ist, muss die Zykluszeit des EtherCAT Masters (0x1C32:02) in den StartUp-SDOs (oder dem Backup Parameter Storage Objekt) übertragen werden.

Synchronisation mit SM2 (SM3) Event

Während bei der Betriebsart Sync-Multiplier=1 die synchronen RxPDOs vollständig gesendet sein müssen, bevor die EtherCAT Input Data aktualisiert werden, kann sich das im Betrieb mit Sync-Multiplier=n über n EtherCAT-Zyklen hinziehen. Der Beginn des CAN-Zyklus ist noch gleich wie beim Betrieb mit Sync-Multiplier=1. Nachdem das TxPDO-Delay abgelaufen ist (in dem Flussdiagramm ist davon ausgegangen, dass das TxPDO-Delay kleiner als die Input Shift Time ist), wird mit dem Senden der synchronen RxPDOs begonnen. Wenn währenddessen die Input Shift Time abläuft, werden die EtherCAT Input Data aktualisiert, in denen die neuesten Daten aller bis zu diesem Zeitpunkt empfangenen TxPDOs enthalten sind. Danach wird jeweils auf das nächste Event gewartet, bis der letzte EtherCAT-Zyklus innerhalb des CAN-Zyklus erreicht ist. In den mittleren EtherCAT-Zyklen erhalten die Daten der zu sendenden asynchronen RxPDOs immer den aktuellsten Wert, während die Daten der zu sendenden synchronen RxPDOs nur im ersten EtherCAT-Zyklus aktualisiert werden. Im letzten EtherCAT-Zyklus werden nach Ablauf der Input Shift Time noch die synchronen RxPDOs geprüft (wie beim Betrieb mit Sync-Multiplier=1). Falls nur asynchrone PDOs konfiguriert sind, ist ein Sync-Multiplier > 1 unwirksam.

Synchronisation mit SYNC0/SYNC1 Event

Wenn Distributed Clocks eingeschaltet sind, würde der CAN-Zyklus durch das SYNC0-Event gestartet. Vor dem Senden der SYNC Message wird auf das SYNC1-Event gewartet, so dass das Senden der SYNC Message mit einem Jitter von maximal 500 ns erfolgt. Der weitere Ablauf des CAN-Zyklus entspricht dem bei der Synchronisation mit SM2 Event.