CAN interface synchronization
The CAN interface cycle, which determines the CAN messages to be sent from the EtherCAT output data and enters the CAN messages received in the EtherCAT input data, is synchronized with the EtherCAT cycle. Synchronization takes place by default via the Sync Manager 2 event. In Fast CAN Queue mode, the EL6751 can also be operated in the Distributed Clocks mode; in this case, synchronization takes place via the SYNC0 and the SYNC1 events.
Buffered CAN Queue
The following flow chart shows the sequence of the CAN cycle in the Buffered CAN Queue mode.
When receiving the EtherCAT process data telegram, the SM2 event is generated by the EtherCAT slave controller, thus starting the CAN interface cycle. Now it is checked whether the TxCounter (entry 0x700z:01) in the EtherCAT output data has changed. If this is the case, NoOfTxMessages (entry 0x700z:03) indicates how many CAN messages have been transmitted in the EtherCAT output data. The first CAN Tx message (entry 0x700z:04) is sent if no transmission process is active, otherwise the CAN Tx message is inserted into the local CAN send queue. The other CAN Tx messages to be sent (entries 0x700z:05 - 0x700z:03+NoOfTxMessages) are inserted into the local CAN send queue and are automatically sent as soon as the last CAN message has been sent. After that, the TxCounter in the EtherCAT input data (entry 0x600z:01) is set to the value of the TxCounter in the EtherCAT output data (0x700z:01).
Subsequently, the CAN Rx messages received since the last increment of the RxCounter in the EtherCAT input data are entered in the EtherCAT input data, provided that the RxCounter in the EtherCAT output data (entry 0x700z:02) is equal to the RxCounter in the EtherCAT input data (entry 0x600z:02). Furthermore, the number of messages entered in the EtherCAT input data (entries 0x600z :05-0x600z:03+NoOfRxMessages) is written in the NoOfRxMessages (entry 0x600z:03) of the EtherCAT input data. Then the Transaction Number (0x600z:04) of the last transmitted CAN TxMessage is entered in the EtherCAT input data and the RxCounters (entry 0x600z:02) in the EtherCAT input data are incremented.
The CAN interface cycle ends with the update of the CAN status in the EtherCAT input data.
Fast CAN Queue
The Fast CAN Queue mode essentially differs in that there is no local CAN Rx queue and that it can also be synchronized with Distributed Clocks. The CAN Rx messages received are entered directly in the EtherCAT input data; there is no longer any local storage. So that the CAN receiver always has access to EtherCAT input data, the Fast CAN Queue works only in the 3-buffer mode of the Sync Managers.
The following flow chart shows the sequence of the CAN cycle in the Fast CAN Queue mode.
Synchronization with SM2 event
In the transmit direction, the sequence is identical to the Buffered CAN Queue mode. In the receive direction, the copying of the received CAN messages from the local Rx queue to the EtherCAT data input is dispensed with.
Synchronization with SYNC0/SYNC1 event
If distributed clocks are switched on, the CAN interface cycle would be started by the SYNC0 event. The sending of the first CAN Tx message is delayed until the SYNC1 event occurs, so that the sending of the first CAN Tx message takes place with a jitter of maximum 500 ns. The output delay time is the time between the SYNC1 event and the start of the CAN transmission of the first CAN Tx message in the CAN controller. The remaining sequence of the CAN interface cycle corresponds to that in the case of synchronization with SM2 event.
EtherCAT Update
In the EtherCAT Update it should be noted that the process data is usually transmitted with a LRW telegram. As a result of this, two cycles elapse in the task with which the EtherCAT master cycle is synchronized until the increment of the TxCounter is confirmed by the EL6751. This dead time can be avoided by selecting ‘Separate input update’ in the task, since in this case the EtherCAT output data are to be transmitted with a LWR telegram and the EtherCAT input data just before the start of the next task cycle with a LRD telegram. A second alternative would be to allow the task (and hence the EtherCAT master) to run with half the cycle time of the CAN interface cycle.