The servo tuning looks correct on a single axis. Put two or more axes on an interpolated path and a contour error appears that no amount of proportional gain fixes. The error does not correlate with load or speed — it scales with the number of active axes. That pattern points to a timing problem at the coordination layer, not a tuning problem at the axis level, and the place to look is the synchronisation mechanism built into EtherCAT (Ethernet for Control Automation Technology) itself.
EtherCAT provides a dedicated mechanism for this: Distributed Clocks (DC). Understanding how DC works, what it actually fixes, and what it leaves untouched is the difference between spending a week adjusting servo parameters and spending ten minutes correcting a clock configuration.
What are EtherCAT Distributed Clocks?
EtherCAT Distributed Clocks is a hardware-assisted synchronisation mechanism defined in the EtherCAT specification ETG.1000.6. It establishes and maintains a common reference time across every slave on a segment, with synchronisation jitter below 1 µs, regardless of how many slaves the segment carries or how long the cables run. That figure is a property of the EtherCAT protocol, achieved through a combination of hardware timestamping in each slave’s ASIC (Application-Specific Integrated Circuit) and a continuous correction loop run by the master.
The mechanism is not a best-effort approximation. It is a deterministic, closed-loop correction embedded in the EtherCAT frame processing path, running at the physical layer of every DC-capable slave, without any external timing infrastructure. The EtherCAT Technology Group (ETG) defines DC as part of the core standard, not as an optional extension.
Why a fast network is not enough
EtherCAT frames travel through the segment at close to the speed of light in copper: roughly 5 ns per metre of cable, plus approximately 1 µs of processing time per slave for frame forwarding. A 32-node segment with standard cabling may accumulate 30 µs or more of propagation delay between the first slave and the last.
From the master’s perspective, a single Process Data Object (PDO) frame carries updated position references for every drive simultaneously. The master sends one frame; every drive sees it. The problem is when each drive acts on it.
In a system without synchronisation, each drive applies the position reference the moment its PDO data is available — which is the moment the frame passes through it. The drive at node 32 is acting on data that the drive at node 1 received 30 µs earlier. Both drives believe they are following the same trajectory. They are not. They are executing two different instants of that trajectory, offset by the propagation delay, and the motion planner has no way to see this because the positions it reads back are also offset in time.
For a single axis or non-interpolated point-to-point moves, this offset is harmless. For interpolated contouring — a laser cutting an arc, a gantry tracing a thread path, an assembly machine coordinating two orthogonal axes — the offset translates directly into a position mismatch at each interpolation step. That mismatch accumulates into contour error. Increasing the position loop gain makes it worse: the controller reacts faster to an error it cannot source, introduced by a timing skew it cannot observe.
How Distributed Clocks compensate for propagation delay
DC solves this by separating two things that are coupled in a naive implementation: the moment the PDO frame arrives at a slave, and the moment the slave acts on it. The mechanism has four stages.
Reference clock election
One DC-capable slave is designated the reference clock. By default this is the first DC-capable device in the chain, though the master can override the selection. This slave’s internal 64-bit counter becomes the shared network time. All other slaves synchronise their own counters to it. The master also tracks the reference clock continuously and derives its own view of network time, which it uses to schedule PDO transmissions at precisely the right phase.
Propagation delay measurement
On initialization, the master sends a broadcast write to all slaves in a single frame. Each slave latches the time of receipt into a dedicated register as the frame passes through. The master reads the latched values on the return trip. By comparing the receive times of consecutive slaves for both the outgoing and return passes, the master computes the one-way propagation delay from the reference clock to each slave, with nanosecond resolution. These per-slave delay values are stored and used to calculate the clock offset each slave must apply to its local counter.
Offset and drift correction
Crystal oscillators are not identical. Even two oscillators nominally rated at the same frequency will drift apart over time. The master periodically reads each slave’s local time, compares it to the reference time corrected for the measured propagation delay, and writes an offset correction back to the slave. The slave applies this correction smoothly — not as an instantaneous jump, which would cause a transient in the drive’s control loop — but as a gradual adjustment to its local counter increment rate. Over a few cycles, every slave’s local clock converges on the reference. The correction interval is configurable; a shorter interval tracks drift more aggressively at the cost of more bus bandwidth.
SYNC0 generation
Once its local clock is aligned, each slave generates a SYNC0 pulse at a period and phase derived entirely from its corrected local counter. The pulse is internal to the slave — it travels on no wire. It is a signal from the slave’s EtherCAT ASIC to the slave’s application processor or drive DSP (Digital Signal Processor). SYNC0 fires at the configured interval, aligned to the reference clock in phase. The PDO frame can arrive at any point in the cycle. The drive waits for SYNC0 before it acts on the data the frame carried.
The result: every DC-synchronous drive on the segment updates at the same absolute moment in network time, regardless of its position in the chain or the cable length upstream of it.
From SYNC0 to the current loop
Understanding where SYNC0 fits inside the drive clarifies what “synchronised” means from the application’s perspective.
CiA (CAN in Automation) 402-compatible servo drives support three synchronisation modes: free-run, SM (Sync Manager) -synchronous, and DC-synchronous. In free-run mode, the drive’s internal timer runs independently. In SM-synchronous mode, the drive acts when the EtherCAT Sync Manager signals that PDO data has arrived. In DC-synchronous mode, the drive’s interpolation timer is reset on the SYNC0 edge, so the current reference is applied at a moment defined by network time, not by frame arrival time.
For interpolated multi-axis motion, DC-synchronous is the only mode that delivers the “same moment” semantics the motion planner assumes when it calculates the next set of axis positions.
The synchronisation mode is typically configured as an object in the drive’s object dictionary during startup, usually object 0x1C32 (Output Sync Manager parameters) and 0x1C33 (Input Sync Manager parameters). A common commissioning error is enabling DC in the master configuration while leaving individual drives in free-run or SM-synchronous mode. The master and the drives will initialise without error. The contour error will persist.
What Distributed Clocks do not solve
DC removes timing skew at the network layer. Several other error sources remain, and it is worth being clear about each.
Master cycle jitter. DC synchronises slave output to a shared network time. It does not improve the master’s own cycle regularity. If the master misses its PDO transmission window by 50 µs because the host operating system delayed its task, all slaves receive stale data 50 µs late. SYNC0 will then apply that stale data at the next correct moment in network time. Master jitter is a function of the real-time behaviour of the host OS and the EtherCAT master stack, not of the DC mechanism. A master running on a non-real-time OS with DC enabled is not necessarily better than a master on a well-tuned real-time OS without it.
Mechanical delay. DC synchronises the moment the current reference changes at the power stage. It does not compensate for motor response time, coupling elasticity, belt stretch, or the bandwidth limit of the mechanical system. A set of drives acting at precisely the same electrical moment is still constrained by the physics between shaft and tool.
Non-DC slaves. Simple digital I/O devices, many sensors, and some actuators run in free-run or SM-synchronous mode. They operate asynchronously alongside DC-capable devices. They neither benefit from DC nor degrade it for their neighbours. This is legal and common.
Crystal quality. The SYNC0 alignment depends on the stability of each slave’s local oscillator between master corrections. Slaves with low-quality crystals drift back out of phase quickly, and the master must work harder to maintain synchronisation. Industrial servo drives handle this without issue. Low-cost generic EtherCAT I/O modules sometimes do not, and the symptom is a System Time Difference register value that oscillates rather than converging.
Signal integrity. Long cable runs add propagation delay, which DC measures and compensates. They also add differential noise and, on poorly terminated segments, signal reflections. DC corrects for delay; it has no effect on signal integrity problems. A segment with excessive cable-induced errors will lose frames, and no synchronisation mechanism recovers a lost frame.
Choosing the right synchronisation mode
Not every application justifies the added configuration work DC requires, and applying it where it is not needed adds complexity without benefit.
| Mode | What triggers the slave update | Axes in sync? | When to use it |
|---|---|---|---|
| Free-run | Slave’s own internal timer; PDO arrival is irrelevant | No | Digital I/O, sensors, non-time-critical actuators |
| SM-synchronous | Sync Manager event on PDO arrival | Partially (linked to frame arrival, not to a shared time) | Single-axis point-to-point, legacy slaves, low-speed applications |
| DC-synchronous (SYNC0) | Hardware SYNC0 pulse derived from corrected local clock | Yes, to better than 1 µs | Interpolated multi-axis motion, any servo requiring jitter below 10 µs |
Use DC-synchronous when two or more axes must move in coordination, when contouring tolerance is tighter than a few micrometres, or when the drive’s data sheet specifies DC as a requirement for achieving the rated position repeatability.
Use SM-synchronous for single-axis point-to-point applications where simultaneity with other axes is not required. The configuration is simpler and the result is adequate for many machines.
Use free-run for I/O, sensors and actuators where the control loop does not require deterministic timing at the microsecond level.
One practical note: DC requires that the master’s DC correction task runs on schedule, every cycle. If the master’s real-time task is late, the correction value it writes is stale, and the slaves drift until the next correction arrives. This means that DC performance is an indirect measure of master cycle regularity, not just of the protocol itself.
Frequently asked questions
What is the difference between EtherCAT Distributed Clocks and IEEE 1588?
Both are clock synchronisation protocols and both achieve sub-microsecond synchronisation. The architectural difference is where the timestamping happens. IEEE 1588 PTP (Precision Time Protocol) runs over standard Ethernet, with timestamps taken in software or, with hardware-timestamping NICs (Network Interface Controllers), at the MAC (Media Access Control) layer. EtherCAT DC timestamps are taken in the slave's EtherCAT ASIC as the frame passes through, at the physical layer, with no software path involved. EtherCAT DC achieves its performance without any external timing infrastructure, as long as the slaves support it. IEEE 1588 is used where DC is not available — across separate EtherCAT segments joined by a switch, or in mixed-protocol systems that include non-EtherCAT devices.
Does every EtherCAT slave need to support Distributed Clocks?
No. Non-DC slaves run in free-run or SM-synchronous mode alongside DC-capable devices without any special configuration. The master activates DC only for the slaves that declare DC support in their ESI (EtherCAT Slave Information) file and that require it for their application. Mixing is standard: a motion segment with ten DC-synchronous servo drives will typically also carry digital I/O modules running in free-run mode on the same segment.
Does SYNC0 use any network bandwidth?
No. SYNC0 is a hardware interrupt generated internally by the slave's EtherCAT ASIC at a period and phase derived from the slave's local corrected clock. It does not travel on the wire. It is a signal between two chips inside the same slave device. The only DC-related bus traffic is the correction value the master writes to each slave periodically, which is a small register write folded into the existing PDO frame — no extra frames, no extra bandwidth.
How do I verify that Distributed Clocks are working correctly?
Read the System Time Difference register (ESC register 0x092C) from each DC-capable slave using your diagnostic tool. A well-synchronised segment shows values within a few hundred nanoseconds of zero across all DC-capable nodes. Values consistently above 1 µs indicate a synchronisation problem: start by checking whether the master's DC correction task is running on schedule, then check the slave's crystal quality and whether the configured correction interval is appropriate. Most open-source and commercial EtherCAT diagnostic tools can read this register continuously and plot it over time, which makes drift problems immediately visible.
What happens if the master misses a cycle when DC is active?
Each DC-capable slave generates its SYNC0 pulse independently from its local clock, regardless of whether the master sent a PDO that cycle. The slave will fire SYNC0 on schedule and apply whatever data it holds — which will be the data from the previous cycle. The servo loop will run, but with a stale position reference. The drive will not fault, and the master will not see an immediate error, but the motion trajectory will deviate for that cycle. In a well-configured system, missed cycles are rare. If they are frequent, the correct response is to improve master real-time behaviour, not to disable DC.
Both are clock synchronisation protocols and both achieve sub-microsecond synchronisation. The architectural difference is where the timestamping happens. IEEE 1588 PTP (Precision Time Protocol) runs over standard Ethernet, with timestamps taken in software or, with hardware-timestamping NICs (Network Interface Controllers), at the MAC (Media Access Control) layer. EtherCAT DC timestamps are taken in the slave’s EtherCAT ASIC as the frame passes through, at the physical layer, with no software path involved. EtherCAT DC achieves its performance without any external timing infrastructure, as long as the slaves support it. IEEE 1588 is used where DC is not available — across separate EtherCAT segments joined by a switch, or in mixed-protocol systems that include non-EtherCAT devices.
No. Non-DC slaves run in free-run or SM-synchronous mode alongside DC-capable devices without any special configuration. The master activates DC only for the slaves that declare DC support in their ESI (EtherCAT Slave Information) file and that require it for their application. Mixing is standard: a motion segment with ten DC-synchronous servo drives will typically also carry digital I/O modules running in free-run mode on the same segment.
No. SYNC0 is a hardware interrupt generated internally by the slave’s EtherCAT ASIC at a period and phase derived from the slave’s local corrected clock. It does not travel on the wire. It is a signal between two chips inside the same slave device. The only DC-related bus traffic is the correction value the master writes to each slave periodically, which is a small register write folded into the existing PDO frame — no extra frames, no extra bandwidth.
Read the System Time Difference register (ESC register 0x092C) from each DC-capable slave using your diagnostic tool. A well-synchronised segment shows values within a few hundred nanoseconds of zero across all DC-capable nodes. Values consistently above 1 µs indicate a synchronisation problem: start by checking whether the master’s DC correction task is running on schedule, then check the slave’s crystal quality and whether the configured correction interval is appropriate. Most open-source and commercial EtherCAT diagnostic tools can read this register continuously and plot it over time, which makes drift problems immediately visible.
Each DC-capable slave generates its SYNC0 pulse independently from its local clock, regardless of whether the master sent a PDO that cycle. The slave will fire SYNC0 on schedule and apply whatever data it holds — which will be the data from the previous cycle. The servo loop will run, but with a stale position reference. The drive will not fault, and the master will not see an immediate error, but the motion trajectory will deviate for that cycle. In a well-configured system, missed cycles are rare. If they are frequent, the correct response is to improve master real-time behaviour, not to disable DC.
Implementing EtherCAT DC on your machine?
Distributed Clocks solves the synchronisation problem. Whether the rest of your EtherCAT architecture — master selection, cycle time, cable topology, drive configuration — is set up correctly is a different question. If you are commissioning a multi-axis machine on EtherCAT and want a second opinion on your timing configuration, the Motax Solutions engineering team works with machine builders on exactly these problems. Get in touch with the specifics of your application.