EtherCAT
Connecting servo drives, remote IO, and sensors to Ethernet sounds like a natural upgrade: the cabling is mature, the bandwidth is high, and the tools are familiar. But control systems are usually not blocked by whether data can arrive at all. They are blocked by whether data can arrive inside a stable cycle. A position value that arrives a few hundred microseconds late is not the same kind of problem as a web page that opens a few hundred microseconds late.
EtherCAT is built around that difference. It does not move TCP/IP into the motion-control field, and it does not make every slave behave like a normal Ethernet device that receives a packet, handles it in software, and sends a separate response. It uses Ethernet frames as the carrier, but organizes cyclic process data as one pass through a chain of slaves.
The core of EtherCAT is not putting industrial control messages into Ethernet. It is letting one frame pass through multiple slaves while each slave reads and writes its own data on the fly.
Where Normal Ethernet Falls Short
Normal Ethernet is good at carrying large amounts of general traffic, but a control loop cares about a different set of properties:
- whether the cycle time is stable
- whether jitter is bounded
- whether several devices can sample inputs and update outputs at aligned times
- which slaves actually processed data in a given cycle
- whether a fault can be traced to the link, a slave, mapping, or timing
If the master sends a request to each slave, waits for a response, and then moves to the next slave, the total time grows with the number of devices. Even when each exchange is fast, dozens of IO modules, several servo axes, and sensors can consume the cycle budget through request-response overhead.
Jitter is the other problem. Switching, queuing, operating-system scheduling, and application processing can all create a gap between “fast on average” and “on time every cycle.” Control systems need the latter.
The Minimal Model
EtherCAT can be reduced to four objects:
- master: sends EtherCAT frames at a fixed cycle and checks the returned result
- slave: reads its output data and writes its input data while the frame passes through
- process data: the cyclic input/output image exchanged in every control cycle
- working counter: a count used by the master to check how many targets processed a datagram
A typical chain is not this:
master -> request slave 1 -> response from slave 1
master -> request slave 2 -> response from slave 2
master -> request slave 3 -> response from slave 3
It is closer to this:
the master sends one frame
-> slave 1 reads and writes its own data as the frame passes
-> slave 2 reads and writes its own data as the frame passes
-> slave 3 reads and writes its own data as the frame passes
-> the frame returns to the master
-> the master checks input data and the working counter
This model explains a lot of EtherCAT behavior: it uses Ethernet cables and Ethernet frames, but its communication semantics are closer to a high-speed cyclic fieldbus scan.
Processing On The Fly
The representative EtherCAT behavior is on-the-fly processing. A slave does not need to receive a complete frame first and then let software parse it slowly. The EtherCAT Slave Controller matches, reads, writes, and forwards the frame in hardware while the frame is moving through the device.
The gain is not a nicer bandwidth number. It is a structural change in the control cycle:
- many slaves share one frame transmission cost
- adding slaves does not require a full request-response round for every station
- data for one cycle is sent and collected centrally by the master
- the forwarding path is handled close to hardware instead of depending on software at every slave
The cost is also clear. A slave cannot be just a normal NIC plus an application program. It needs EtherCAT Slave Controller capability in the hardware path. The master also cannot treat the network like a group of ordinary TCP or UDP devices.
Process Data As A Memory Image
Many EtherCAT systems are best understood as having a process-data image. The master prepares an output area locally and places data for the slaves into it. When the frame passes through a slave, the slave takes its output data from the corresponding location and writes its input status back. When the frame returns, the master sees the input image for that cycle.
This does not mean the network literally has shared memory. It means EtherCAT uses address mapping to organize distributed slave IO into a continuous cyclic data view.
Two mechanisms often appear here:
FMMUmaps logical addresses to physical memory areas inside the slaveSyncManagermanages synchronization boundaries for process data or mailbox data
That level of understanding is enough to explain most engineering symptoms. FMMU lets the master organize the process-data map by logical address instead of writing a separate access flow for every slave. SyncManager gives the slave application side and the EtherCAT communication side a clear boundary when they access the same data.
So when a process-data mapping is wrong, it is usually not just a variable-name typo. The master configuration, slave object dictionary, PDO mapping, and internal buffer boundaries may not agree.
What The Working Counter Tells You
An EtherCAT datagram carries a working counter, usually written as WKC. The master does not only check whether the frame came back. It also checks how many slaves processed that datagram as expected.
This has real diagnostic value. A returned frame only says there is a return path. A matching WKC says the target access was hit and the corresponding read or write action was performed.
Several symptoms should be separated:
- no returned frame: first suspect link, topology, power, missing slaves, or the master port path
- returned frame with wrong WKC: first suspect slave state, addressing, PDO mapping, SyncManager, or access permission
- correct WKC but unchanged data: continue with slave application state, drive enable, object semantics, and business conditions
That is why WKC is so informative in EtherCAT captures and diagnostics. It is not a business acknowledgment and does not mean a servo has executed an action. It is communication-layer feedback that the addressed read or write was processed by the slave.
Distributed Clocks Are Not About Bandwidth
In real-time control, fast arrival is not enough. Several slaves often need to sample inputs or update outputs at nearly the same time, especially in multi-axis motion. If every device acts only when a frame happens to arrive, cable position, forwarding delay, and master send jitter all leak into the control error.
EtherCAT Distributed Clocks solve the time-base alignment problem. Slaves maintain local clocks, and the system measures and corrects them so they stay synchronized. Input sampling, output update, or a sync event can then be triggered by the local synchronized clock instead of only by the instant a frame arrives.
The effect is direct:
- master send jitter does not have to become execution jitter one-to-one
- multiple slaves can act against a common time base
- position sampling and output updates are easier to align in motion control
So evaluating EtherCAT only by asking whether 100 Mbps is enough misses the point. Many systems care about the combined result of cycle time, synchronization accuracy, slave count, process-data size, and master real-time behavior.
It Is Not A TCP/IP Problem
EtherCAT can be carried directly in Ethernet frames, commonly with EtherType 0x88A4. That means cyclic process-data communication does not need to enter IP, TCP, or UDP semantics first.
Several judgments follow:
- an EtherCAT slave is not just a normal TCP server that can be considered healthy after a ping
- normal switches, routers, and firewalls do not define the EtherCAT fieldbus model
- captures should be read in terms of EtherCAT datagrams, WKC, commands, and slave state, not just IP five-tuples
- an EtherCAT network is usually controlled by a dedicated master, with topology and cycle behavior defined by configuration
The EtherCAT ecosystem also has mailbox communication and upper protocols or device profiles such as CoE, FoE, EoE, and SoE. They matter, but they should not hide the main path: cyclic control is still centered on the process-data cycle, slave state, and time synchronization.
Why Slave State Matters
An EtherCAT slave does not power up directly into stable process-data exchange. Common states include INIT, PRE-OP, SAFE-OP, and OP.
A rough reading is:
INIT: basic communication exists, but many application-layer capabilities are not upPRE-OP: mailbox communication and parameter configuration are availableSAFE-OP: input data is usually available, while outputs are not fully in normal control yetOP: normal process-data exchange is active
This state machine affects troubleshooting. A master that can identify a slave does not mean the slave is ready for full control. CoE parameters that can be read do not mean PDO outputs are active. A device stuck in SAFE-OP often points to unmet configuration, mapping, synchronization, or application conditions.
Between “the device is found” and “the control loop is normal,” there is still a path of state transition and configuration validation.
What To Check In The Field
EtherCAT troubleshooting should not begin inside object-dictionary details. A steadier order is to establish the cyclic link first:
- Check topology and link: master port, slave order, power, Link/Activity, ring or cable issues.
- Check slave state: whether devices move from
INIT/PRE-OP/SAFE-OPintoOP. - Check WKC: whether the actual working counter matches the expected value from the master configuration.
- Check process-data mapping: whether PDO, FMMU, SyncManager, and the master IO map agree.
- Check cycle and jitter: master real-time thread, NIC driver, operating-system scheduling, and Distributed Clocks state.
- Check business-layer conditions: drive enable, alarm state, control word, mode word, and device-profile semantics.
This order quickly separates layers. If the link is not standing, the object dictionary is not the first thing to edit. If WKC is wrong, the motion-control algorithm is not the first suspect. If the device is not in OP, inactive outputs are usually not a business-code problem first.
Three Judgments To Keep
The useful thing to remember about EtherCAT is not the label “Industrial Ethernet.” It is three engineering judgments.
First, EtherCAT organizes cyclic input and output for many slaves into one frame pass, reducing delay and jitter from per-station request-response exchanges through on-the-fly processing. Second, its process-data model depends on configuration, mapping, and slave state; it is not ordinary TCP/IP communication after device discovery. Third, real-time behavior is not only bandwidth. It comes from the master cycle, slave hardware processing, WKC, Distributed Clocks, and field topology together.
With those judgments, many symptoms become easier to place: why a device can be scanned but not controlled, why a frame returns but WKC is wrong, and why a cycle can be fast on average while motion still jitters.