How do EtherCAT Master and Slave devices communicate?

In EtherCAT, the network manager—now commonly called the MainDevice—initiates EtherCAT communication. Field devices—SubDevices—do not normally originate independent EtherCAT frames on the segment. Instead, the EtherCAT SubDevice Controller processes the travelling frame on the fly, reading the data addressed to the local device and inserting return data before the same frame continues. Older documents use the terms Master / Slave; current ETG material increasingly uses MainDevice / SubDevice for the same network roles.^[1]

The MainDevice first identifies the network it is about to control

Startup begins with discovery and configuration rather than motion commands. The MainDevice identifies the physical order of the connected SubDevices and checks that the network matches the expected configuration. Basic hardware information can be stored in the SubDevice Information Interface (SII) attached to the ESC, while the vendor's XML-based ESI file provides the complete network-accessible description: identity, process-data options, mailbox protocols and supported synchronization modes.^[2]

This is why two devices with the same connector are not automatically interchangeable. Product Code, Revision, ESI content and identification method matter during device integration.

Communication moves through the EtherCAT State Machine

A SubDevice normally progresses through INIT → PREOP → SAFEOP → OP. INIT establishes the basic communication state. PREOP allows configuration and mailbox services. SAFEOP brings process-data communication into a controlled intermediate state. OP is the state used for full cyclic input and output data exchange.^[3]

Do not confuse EtherCAT OP with the operating state of the machine function itself. A servo drive can be in EtherCAT OP while its own drive state machine still has the power stage disabled. Network state and application state are separate layers.

PDOs carry the cyclic process data

A Process Data Object (PDO) contains data that is exchanged continuously: a drive Target Position and Actual Position, an I/O module's digital bits, an analog measurement or a status word. During network configuration, the PDOs are mapped into the distributed process image.^[4]

At the start of a cycle, the MainDevice places new output data into the EtherCAT datagrams. As the frame passes the SubDevices, each one reads its assigned output area and writes its new input data into the frame. When the frame returns, the MainDevice has the refreshed input process image. It does not need to open a separate TCP/IP session to every field device.

A small process-image example

Consider an illustrative three-device network: I/O-A uses 2 output bytes and 2 input bytes; Servo-B uses 8 output bytes and 8 input bytes; Sensor-C provides 4 input bytes and no cyclic outputs. The application process image is therefore 10 output bytes + 14 input bytes.

This is an educational map, not a universal PDO layout. Real byte counts come from the actual ESI and device manual. The MainDevice is also not required to fit the entire cycle into exactly one Ethernet frame; the configuration may use several EtherCAT datagrams or frames.

SDO and mailbox traffic handle data that does not belong in every cycle

A Service Data Object (SDO), when CoE is used, is suited to on-demand parameter and configuration access. PDOs carry continuously refreshed process data; SDOs are used for items that do not need to consume cyclic bandwidth every control period. A filter constant, drive limit or product-information object is a typical example.^[5]

Mailbox communication can also carry other profiles such as SoE, FoE, EoE or AoE where the device supports them. A SubDevice does not have to implement every mailbox protocol; the supported set is described in its device information.

Working Counter tells the MainDevice whether the expected memory interactions happened

Each EtherCAT datagram ends with a Working Counter (WKC). When an addressed SubDevice successfully performs the relevant memory access, the WKC is updated in hardware. The MainDevice compares the returned WKC with the value expected from the configured network.^[6]

If a datagram normally expects WKC=5 and comes back with WKC=3, the MainDevice immediately knows that the transaction did not have the expected participation. WKC does not identify the root cause by itself: a node may be missing, reset, outside OP state or unable to perform the addressed memory operation. Link status, AL Status/Code and additional diagnostics are then used. See EtherCAT troubleshooting.

SubDevice applications can be FreeRun, frame-synchronous or DC-synchronous

The application inside a SubDevice does not always execute from the same trigger. ETG distinguishes FreeRun, where the application runs from a local timer; SM-synchronous operation, where new process data triggers the application; and DC-synchronous operation, where Distributed Clocks generate precise SYNC0/SYNC1 timing events.^[7]

So “EtherCAT makes every device act at exactly the same instant” is too broad. A multi-axis servo system may use DC-synchronous operation, while a simple digital I/O or sensor may use another mode.

Distributed Clocks synchronize time; they do not carry SubDevice-to-SubDevice data

A common legacy explanation incorrectly equates Distributed Clocks with direct SubDevice-to-SubDevice communication. DC has a different job: it aligns ESC local clocks to a shared EtherCAT system time and provides SYNC/LATCH timing support. The actual data path still uses PDOs, mailbox services or other EtherCAT mechanisms.^[8]

A DC-capable ESC also does not guarantee that the device application is using a DC-synchronous mode. The application and the ESI/configuration settings must actually enable and use it.

Can one SubDevice send process data directly to another?

Yes, but it is not unrestricted peer-to-peer Ethernet. ETG describes two methods. In topology-dependent one-datagram communication, data read from an upstream SubDevice can be written to a downstream SubDevice in the same travelling datagram; the order of the devices matters. In the MainDevice-routed method, the MainDevice reads the source in one bus cycle and writes the data to the destination in the next bus cycle.^[9]

The routed method is more flexible and lets the MainDevice validate the source transaction with the Working Counter before forwarding the data. Neither method is the Distributed Clocks mechanism.

Events and faults are not represented by one universal “event flag”

Application events can be represented in mapped PDO bits, device-specific Object Dictionary entries, CoE Emergency mechanisms or mailbox services depending on the device profile. At communication level, the MainDevice can observe AL status, AL status code, port/link information, ESC event/interrupt mechanisms and Working Counters.

A “servo fault” bit seen by the PLC and an invalid WKC seen by the EtherCAT stack are therefore different evidence. The first is an application/device condition; the second indicates that the expected EtherCAT memory transaction did not complete as configured.

Cable redundancy is an engineered option, not an automatic property of every ring drawing

EtherCAT cable redundancy requires a second MainDevice port and redundancy support in the MainDevice stack. In a normal non-redundant line, a break can make downstream devices unreachable. A redundant physical ring returns the last SubDevice to the second MainDevice port so communication can be maintained from both directions. The distinction is covered in the EtherCAT topology guide.

One communication cycle, step by step

What proves that communication is really healthy?

A lit link LED is not enough. A useful commissioning chain is: correct device and revision → expected topology → ESM OP state → expected PDO map → correct WKC → DC synchronization where required → meaningful engineering value in the application. An encoder count can be changing while the scaling or axis interpretation is still wrong.

Communication evidence and process correctness therefore have to be checked separately. The technical specifications describe the EtherCAT mechanisms, while the programming languages and tools guide explains how the process image is exposed to the control application.

Related EtherCAT guides

• What is EtherCAT?
• How does EtherCAT work?
• What is the topology of EtherCAT?
• Which devices and sensors can be integrated with EtherCAT?
• How does EtherCAT handle real-time performance?
• EtherCAT technical specifications
• Programming languages and tools for EtherCAT
• Detecting and resolving EtherCAT errors
• EtherCAT security
• Industrial communication

Technical references

[1] EtherCAT Technology Group — MainDevice sends the EtherCAT telegram; SubDevices process data on the fly. Implementation

[2] EtherCAT Technology Group — ESI/SII, device properties and online/offline network configuration. EtherCAT Technology / SII interface

[3] EtherCAT Technology Group / Delta Motion — EtherCAT State Machine: INIT, PREOP, SAFEOP and OP. ESM / State Machine

[4] Delta Motion — Process Data Objects (PDO): continuously exchanged process data. PDO

[5] Delta Motion — Service Data Objects (SDO): on-demand parameter and configuration access. SDO

[6] EtherCAT Technology Group — Working Counter diagnostics and successful memory interactions. EtherCAT Diagnosis for Users

[7] ETG.2200 — FreeRun, SM-synchronous and DC-synchronous SubDevice application modes. EtherCAT Implementation Guide

[8] EtherCAT Technology Group — Distributed Clocks synchronize ESC local clocks; they are not a SubDevice-to-SubDevice data channel. Distributed Clocks

[9] EtherCAT Technology Group — SubDevice-to-SubDevice process data within one datagram or routed via MainDevice in two bus cycles. SubDevice-to-SubDevice Communication