EtherCAT Distributed Clock Checker

This free EtherCAT Distributed Clock checker tests whether the Sync0 timing you are about to configure hangs together arithmetically, before you download it to the master. Enter your master cycle, the Sync0 cycle factor, the Sync0 shift, and your slaves' minimum supported cycle; it calculates the resulting Sync0 cycle and frequency, then checks the two relationships that catch most misconfigurations: the Sync0 cycle must not fall below the slave minimum, and the shift must fit inside the Sync0 period. It's for controls and automation engineers commissioning distributed-clock applications — synchronized motion, timestamped I/O, measurement — or reviewing settings inherited from another project. No account, no spreadsheet — the formula and checks are shown below so you can reproduce the result by hand.

◴

Check the basic relationship between the master cycle, Sync0 factor, shift, and slave minimum cycle.

Check the basic relationship between the master cycle, Sync0 factor, shift, and slave minimum cycle. Checks arithmetic consistency only: Sync0 cycle = master cycle × factor, the selected cycle is compared with the entered slave minimum, and shift is checked against the calculated Sync0 period. Always use the slave ESI/device documentation and the master vendor's DC guidance for final settings.

The formula

Distributed clocks give every slave a local clock that tracks the network's reference clock. Sync0 is the periodic pulse a slave generates from that clock — inputs latch and outputs switch on Sync0 edges, so slave actions align to the clock rather than to frame arrival. Masters rarely run Sync0 at exactly the application cycle; they scale it with a cycle factor and offset it with a shift time. This checker does that arithmetic and tests the result:

Sync0 cycle
  T_Sync0 = T_master × f

Sync0 frequency
  F_Sync0 = 1,000,000 ÷ T_Sync0          (T in µs, F in Hz)

Consistency checks
  T_Sync0 ≥ T_min        Sync0 cycle clears the slave minimum
  t_shift < T_Sync0      shift fits inside the Sync0 period
VariableMeaningWhere it comes from
T_masterMaster (application) cycle time, in µs — the period of the task that exchanges process dataYour master/task configuration
fSync0 factor (cycle factor) — the multiplier between the master cycle and the Sync0 cycle; dimensionlessYour master's DC settings for the slave or segment
T_Sync0Sync0 cycle — the period of the slave's synchronization pulseCalculated: T_master × f, and the figure both checks test
F_Sync0Sync0 frequency, in HzCalculated: 1,000,000 ÷ T_Sync0
T_minSlave minimum cycle, in µs — the shortest cycle the slave supportsThe slave's ESI file / device documentation (see FAQ 5)
t_shiftSync0 shift time, in µs — how far the Sync0 pulse is offset within its periodYour master's DC settings

Why the factor matters: a factor below 1 runs Sync0 faster than the master cycle (sub-cycle — the slave synchronizes, latches, or timestamps more than once per application cycle); a factor of 1 matches it; a factor above 1 runs Sync0 on every second, third, or nth master cycle. All three are legitimate — the code accepts any factor from 0.01 upward — but every slave on the segment has a floor below which it cannot follow, and that floor is what the first check protects. The second check protects the shift: a shift is a position inside one Sync0 period, so it has to be smaller than the period itself to mean anything.

Note the boundary behaviour, because both edges come up in practice: the minimum-cycle check passes at exact equality (a Sync0 cycle equal to the slave minimum is a Pass — with zero margin), while the shift check fails at exact equality (a shift equal to the Sync0 cycle does not fit inside the period).

What each input means

Every field below is exactly as it appears in the live calculator (labels, defaults, and input limits verified in source).

InputUnitDefaultWhat breaks if you get it wrong
Master cycle (µs)µs (minimum 1)1,000This is the base every other figure scales from. Enter the cycle of the task that actually drives the segment — if the master runs the application at 2 ms but you enter 1 ms, the calculated Sync0 cycle is half the real one and both checks judge the wrong configuration
Sync0 factor— (minimum 0.01, step 0.01, no maximum)1The multiplier that produces the Sync0 cycle. Below 1 = sub-cycle (faster Sync0), 1 = same as master, above 1 = every nth master cycle. A factor entered the wrong way up (e.g. 2 instead of 0.5) gives a Sync0 cycle four times the intended one — and can still "pass" against a slow minimum, so check the calculated cycle, not just the verdict
Sync0 shift (µs)µs (minimum 0)200The offset of the Sync0 pulse within its period, used to position latching/switching relative to the arriving frame. It must be smaller than the Sync0 cycle; at or above it, the value no longer describes a point inside the period and the checker fails the configuration
Slave minimum cycle (µs)µs (minimum 1)500The shortest cycle your slowest slave supports, from its ESI/device documentation. Too low a figure lets the checker pass Sync0 cycles the hardware can't follow; too high rejects valid configurations. With mixed slaves sharing a Sync0 cycle, enter the largest minimum on the segment — the slowest device sets the floor

Worked example

Scenario: a drive and I/O segment being commissioned with Distributed Clocks on a 1 ms master cycle. The inputs below are the calculator's own starting values, so you can reproduce the main case exactly by opening the calculator and pressing "Check DC timing" without changing anything.

Inputs (the calculator's defaults):

  • Master cycle: 1,000 µs
  • Sync0 factor: 1
  • Sync0 shift: 200 µs
  • Slave minimum cycle: 500 µs

Step by step:

  1. Sync0 cycle: 1,000 × 1 = 1,000 µs
  2. Sync0 frequency: 1,000,000 ÷ 1,000 = 1,000 Hz
  3. Minimum-cycle check: 1,000 µs ≥ 500 µs → Pass
  4. Shift check: 200 µs < 1,000 µs → fits inside the period

The calculator's verdict for these inputs reads: "The entered timing relationship is arithmetically consistent. Verify the slave ESI/device documentation and master-specific DC configuration before applying settings."

Variation 1 — sub-cycle, factor 0.5. The application needs Sync0 events twice per master cycle (factor 0.5, everything else unchanged). Sync0 cycle = 1,000 × 0.5 = 500 µs; frequency = 2,000 Hz. Minimum-cycle check: 500 ≥ 500 → Pass — but exactly at the floor. Shift check: 200 < 500 → fits. The configuration is consistent, with zero margin on the minimum: any later change that shortens Sync0 further (a faster master cycle, a smaller factor) breaks it against these slaves.

Variation 2 — failing: Sync0 below the slave minimum. Push the factor to 0.25 chasing a faster sync rate. Sync0 cycle = 1,000 × 0.25 = 250 µs; frequency = 4,000 Hz. Minimum-cycle check: 250 < 500 → the metric shows "Check", and the verdict reads: "Review the settings before commissioning. Sync0 cycle is below the entered slave minimum of 500 µs. Verify the slave ESI/device documentation and master-specific DC configuration before applying settings." The master would happily download this; the slaves cannot follow a 250 µs cycle. The fix is on the settings side — raise the factor (or slow the master cycle) until Sync0 clears 500 µs — or on the hardware side, with slaves whose minimum cycle is genuinely lower.

Variation 3 — failing differently: shift outside the period. Back to the defaults, but with a shift of 1,200 µs keyed in from a configuration sheet for a slower segment. Sync0 cycle is still 1,000 µs and the minimum-cycle metric still shows "Pass" — yet the verdict is the failing one: "Review the settings before commissioning. Sync0 shift must be smaller than the calculated Sync0 cycle in this checker. Verify the slave ESI/device documentation and master-specific DC configuration before applying settings." A 1,200 µs shift cannot be a position inside a 1,000 µs period. Note where the failure shows up: the "slave minimum-cycle check" metric tracks only the minimum test, so a shift failure is visible only in the verdict and its red styling. Read the verdict, not just the metric grid.

What the example shows: the factor is the lever and the slave minimum is the wall. Sub-cycle Sync0 (Variation 1) is a normal, useful configuration — right up to the floor the slowest slave sets. Both failure modes are single-keystroke mistakes (a factor one step too small, a shift carried over from a slower segment), and both are invisible until something checks the relationships. That check is all this calculator does — which is exactly why it's worth running before commissioning rather than after a failed startup.

What the result tells you

The result panel shows four figures (labels as displayed by the live calculator), followed by a one-line verdict:

  • Calculated Sync0 cycle — master cycle × factor, in µs. This is the period your slaves' Sync0 pulses will actually run at, and the figure both checks test. Sanity-check it against what you intended before reading anything else — a wrong-direction factor (§4) can pass the checks while being four times the cycle you meant.
  • Sync0 frequency — 1,000,000 ÷ Sync0 cycle, in Hz. The same period expressed as a rate; useful when device documentation or a configurator talks in Hz rather than µs (1,000 µs = 1,000 Hz, 500 µs = 2,000 Hz, 250 µs = 4,000 Hz).
  • Configured shift — the shift you entered, echoed back in µs. Compare it against the calculated Sync0 cycle: it must sit strictly inside that period.
  • Slave minimum-cycle check — Pass when the Sync0 cycle is at or above the slave minimum you entered, Check when it falls below. Important: this metric reports only the minimum-cycle test. The shift test has no metric of its own — its result appears only in the verdict.
  • The verdict line — the overall judgement. Green "The entered timing relationship is arithmetically consistent." means both checks passed. The red "Review the settings before commissioning." names each failing check ("Sync0 cycle is below the entered slave minimum of {X} µs" and/or "Sync0 shift must be smaller than the calculated Sync0 cycle in this checker"; if both fail, both are listed). Every verdict, pass or fail, ends with the same instruction: "Verify the slave ESI/device documentation and master-specific DC configuration before applying settings." That is not boilerplate — this checker validates arithmetic among four numbers you typed; whether those numbers are the right ones for your slaves and master is the ESI's and the master vendor's territory, and the site's EtherCAT guide works through DC configuration in full.

Out-of-range inputs (a factor below 0.01, a master or minimum cycle below 1, a negative shift) don't produce a result at all — the calculator asks you to check the entered values instead.

Common mistakes

  1. Running sub-cycle Sync0 past the slowest slave. A factor of 0.25 at a 1 ms master cycle asks every slave to synchronize at 250 µs. The master accepts the configuration; slaves with a 500 µs minimum can't follow it. The minimum that matters is the largest one on the segment — check every device's ESI, not just the drives.
  2. Carrying a shift across from a slower segment. Shift values are absolute microseconds, not proportions. A 1,200 µs shift that was valid inside a 2,000 µs Sync0 period is meaningless inside a 1,000 µs one (Worked Example, Variation 3). Any time the master cycle or factor changes, re-derive the shift against the new period.
  3. Reading the Pass metric as an all-clear. The "slave minimum-cycle check" metric covers one of the two tests. A configuration can show Pass there and still fail on shift — the failing state lives in the verdict line. Read both, every time.
  4. Entering the wrong base cycle. The master cycle field is the cycle of the task exchanging data with the segment — not the Sync0 cycle you're trying to achieve, and not a different task's cycle on the same master. A wrong base silently scales the calculated Sync0 cycle and judges a configuration you don't actually have.
  5. Treating "arithmetically consistent" as "will synchronize." This check sees four numbers. It cannot see reference-clock selection, propagation-delay measurement, whether DC is even enabled correctly on each slave, or ESI mismatches — all of which decide whether distributed clocks actually lock and hold in the machine. Consistency here is the entry ticket, not the result; commissioning still follows the slave documentation and your master vendor's DC guidance.

FAQ

What is Sync0 in EtherCAT Distributed Clocks?

Sync0 is the periodic synchronization pulse a slave generates from its local distributed clock. Inputs are latched and outputs are applied on Sync0 edges, which is how Distributed Clocks keep actions on different slaves aligned to the same instant rather than to whenever a frame happens to arrive. The Sync0 period doesn't have to equal the master cycle: masters derive it from the application cycle using a cycle factor, and a shift time can offset the pulse within its period. This checker verifies that the combination you enter — master cycle, factor, shift, and your slaves' minimum cycle — is arithmetically consistent.

How do I calculate the Sync0 cycle time?

Multiply the master cycle by the Sync0 cycle factor: Sync0 cycle = master cycle × factor. A 1,000 µs master cycle with a factor of 1 gives a 1,000 µs Sync0 cycle (1,000 Hz); a factor of 0.5 gives 500 µs (2,000 Hz); a factor of 2 gives 2,000 µs (500 Hz). The factor is how masters express sub-cycle and multi-cycle synchronization without changing the application cycle itself.

Can the Sync0 cycle be faster than the master cycle?

Yes. A cycle factor below 1 makes Sync0 fire more than once per master cycle — a factor of 0.5 at a 1,000 µs master cycle gives a 500 µs Sync0 cycle. That only works if every slave on the segment supports a cycle that short, which is why this checker compares the calculated Sync0 cycle with the slave minimum you enter. Factors above 1 are equally valid: Sync0 then fires once every two or more master cycles, which suits slower, precisely synchronized outputs and measurements.

What happens if the Sync0 shift is bigger than the Sync0 cycle?

The shift is meant to position the Sync0 pulse inside its own period, so a shift at or above the Sync0 cycle no longer describes a point in that period — at best it wraps into a later cycle; depending on the master, the configuration may be rejected or behave unexpectedly. This checker flags it: the verdict tells you the Sync0 shift must be smaller than the calculated Sync0 cycle. Reduce the shift, or lengthen the Sync0 cycle (raise the factor or the master cycle) until the shift sits comfortably inside the period.

Where do I find my slave's minimum cycle time?

In the slave's ESI file and device documentation — the minimum cycle time is a device property, set by how fast the slave can handle its distributed-clock synchronization and process data, and configurator tools usually surface it when you enable DC on the device. If several slaves will run the same Sync0 cycle, enter the largest minimum among them: the cycle has to clear every device's floor, so the slowest device on the segment sets the limit for all of them.

Does a Pass from this checker mean my Distributed Clocks are configured correctly?

No. A Pass means the four numbers are arithmetically consistent: the Sync0 cycle clears the slave minimum you entered, and the shift fits inside the period. Distributed-clock behaviour also depends on reference-clock selection, propagation-delay measurement, your master's DC configuration, and each slave's ESI — none of which a four-field check can see. Treat this as a pre-commissioning sanity check, verify against the slave ESI/device documentation and your master vendor's DC guidance, and work through our guide to EtherCAT cycle time, jitter and Distributed Clocks for the full picture.

Related tools and reading

Budgeting the whole EtherCAT segment?

The free Controls Toolkit includes the EtherCAT timing-budget workbook — slave and PDO inventory, cycle utilisation, and remaining timing margin, with the formulas built in — plus an Industrial PC sizing workbook. Free by email signup.