EtherCAT distributed clocks are the mechanism that lets every device on an EtherCAT network share an almost identical sense of time, accurate to well under a microsecond. Rather than relying on a central controller to command each slave at exactly the right instant, distributed clocks give each slave its own synchronised clock so they can all act in step on their own. This is achieved by picking one slave as the reference, measuring the tiny delays as signals travel down the network, correcting for clock drift, and firing precise SYNC signals. That tight, shared time base is what makes coordinated multi-axis motion and cleanly time-stamped data possible.
EtherCAT distributed clocks in one line: EtherCAT distributed clocks are a synchronisation feature that gives every capable slave on the network a shared clock accurate to sub-microsecond levels. The first distributed-clock-capable slave becomes the reference clock, the master measures propagation delays and drift between slaves, and each slave fires SYNC0 or SYNC1 signals precisely in step, so devices such as motion axes can act at exactly the same moment.
The scheme starts by choosing a reference clock. The first slave on the network that is capable of distributed clocks is designated the reference, and its internal clock becomes the master time that everyone else aligns to. Every other distributed-clock-capable slave has its own local clock, and the goal is to make all those local clocks agree with the reference as closely as possible, so that when they each act on their shared time, they act together.
Two corrections make this accuracy possible. First is propagation delay compensation: because it takes a small but real amount of time for a signal to travel down the cable and through each device, a slave further along the network naturally sees events slightly later. The system measures these delays for each slave and offsets each local clock accordingly, so a given instant in time means the same thing everywhere on the segment. Second is drift compensation: no two crystals run at exactly the same rate, so clocks slowly diverge, and the mechanism continuously nudges each local clock to keep it locked to the reference.
Once the clocks agree, each slave can generate precise timing signals from its own local clock, commonly called SYNC0 and sometimes a second SYNC1. These are hardware pulses that fire at a configured instant, and because every slave's clock is aligned, those pulses happen simultaneously across the network. A slave uses its SYNC signal to latch inputs or apply outputs at exactly the planned moment, so the whole segment behaves as if driven by one shared heartbeat rather than by whenever each device happened to be addressed.
The classic reason to use distributed clocks is coordinated multi-axis motion. When several servo axes must move in a precise relationship, for example tracing a path together or keeping a mechanical linkage in sync, it is not enough for each axis to receive its command reasonably quickly; they must all apply their commands at the same instant. Even small differences in timing between axes translate into position errors and rough motion. Distributed clocks give every axis the same SYNC pulse, so they update together and the coordinated movement stays smooth and accurate.
Without a shared time base, the alternative is to hope that command frames arrive close enough together, which introduces jitter and limits how tightly axes can be coordinated. Distributed clocks remove that uncertainty by decoupling the moment of action from the moment of communication: the data can travel over the network at slightly different times, but each slave waits for its synchronised SYNC signal before acting. This separation of when data arrives from when it is applied is the heart of why EtherCAT can drive demanding motion applications so precisely.
The same precise time base benefits measurement as well as actuation. Slaves can latch their inputs on a synchronised SYNC pulse, so a set of readings taken across many devices all correspond to the same instant. That is valuable whenever you need a coherent snapshot of a machine, because it means the sampled values genuinely belong together in time rather than being smeared across whenever each device happened to be read.
Distributed clocks do not just help the machine run; they also make the data coming off it more trustworthy for monitoring. Because every capable slave shares the same sense of time, values captured on a synchronised pulse carry a consistent time reference, which means a monitoring layer can compare readings from different parts of the machine knowing they were sampled together. When those values are streamed up to a cloud historian, that coherence carries through: a snapshot of many signals really does represent one moment on the machine.
This matters for the kind of analysis operators actually want to do. Correlating a torque spike on one axis with a position error on another, or lining up a set of sensor readings during a fault, only works cleanly if the samples share a common time base. Data gathered from an EtherCAT segment with distributed clocks arrives already time-coherent at the source, so a platform that historises it can preserve that relationship rather than trying to reconstruct timing from when frames happened to be received.
For a cloud SCADA platform like Merobix, the practical upshot is that machine data from a well-synchronised EtherCAT network is easier to reason about after the fact. The controller typically gathers the synchronised values and forwards them, and the tight time base upstream means the trends and events an operator reviews reflect what really happened together on the machine. The monitoring layer sits above the real-time synchronisation rather than inside it, but it inherits the benefit of clean, coherent time stamps that distributed clocks produced at the field level.
The reference clock is the internal clock of the first distributed-clock-capable slave on the network. Its time becomes the master time base that every other capable slave aligns to, using propagation-delay and drift compensation so all the local clocks agree closely enough for sub-microsecond synchronisation.
SYNC0 and SYNC1 are hardware timing pulses that an EtherCAT slave generates from its synchronised local clock at a configured instant. Because every slave's clock is aligned, these pulses fire simultaneously across the network, and slaves use them to latch inputs or apply outputs at exactly the same moment.
Coordinated multi-axis motion requires every axis to apply its command at the same instant, not just to receive it quickly. Distributed clocks give all axes a synchronised SYNC pulse so they act together, removing the timing jitter that would otherwise cause position errors and rough motion between axes.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.