EtherCAT for PLC Motion and I/O Systems

Direct answer

EtherCAT is a real-time Industrial Ethernet system used to connect a PLC or industrial PC MainDevice to distributed I/O, servo drives, encoders, robots and other SubDevices. The MainDevice sends frames through the network; each SubDevice reads output data addressed to it and inserts input data while the frame passes, then the last open port returns the frame through the full-duplex path. This on-the-fly processing lets one frame serve many devices with predictable cyclic exchange.

To configure EtherCAT in a PLC project, first prove that the controller/runtime and network interface support acting as an EtherCAT MainDevice. Obtain the exact SubDevice's EtherCAT SubDevice Information, or ESI, file; match the discovered product/revision; create the expected topology; select cyclic Process Data Objects, or PDOs; map them to typed PLC variables; set the bus/task cycle and watchdog behavior; configure Distributed Clocks only where the application and devices require them; and commission devices through INIT, PREOP, SAFEOP and OP with a defined safe-output test.

To diagnose EtherCAT, preserve the first fault and compare expected topology, actual device order, link state, EtherCAT state, AL status code, expected versus actual Working Counter, per-port receive/CRC and lost-link counters, and Distributed Clock deviation. A Working Counter mismatch proves that a datagram did not receive the expected participation; it does not by itself identify a bad cable or name the failed device. Use topology and per-port counters to localize the boundary.

Use current EtherCAT terminology

The EtherCAT Technology Group now uses MainDevice and SubDevice in public technology descriptions. Many installed manuals, engineering tools and object names still use the legacy terms master and slave. Both pairs refer to the initiating controller and the devices that process its frames. When searching a product manual, use the terminology printed by that product without assuming an architectural difference.

Core terms

Understand on-the-fly frame processing

The MainDevice is the only node in an EtherCAT segment that actively originates EtherCAT frames. SubDevices forward the frame downstream while reading from and writing to assigned locations. The last open port closes the logical path and the full-duplex return travels back through the nodes to the MainDevice.

One frame can serve many devices

EtherCAT can carry Ethernet over EtherCAT as an optional mailbox profile, but that does not turn the cyclic fieldbus into an unmanaged office-LAN chain. Use EtherCAT infrastructure components and the device/manufacturer topology rules.

Select the PLC and MainDevice interface

The first compatibility question is not “does the PLC have Ethernet?” It is “does this exact PLC/runtime, firmware and interface implement the required EtherCAT MainDevice class and features?” Motion may require Distributed Clocks, specific cycle times, CiA 402 profile support and coordinated task scheduling that a basic I/O MainDevice does not provide.

MainDevice capability checklist

Brand compatibility needs an exact product answer

Beckhoff controllers and TwinCAT are closely associated with EtherCAT, but still require compatible terminals, ESI data and configuration. Use the Beckhoff EtherCAT TwinCAT 3 setup, PDO mapping and diagnostics guide for the exact target, real-time adapter, scan/diff, Startup, task/DC and Working Counter workflow. CODESYS-based controllers can support an EtherCAT MainDevice when the target runtime, license, driver and network interface support it; “uses CODESYS” alone is insufficient. Siemens S7-1200 controllers are ordinarily configured around their documented PROFINET capabilities; an EtherCAT connection generally needs a supported gateway or separate motion controller rather than an assumption of native MainDevice support. Use the S7-1200 EtherCAT gateway, mapping and diagnostics guide to select the correct PROFINET-device/EtherCAT-MainDevice or controller-to-controller role pair. Rockwell controllers are ordinarily associated with EtherNet/IP; the Allen-Bradley EtherCAT gateway, Studio 5000 mapping and diagnostics guide explains the required Scanner/Adapter and MainDevice/SubDevice role pairs without implying native compatibility. Current OpenPLC Runtime v4 includes a native plugin route, but support still depends on the exact release, host, plugin, dedicated NIC and device project; use the OpenPLC EtherCAT v4 setup and diagnostics guide for that product-specific path.

Verify each claim in the current controller and interface manuals. Do not choose a gateway solely because both product pages say Ethernet; it must implement the correct roles, cyclic data sizes, timing, state and fault behavior.

Build the topology and cabling correctly

EtherCAT supports line, tree, star and branch structures using the ports and junctions provided by EtherCAT devices. Its physical arrangement can be flexible while the logical frame path remains deterministic and discoverable. A standard office Ethernet switch inserted into the real-time device path is not equivalent to an EtherCAT junction.

Topology evidence

For common 100BASE-TX copper links, the often-cited maximum is 100 m between devices, but the installed cable, connector, flex duty, EMC environment and device manual determine the valid segment. EtherCAT P combines communication and power under its own system rules; it is not ordinary Power over Ethernet. Fibre and other physical variants require compatible devices.

Import ESI and match device identity

An ESI file describes one or more SubDevice types and revisions: identification, physical ports, process data, SyncManagers, mailbox protocols, Distributed Clock modes and other capabilities. Import it into the engineering tool's device repository using the tool's supported workflow.

Resolve ESI and scan mismatches

Do not download an ESI from an unrelated file archive merely because the filename resembles the device. Use the manufacturer or ETG-listed product source, record the file/version/checksum, and retain it with the project.

Map PDOs to PLC variables

PDOs carry cyclic values. From the SubDevice perspective, RxPDOs are received by the SubDevice—commonly controller commands, target values and output bits. TxPDOs are transmitted by the SubDevice—commonly status, actual values and input bits. Some PLC tools present direction from the controller perspective, so verify the labels in that tool.

Generic drive and I/O mapping example

The byte/bit offset shown by the PLC tool is generated from the active PDO configuration. Hard-coding remembered offsets from another device revision is fragile. Map named, typed variables and retain a generated mapping report with the project.

Understand mailbox and device profiles

Mailbox communication supports acyclic protocols while cyclic exchange continues. CAN application protocol over EtherCAT, CoE, exposes an object dictionary and SDO services familiar from CANopen. Servo drives commonly use a standardized drive profile over CoE, but actual modes, objects and PDO choices remain device-specific.

Mailbox protocol roles

Startup parameter lists often write mailbox objects as the device moves through states. One rejected SDO can prevent transition to SAFEOP or OP. Preserve the exact object, subindex, abort/AL status and device state instead of deleting all startup commands.

Commission the EtherCAT state machine

EtherCAT SubDevices transition through INIT, PREOP, SAFEOP and OP. A BOOTSTRAP state is available for supported firmware-download functions. The MainDevice requests transitions; the SubDevice reports its Application Layer state and status code.

State behavior and diagnosis

State descriptions are protocol principles; the exact output safe value, drive behavior and transition checks come from the SubDevice manual. Never command OP until machine risk controls, output mapping and watchdog/fail state have been validated.

Configure cycle time and Distributed Clocks

The EtherCAT frame cycle, PLC task, motion task, input latch and output update must form a coherent timing design. “EtherCAT is fast” does not guarantee that an overloaded controller task, unsupported adapter or poor application schedule meets a machine's jitter and latency requirements.

Timing design record

Distributed Clocks use hardware-supported local clocks and topology-derived propagation delay compensation. The ETG describes synchronization well below one microsecond in suitable implementations, but this is not a universal end-to-end motion accuracy guarantee. Sensor latency, drive loops, mechanical dynamics, MainDevice scheduling and configuration still matter.

Diagnose Working Counter mismatches

Each EtherCAT datagram includes a Working Counter. Devices increment it according to the command and whether the addressed memory operation succeeds. The MainDevice knows the expected value for the configured datagram and compares the returned value each cycle.

Interpret WKC as participation evidence

Do not translate “WKC error” directly into “replace the shown terminal.” A fault upstream can remove several downstream devices. A state or PDO configuration issue can affect participation without a physical link loss. First identify which datagram failed, then correlate topology and per-port evidence.

Use link and error counters to localize faults

EtherCAT SubDevice Controllers expose standardized diagnostic registers for port link state and error counters. Vendor tools may label receive errors, CRC/frame errors, forwarding errors and lost-link counters differently, and some counters are optional. Establish a baseline after power-up because switching events can increment counters; counters that continue increasing during normal operation deserve investigation.

Counter-to-cause matrix

Commission a PLC, I/O and servo network

Use an isolated machine state with torque/energy risks controlled. The sequence below is cross-vendor; the exact commands and safety validation belong to the installed products.

Twelve-step commissioning workflow

1. Record MainDevice/runtime, network adapter, firmware, licenses and supported EtherCAT features.
2. Inventory every SubDevice's exact identity, revision, ESI source, port order and power needs.
3. Draw the expected topology including junction port numbers and detachable machine modules.
4. Install controlled ESI files and create/scan the network without enabling outputs.
5. Resolve every expected-versus-actual identity and order difference.
6. Select PDOs and export a mapping report with direction, offset, type, scale and safe default.
7. Configure mailbox startup parameters individually and preserve any abort/status evidence.
8. Set bus and PLC/motion task cycles within documented capabilities.
9. Configure DC/synchronization only for devices/modes that require and support it.
10. Transition INIT to PREOP to SAFEOP while verifying input data, state and AL status.
11. Under the approved machine procedure, transition to OP and test one output/axis at a time.
12. Inject controlled loss of link/frame or device power in a suitable test system to prove watchdog, diagnostics, safe state and recovery.

Interactive practice boundary

Use the industrial communication protocols lab to practise separating cyclic data, configuration, topology, device state and fault evidence. It does not emulate EtherCAT ASIC processing, Distributed Clock accuracy, electrical signalling, servo-loop timing, Safety over EtherCAT or ETG conformance. Validate those properties with the approved MainDevice, SubDevices, capture/diagnostic tools and machine procedure.

Diagnostic answer map for search and AI-assisted troubleshooting

Frequently asked questions

What is the difference between an EtherCAT MainDevice and SubDevice?

The MainDevice configures the network and originates EtherCAT frames. SubDevices process assigned data in those frames and forward them. Older documentation commonly calls these roles master and slave.

Does every PLC with an Ethernet port support EtherCAT?

No. The controller/runtime and network interface need an EtherCAT MainDevice stack, driver, engineering support and the required optional capabilities. Standard TCP/IP, PROFINET or EtherNet/IP support does not automatically add EtherCAT.

What information is stored in an EtherCAT ESI file?

An ESI can describe device identity/revisions, physical ports, SyncManagers, cyclic PDO choices, mailbox protocols, Distributed Clock modes and other configuration capabilities. The actual file contents vary by product.

Why does the scanned EtherCAT topology differ from the PLC project?

A cable may enter a different port, a junction branch/order may have changed, a terminal may be inserted/missing, or the project may contain a different revision. Compare the first mismatch and every branch port before accepting changes.

What happens in EtherCAT SAFEOP state?

In principle, input process data can be exchanged while outputs remain in their defined safe behavior. A device that will not reach OP commonly has a PDO, synchronization, watchdog or application error; inspect its AL status and manual.

What causes an EtherCAT Working Counter mismatch?

An addressed operation did not get the expected participation. Causes include missing/wrong-state devices, topology/configuration differences, inaccessible mapped memory, intermittent links, power resets or timing/state faults. Diagnose the affected datagram and topology boundary.

How do EtherCAT Distributed Clocks work?

DC-capable SubDevices contain hardware clocks. The MainDevice measures propagation relationships, selects/uses a reference and continuously aligns other clocks so local input/output events can occur at coordinated times. Configuration and device mode determine the actual result.

Can I put a normal Ethernet switch in an EtherCAT device line?

Do not treat an ordinary switch as an EtherCAT junction. Build branches with supported EtherCAT ports/junctions and follow the MainDevice and device documentation. A separate switched Ethernet network can coexist through designed interfaces.

How do I diagnose intermittent EtherCAT dropouts?

Trigger a capture on the first state/WKC fault and save topology, affected datagram, AL status, link state, per-port receive/CRC and lost-link counters, DC deviation, device power and machine event. Counters that keep increasing under normal operation localize the boundary.

Is Safety over EtherCAT the same as ordinary EtherCAT I/O?

No. Fail Safe over EtherCAT uses a certified safety communication layer and safety devices/application lifecycle. Standard EtherCAT diagnostics can support investigation, but safety design, modification and validation require the applicable certified products and procedures.

Sources, review scope, and limitations

This guide was reviewed on August 28, 2026. EtherCAT is standardized in IEC 61158 and IEC 61784 and maintained through the EtherCAT Technology Group ecosystem. Public technology pages explain the shared principles; exact controller classes, optional functions, timings and device behavior remain product-specific.

• EtherCAT technology, functional principle, diagnostics and profiles — EtherCAT Technology Group
• EtherCAT Compendium — EtherCAT Technology Group
• ETG.2200 EtherCAT Implementation Guide — EtherCAT Technology Group
• ESI downloads and best-practice resources — EtherCAT Technology Group
• EtherCAT Distributed Clocks — Beckhoff Information System
• EtherCAT diagnostic capabilities — Beckhoff
• EtherCAT ESC technology and error-counter interpretation — Beckhoff
• EtherCAT diagnosis and port counters — ABB PLC Help
• EtherCAT communication and ESI use — AutomationDirect
• PDO mapping and ESI selections — AutomationDirect

The illustrations are conceptual, not topology, wiring, timing or safety drawings. Published headline performance values are not a guarantee for a particular PLC, network interface, cycle load, cable plant or motion system. Changes to PDO mapping, state transitions, Distributed Clocks, drive control words, topology or safety communication can energize outputs or motion; commission only under the site's approved risk controls and exact manufacturer procedures.