Industry Applications #05
EtherCAT and Multi-Axis Synchronization: Why Distributed Clocks Matter
Two axes need to travel together along a 45-degree diagonal. The X and Y axes each move at 200 mm/s, and the controller sends the commands at the same time, but the X axis drive receives its command 100 µs later than the Y axis.
As a result, the X axis position always lags by 20 µm, and the actual path deviates from the ideal diagonal by about 14 µm (20 µm ÷ √2):
Δ = v × Δt = 200 mm/s × 100 µs = 0.02 mm
On a cutting machine, those 14 µm or so are carved straight into the workpiece; on a measurement station, they become measurement error directly. Timing error in the communication layer turns proportionally into spatial error, which is why multi-axis systems have to talk about synchronization.
1. What synchronization error turns into
Crossing speed with synchronization error makes the orders of magnitude obvious:
| Motion speed | 1 ms sync error | 100 µs sync error | 1 µs sync error |
|---|---|---|---|
| 100 mm/s | 100 µm | 10 µm | 0.1 µm |
| 200 mm/s | 200 µm | 20 µm | 0.2 µm |
| 500 mm/s | 500 µm | 50 µm | 0.5 µm |
If the mechanism is built to the micrometer but the communication layer works in milliseconds, the accuracy of the whole system stops at the millisecond layer.
This also explains a common puzzle: the servos are well chosen, the mechanism is stiff enough, single-axis positioning measures beautifully, yet with two axes moving together it simply cannot produce an arc or a diagonal. The problem is not in the axes but in the two axes not being aligned on "when to start moving".
2. EtherCAT's first key: processing on the fly
When standard Ethernet switches are cascaded, at each stage a packet is usually received completely and checked before being forwarded, and each node's data occupies a packet of its own. The more nodes in the chain, the faster the delay accumulates.
EtherCAT works completely differently: the frame does not stop. A single Ethernet frame passes through all the slaves in sequence, and as the frame "passes through" each slave, the slave's hardware reads its own few bytes and writes its return data into the frame on the spot, and the frame moves on to the next station.
3. The second key: distributed clocks
Fast frames only solve "the data arrives promptly enough". But each axis still receives its data at a different moment: there is inherently a propagation time difference between the first and fourth stations.
Distributed clocks (DC) solve exactly this. The method:
- The clock of one slave is chosen as the reference clock
- The master measures the propagation delay of the frame's round trip to each station, and calculates each station's offset from the reference clock
- The offset compensation values are written to each station, and the drift of each station's clock is continuously corrected during operation, so all nodes share the same time base
- A motion command is no longer "do it on receipt" but "do it at time T"
Point 4 is the heart of the matter. Since everyone's clocks are synchronized, it no longer matters whether data arrives early or late: everything waits until the specified moment and executes at the same time.
According to the EtherCAT Technology Group's specification, jitter between nodes is well below 1 µs. Back to the table at the start: a 1 µs synchronization error at 200 mm/s causes a position deviation of only 0.2 µm, already below the error of the mechanism itself.
4. How to choose between the three approaches
| Approach | Sync capability | Recommended axes | Suited to |
|---|---|---|---|
| Pulse/direction | Relies on the control card's hardware output; good synchronization but a lot of wiring | 1–8 | Few axes, short wiring distances, budget-sensitive |
| CANopen | Communication cycles mostly at the millisecond level; with SYNC message synchronization, jitter of tens to hundreds of µs | 4–16 | Point-to-point positioning, loading and unloading, fixture actions |
| EtherCAT | With DC enabled, jitter well below 1 µs | 8 or more | Interpolated motion, gantry synchronization, on-the-fly capture, multi-axis coordination |
We suggest working through the decision in this order:
- Is coordinated motion between axes needed? (interpolation, gantry synchronization, electronic cams): with few axes and short wiring, a pulse control card's hardware interpolation can do it; with many axes, synchronization across modules, or axes to be added later, look at EtherCAT first
- No coordination, just independent positioning? Up to eight axes, pulse control is simplest (a single 4-axis or 8-axis control card is enough); beyond that, switch to a fieldbus (CANopen or EtherCAT) to save wiring
- Will axes be added later? Adding an axis to EtherCAT means connecting one cable; adding one with pulse control means another card and another bundle of wires
5. Beyond synchronization: aligning with image capture
Multi-axis synchronization solves "between axes". A measurement station has another synchronization problem: between the axes and the camera.
With the stage moving at 100 mm/s, a trigger signal that is 1 ms late makes the image correspond to a position 100 µm away, and the size of the offset depends on the current speed; if the trigger delay also has jitter, it is even less of a fixed offset that can be compensated afterwards.
There are two solutions, both calculated in section 2.5 of the industrial automation page: trigger the camera directly from encoder position with a motion control card's position compare output, or bring the camera trigger module into the same time base with EtherCAT distributed clocks. The advantage of the latter is that the whole line runs on a single time base, with no need to synchronize two separate systems.
Closing: first find which layer the error comes from
"We cannot reach the accuracy" is a symptom, not a cause. What really needs doing is to take the error apart:
- Even single-axis positioning is inaccurate → a mechanism or servo tuning problem; see inertia ratio and torque
- Single axes are accurate, multiple axes are not → a synchronization problem; this article
- Accurate when stationary, inaccurate in motion → an image trigger problem; see position compare output and DC
- Accurate just after power-up, inaccurate after running for a while → thermal drift; look at the mechanism's materials and temperature control
The four causes have completely different solutions, and they do not substitute for one another. Better servos do not solve a synchronization problem, and switching to EtherCAT does not fix a mechanism that is not stiff enough. Confirm which layer it is first, then decide where to spend the money.
EtherCAT® is a registered trademark and patented technology licensed by Beckhoff Automation GmbH, Germany; specifications cited in this article are from public material of the EtherCAT Technology Group.
