Class A - Master Synchronization (DCM)

Synchronization between master and slaves

Principles of Distributed Clocks

For the synchronization of the slave devices the Distributed Clocks (DC) feature of EtherCAT is used.
Referring to this the first DC-capable slave in the bus is defined to be the reference clock.
The time of the reference clock is distributed to all slaves by means of the EtherCAT master. Thus the EtherCAT Master cyclically sends a ARMW command in order to read the bus time stored in the appropriate register in the ESC (EtherCAT Slave Controller) of the clock master and to write this value into the corresponding registers of the DC slaves.
These DC slaves update their local time by means of an controller that is integrated in their ESC.
In order to assure the requested accuracy (values below 1us can be achieved), the delays of the EtherCAT frames between the particular slaves have to be compensated, in addition.
For each slave the time between when the frame which was sent and the time when it was received will be measured.
Afterwards, depending on the bus topology, the master calculates the delays between the slaves and writes the corresponding delay compensation values into the register 0x928 of the ESC.

The ESC controller's DC unit provides two digital output signals, SYNC0 and SYNC1.
Based on the bus time, these SYNC pulses, whose frequency generally correspond to the EtherCAT bus clock, are generated.
If the EtherCAT master for example sends the cyclical I/O data in a 1 ms rate, the SYNC pulse frequency usually also set to 1 kHz.
These SYNC signals on the slave side, on the one hand are available as a digital output signal (e.g. to activate slave hardware components) and on the other hand as an interrupt source for the slave software.

Referring to this it is obvious that all slaves have to be provided with the new data before the SYNC pulse is released.
To achieve this a minimum time lag between the arrival of new cyclical I/O data and the SYNC pulse must be guaranteed.

Master Synchronization

Typically, the EtherCAT master stack sends it cyclic I/O data based on a hardware timer in the controller hardware (e.g. a 8254 timer in an embedded x86 PC).
In case the system shall run in a 1kHz cycle, the 8254 timer as well as the slave timer that is responsible to generate the SYNC pulses are set to 1kHz.
But the 8254 timer and the slave timers both will not run at an exact cycle rate of 1kHz.
Effectively there will be a drift between these two timers and thus no constant distance between sending the cyclic I/O data in the master and generation of the SYNC pulses in the slaves can be achieved.
In order to control that distance at a well defined constant value, the EtherCAT master has to be synchronized with the DC clock master (that is the first DC capable slave in the bus).
This mechanism is called Distributed Clocks Master Synchronization (DCM).

It can be implemented in two different ways:
- re-adjustment of the physical timer (e.g. the 8254 timer) used in by hardware where the EtherCAT Master is executed (Master Shift)
- re-adjustment of the bus time of the DC clock master (Bus Shift)

The DCM Controller cyclically calculates the difference between the EtherCAT master time and the DC clock master time.
According to the set value (which is the distance of the SYNC pulse to the timer-interrupt in the master) the PI controller algorithm calculates the re-adjustment value.
When using “Master Shift” the re-adjustment value affects the physical timer of the EtherCAT Master (e.g. the 8254) whereas when using “Bus Shift” it affects register 0x920 of the DC Clock Master.

The Class A EtherCAT Master supports both methods (master shift as well as bus shift).
Synchronization of the master with the slaves is one of the most challenging features of EtherCAT.
Based on our experience we will advise customers concerning the right method to use for their given application and hardware.

Blue line: Start of cyclic task (Job-Task) driven by oscillator on master controller

Red line: DC-Sync signal based on System Time driven by oscillator in the slave.
Slave task is scheduled after DC-Sync is raised.

Without synchronizing both times, the EtherCAT frame (process data) may transmitted through the network while the slave task is scheduled.
This will cause the same issues as in free run mode.

Outputs (Master to Slave): Slave has no new data in one cycle, or will miss output data
Inputs (Slave to Master): Master has no new data, or will miss input data

DCM: Bus Shift Mode (default) Reference Clock controlled by Master/Controller Time

Bus Shift: DC Reference Clock follows the Master Clock/Timer

Adjust the Bus Time Register of the DC Reference Clock. The Ref.clock converge to this time.
The DC Ref. clocks time (EtherCAT system time) is distributed to the slaves behind the Ref.clock. The slaves will converge to the system time.

DCM: Master Shift Mode Master/Controller Time controlled by Reference Clock

Master Shift: Master Clock/Timer follows the DC Reference Clock

The timer frequency on Master controller is adjusted.
E. g., if the timer is to fast, slow down the timer for one cycle and then switch back to the original frequency.
Pro: Reduced DCM controller error
Pro: Quality independent from cyclic frame send time jitter
Con: Requires enhanced OS-Layer:
OsHwTimerGetInputFrequency(), OsHwTimerModifyInitialCount()
Con: Not available on all operating systems!

DCM Controller Set Value (default) “Controlling the time between cyclic frame and Sync0”

Minimum controller error depending on cyclic frame send time jitter
Frame send time depends on application execution time
App execution time should be nearly constant
The DCM controller is using a filter algorithm to deal with frame send time jitter
Works fine in most cases

DCM Controller Set Value (enhanced) “Controlling the time between start of cycle and Sync0”

Reduced DCM controller error
Quality independent from
cyclic frame send time jitter
Requires enhance OS-Layer
OsHwTimerGetInputFrequency()
OsHwTimerGetCurrentCount()
Not available on all operating systems!