EtherCAT master algorithms

Discovery

Enumerating and addressing the bus

Nothing tells the master how many devices are attached. It could be one, it could be two hundred. The answer comes from a property of the protocol rather than from configuration.

EtherCAT frames pass through every device in turn, and each one increments a counter in the frame if it was addressed. Auto-increment addressing uses that: a datagram carries a position that each device increases as it forwards, and the device that sees zero is the one being addressed. So the master counts up from below — to reach the nth device it sends −n, which n devices raise to zero on the way. Send a read for position n and exactly the nth device answers.

Read position n. If the counter comes back unchanged, there is no nth device and the bus is n long.

The address on line 8 is a function of position, so re-running discovery computes the same value and skips every write. The walk is idempotent. Discovery runs again after a topology change, and a device that already holds its address is not rewritten.

Line 11 appends only after every read and write for that device has succeeded, so a failure part-way through leaves no half-built record.

Application layer

Sequencing every device to OP

Every device runs the same small state machine — INIT, then PREOP, then SAFEOP, then OP — and the master has to walk the whole bus through it together. Configuration happens between the states: mailboxes are set up before PREOP is useful, the process image and clocks before SAFEOP, outputs only in OP.

The obvious implementation asks each device to change state and waits for it before moving to the next. That serialises the whole bus behind its slowest member. Instead every request goes out first, and only then does the master start asking whether they arrived.

Line 9 is the difference between a diagnosable failure and an infuriating one. A master that reports only that a transition timed out leaves an engineer to find which of ninety devices refused; reading every device's status on the way out names it, along with the error code it is reporting.

Telling a refusal from slowness

A device that cannot make the transition keeps reporting the state it is still in. So comparing states alone cannot distinguish "refused" from "not yet", and the master would spend its whole poll budget waiting for an answer that already arrived.

The status carries a separate bit meaning "state transition not successful", and a status code saying why. Checking that bit before comparing states turns a full timeout into an immediate failure that names the device and its reason.

There is a matching bit on the way out. A device left latched in an error state will refuse a fresh request, so requests to the two lowest states also assert an acknowledge bit that clears the latch — which is what lets a master recover a bus it did not start.

Metadata

Reading a device's EEPROM

Discovery finds devices. It does not say what they are. Identity, how many process-data channels a device has, what its default data mapping looks like — all of it lives in an EEPROM on the device, reached through a register interface.

That interface is asynchronous. The master writes an address, and the device signals when the word is ready by clearing a busy bit.

Line 7 sits inside the busy check for a reason. Reading the data register before the device has cleared busy returns whatever the previous operation left there — a value that looks entirely plausible and belongs to a different address.

The poll ceiling on line 4 is what keeps one unresponsive device from hanging startup. This runs for every device in turn, so a device that never answers would otherwise stall the whole bus before it has even been configured.

Two details come from the device rather than the master. A single read returns four or eight octets, and which one is a property the device declares — so the master reads that back from the status rather than assuming a size. And starting a read needs a rising edge on the command bit, not merely writing a one to it: a bit left set by an abandoned read would make the next request do nothing at all, which is why the sequence clears the error state first.

Configuration

Validating the configured topology

Many installations are configured offline: an engineering tool produces a file describing the network, and the master is expected to bring up that network. The bus actually on the wire may differ — a device swapped, a segment added, a file one revision out of date.

The check is a walk down both lists comparing position by position. What matters is when it happens.

It runs before process-data setup, not during it. Validating as each device is configured would mean discovering the mismatch part-way through writing FMMUs, leaving some devices configured for a process image that is about to be abandoned. Checking first means a mismatch costs nothing but the check.

A rejection names the position and what differed. An engineer with a file one device out of date needs to know which device; being told only that validation failed leaves them comparing two lists by hand.

Process data

Laying out the process image

Every device contributes some outputs and some inputs. The master gathers all of them into one shared address space — the process image — and tells each device which slice of it belongs to that device.

A cyclic frame is made of datagrams, and a datagram that uses logical addressing names one contiguous range of that space: a start address and a length. Every device whose slice lies inside the range takes part as the frame passes. A range cannot skip a gap, and it cannot name two separate stretches.

That one property decides the whole layout, because it means the cost of a cycle depends on how many contiguous runs the master has to address.

Suppose the master walks the bus once, appending each device's outputs and then its inputs as it meets them. The image comes out alternating: outputs, inputs, outputs, inputs. Now no contiguous range holds only outputs. Writing the outputs takes one datagram per device instead of one for all of them, and reading the inputs takes another per device — because each device's slice is its own isolated run.

Walking the bus twice fixes it. One pass collects every device's outputs, a second collects every device's inputs. Each direction is now a single unbroken run, so one datagram covers all the outputs and one covers all the inputs — and because the two runs sit next to each other, one combined read-write datagram can cover the entire image.

Translating one address range per device

A datagram covering the whole output block is addressed to the block, not to any device. So how does each device end up holding only its own bytes?

Each device contains an address-translation unit, and the master configures it with two things: which range of the shared image belongs to that device, and where that range lives in the device's own local memory. As the frame passes through, the device compares the addresses the datagram covers against its configured range and copies just the overlapping bytes — out of the frame for outputs, into the frame for inputs.

So the devices do the demultiplexing themselves, in hardware, as the frame goes by. That is what lets the master address the whole image at once and still have each device receive exactly its own share: a cyclic datagram never names a device at all.

It is also why the layout has to be settled before the cycle starts. Those translation units are configured once, from the layout, and a device's slice cannot move afterwards without reconfiguring them.

The standard bounds them: a device has at most sixteen such units, and each maps one contiguous logical range to one contiguous local range. A device needing more separate mappings than that cannot be configured, whatever arrangement of the shared image is chosen. This is the limit on how finely a process image can be divided.

Packing is done at bit granularity, not byte. A device contributing three bits takes three bits. That looks like a micro-optimisation and is not: the process image travels in every frame, so a wasted byte is a wasted byte per cycle, for the life of the machine.

Sizing the channel

One number has two sources that disagree. A device's description declares how large its process-data channel is; the selected data mapping declares how many bytes are actually being exchanged. The master takes the larger — the payload has to fit, but a device may advertise a wider channel for reasons the master cannot see.

A channel carrying outputs also gets its watchdog enabled. That is what makes a device fall back to a safe state if cyclic data stops arriving. Without it, a master that dies leaves its last commanded values driven indefinitely — which on a machine with an axis in motion is the difference between a stop and a runaway.

Cyclic data

Deriving the expected working counter

A cyclic frame goes out carrying outputs and comes back carrying inputs. Nothing in it records which devices took part — except one counter travelling with the frame, which each device increments as it passes.

The counter counts participations, not devices. A datagram that both writes outputs and reads inputs gives one device more than one way to take part in the same pass, so a device's contribution depends on which directions its data lies in. That is why the numbers below are not all one.

The master therefore knows a cycle was complete when the counter returns the value it should. That value is never observed and then trusted; it is derived from the process image plan before the loop starts, so the first cycle is checked as strictly as the millionth.

A mapping that only partly overlaps the datagram's address window contributes nothing at all. A partial overlap is a planning mistake, and counting it as a partial increment would produce an expected value that a healthy cycle can never match.

An assumption the layout has to keep true

The standard counts per device, not per mapping — a device increments once "if at least one" of the addressed regions matched, no matter how many of its regions did. This master instead adds up its mappings, which gives the same answer only while no device holds more than one mapping per direction inside a single datagram.

Its own layout guarantees that: each device is given exactly one mapping per direction. So the sum is correct here — but it is correct because of the layout, not on its own. A process image built some other way, giving one device two output regions in the same datagram, would make the master expect a number no conforming device will ever produce, and every cycle would look faulty.

Distributed clocks

Measuring propagation delay

Devices on an EtherCAT segment share a system time, and they use it to act simultaneously — to sample sensors or drive outputs at the same instant rather than as the frame sweeps past them. That only works if each device knows how long the frame took to reach it.

The delay is measured, not assumed. Each device timestamps the frame as it arrives at each of its ports, and those timestamps let the master reconstruct how long the signal spent on every link.

Why one broadcast, and not one frame per device

The timestamps only mean something together. They must all describe the same traversal, so the latch is one broadcast write that every device sees as it passes. Reading each device individually would produce timestamps from different frames taken at different moments, which cannot be differenced.

Lines 7 to 9 handle counter wraparound. The timestamps come from free-running 32-bit counters, so a difference must be computed with wrapping arithmetic. A difference larger than half the counter's range has two equally valid readings. Rather than pick one, the measurement is rejected.

Line 4 covers missing hardware support. A device that forwards frames but cannot timestamp them leaves a gap in the accumulated delay. The only way to fill that gap would be to assume a residence time. Configuration fails instead.

Line 10 halves a round trip to get a one-way delay. This is the standard's symmetric-link assumption rather than this master's choice. A link whose two directions differ materially would break it.

Writing the offsets, then activating the sync unit

Measuring the delay tells the master how far each device is from the reference. Two more things have to happen before anything is synchronised.

First the clocks are aligned. The master zeroes the reference's offset, reads its clock once, and expresses every other device's offset against that single reading — corrected by that device's propagation delay. Reading the reference again for each device would make every offset relative to a different instant, and the alignment would be no better than the time between the reads.

Then the sync unit is switched on. Aligned clocks let devices agree what time it is; a SYNC pulse is what makes them act at the same instant — sample a sensor, latch an output — rather than as the frame sweeps past. The master writes the pulse period, optionally a second slower one, and activates the unit.

Activation comes last. The unit starts generating pulses the moment it is activated, so activating before the offsets are written produces pulses from clocks that have not been aligned. That failure is harder to diagnose than no synchronisation, because the pulses are present and appear correct.

Mailbox

Transferring parameters and files

Cyclic data is the same few bytes every cycle. Everything else — reading a fault code, writing a gain, loading firmware — is a request and a response through a mailbox.

Values larger than one message

A parameter might be one byte or several kilobytes. Small values ride inside the request itself. Larger ones are split into segments, and segments raise a problem: they look alike. A duplicated or retransmitted segment appended twice corrupts the value silently.

So each segment carries a bit that alternates. A segment whose bit did not alternate is a duplicate, and it is reported as a protocol error rather than accepted. The specification even has a dedicated abort code for it.

Abort codes are preserved rather than collapsed into a generic failure. The code is what separates "no such object" from "wrong size" from "read-only", and an integrator has no other source for that distinction.

How much data one segment carries

A segment always carries seven data octets, and a small count in its header says how many of the seven are real. That encoding cannot describe anything larger than seven. A device with a bigger mailbox sends more than seven in one segment, sets the count to zero, and the real size has to be taken from the message length instead.

Reading the count in both cases looks safe, and that is what makes it dangerous. Zero unused octets reads as seven — a sensible-looking answer that is wrong for every segment larger than the minimum. The rest of the segment is discarded, the transfer still ends when the device marks its last segment, and the caller gets a short value with nothing reported as failed. So the length governs whenever the message is longer than the minimum, and the count applies only at the minimum.

Transferring files, and handling a busy device

File transfer numbers its packets and ends when a packet arrives shorter than a full one. That is why a file whose length is an exact multiple of the packet size must end with an empty packet — the terminator is shortness, not a length field.

A device may answer that it is busy. The transfer retries the same step without advancing its packet number, and the number of retries is bounded. An unbounded retry is how a device that is permanently not ready becomes a master that never finishes.

Staging firmware, which is not applying it

The highest-consequence operation a master performs is also the one the standard says least about. It defines file transfer. It does not define what a device does with a firmware image once it has one.

So the master reports Staged, not success. It knows the bytes arrived. It does not know whether the device accepted them, whether it will boot, or which slot it chose. Claiming success would be claiming knowledge the master does not have.

Everything checkable is checked before any byte goes on the wire: an explicit destructive-write allowance from the caller, a non-empty image and filename, a maximum size, and optionally a checksum the caller supplies. A firmware transfer that fails part-way can leave a device unbootable, so a check that can be made early is made early.

Acyclic traffic

Budgeting the acyclic window

Not all traffic is cyclic. Reading a drive's error register, downloading a parameter, transferring firmware — these are request-and-response exchanges through a mailbox, and they share the wire with the cycle that must not be late.

Both kinds of traffic go out on the same wire, and a cycle is late if anything delays the frame carrying its process data. A mailbox exchange placed ahead of that frame adds its own transmission time to the cycle; one placed after it cannot, because by then the cyclic frame has already been sent and its response received.

The ordering is therefore fixed: acyclic work runs after the cyclic exchange has finished, never before it, and never for longer than its budget allows.

The budget's scope is the part that has to be right. If parameter transfers and firmware transfers each keep their own per-cycle allowance, each is individually well behaved while the cycle pays for both. One arbiter, indexed by device, owns the whole window, so the cap applies to the total and one talkative device cannot occupy the window while another waits.

Supervision

Running three regions concurrently

A master in OP is doing three separate jobs on the same tick: exchanging process data, servicing whatever mailbox work is queued, and watching whether the segment is still healthy. Writing that as one flat state machine either loses the concurrency or multiplies the states until nobody can reason about them.

So OP is three regions that advance independently.

The other benefit is in what recovery sees. Because the fault is recorded in the region that failed, and carries its own reason, recovery policy can tell a working-counter fault from a mailbox fault and respond differently. A single global fault state would have told it only that something went wrong.

Within the process-data region, the substates — waiting for tick, sending, receiving, checking the counter, complete — describe ordering inside one tick, not a sequence of ticks. The whole exchange runs to completion before the cycle call returns.