EtherCAT

What EtherCAT Is and What Is Being Decided

Fieldbus generations are latency stories. Classic fieldbuses, Modbus serial, PROFIBUS, DeviceNet, exchange device by device and measure loop time in milliseconds to tens of milliseconds. Industrial Ethernet with switches and per-device telegrams, Modbus TCP and its cousins, moves bytes fast but re-enters the store-and-forward world, and controller loops land in the several-millisecond class. EtherCAT's on-the-fly processing removes the per-device assembly entirely: one frame tours the whole network, every device touches it in passing, and the network behaves like one wide I/O register with nanosecond-scale per-node cost. The measured consequences are stable catalog numbers: roughly a thousand digital I/O updated in about 30 microseconds, machine cycles of 100 microseconds class on compact nets, and 1 millisecond class on large ones, numbers that turned multi-axis motion coordination, high-speed packaging, and measurement synchronization from special hardware problems into configuration problems.

What is being decided at purchase is which of three commitments the machine actually needs, because EtherCAT priced into a slow machine is capital parked. First, cycle time class: if the process is valves and conveyors, a millisecond-class bus of any flavor carries it, and EtherCAT is bought for its ecosystem and diagnostics instead; if the process is coordinated servo motion, flying shears, registration, or multi-channel measurement, the cycle and sync class is the purchase driver. Second, synchronization quality: distributed clocks hold device sample and output times together well under a microsecond, which is what makes multi-axis interpolation and synchronized sampling real; without that need, the buyer can trade sync rigor for simplicity. Third, ecosystem fit: CoE device profiles for drives and I/O, SoE for servo-heritage devices, gateway devices that bridge legacy islands, and the safety layer FSoE for SIL-rated safety over the same cable. Each commitment selects hardware, and the selection chapter is organized around exactly that.

Positioning against the neighbors is one paragraph of honesty. Against PROFINET RT and Modbus TCP: EtherCAT's performance class sits above the switched-Ethernet mainstream, at the cost of a dedicated real-time segment that mainstream IT traffic does not ride. Against PROFINET IRT and SERCOS-like deterministic Ethernets: same performance tier, choice driven by the controller vendor's ecosystem more than by raw numbers. Against IO-Link: not a competitor but a layer, IO-Link is point-to-point device communication from sensors to an IO-Link master, and that master's backplane or uplink is often exactly this network. Against the plain fieldbus gateway that bridges Modbus to PROFINET: the gateway is the tool for legacy islands, while EtherCAT is the native backbone the new machine is built on. And inside the cabinet, the HMI panel, the PLC, the drives, and the remote I/O are all citizens of whatever backbone the architect picks, which is why this decision is made at machine architecture time, not at component shopping time.

One terminology note that keeps specifications aligned with the standards text: IEC 61158 names the controller a MainDevice and the field devices SubDevices; the older master and slave vocabulary survives in practice, and this page uses the standard terms with the familiar ones in parentheses where helpful.

On-the-Fly Processing, Cycles, and Distributed Clocks

The mechanism deserves one precise paragraph. Each SubDevice contains an EtherCAT Slave Controller, an ESC, implemented as an ASIC, FPGA logic, or integrated controller silicon, that sits on the Ethernet path between the device's two ports. As a frame streams through, the ESC recognizes the device's logical addresses in the frame's data areas, extracts input bytes and inserts output bytes on the fly, and forwards the frame with no store-and-forward delay beyond its nanosecond-scale processing. Frame order around the physical loop defines a natural sequence, and the MainDevice, having sent the frame and received it back, holds fresh data from every SubDevice in one round trip. The bandwidth arithmetic is equally direct: at 100 Mbit/s full duplex, the frame rate ceiling translates to the headline figure, on the order of a thousand digital I/O refreshed every 30 microseconds, and real machines budget cycle times of 50 to 200 microseconds for compact motion nets and 1 millisecond class for plant-scale ones.

Distributed clocks are the second mechanism and the reason motion converges. One reference clock, in the first SubDevice with DC support, is elected; every DC-capable device in the loop measures frame transit through itself and drifts its local clock onto the reference. The result is a network-wide time base whose mutual offset is held well under a microsecond, with jitter specifications in the tens to hundreds of nanoseconds on healthy installations. Control outputs can then be issued at synchronized future instants, SYNC events, so that dozens of drives begin their interpolation step and dozens of analog channels sample their value at the same physical moment. The measurement payoff is the same mechanism: synchronized sampling across remote I/O turns distributed sensors into one coherent dataset, which is why test benches and grid analyzers adopted the same fieldbus that runs packaging machines.

The state machine is the operational contract between MainDevice and SubDevice, and its names appear in every diagnostic screen: INIT, PRE-OPERATIONAL, SAFE-OPERATIONAL, and OPERATIONAL. A SubDevice reaches SAFE-OP with inputs valid but outputs held, and OP with outputs live; transitions are driven by the MainDevice after configuration and watchdog arming. The practical meaning for the buyer is commissioning language: a SubDevice stuck in PRE-OP is a configuration disagreement, profile objects, addresses, or sync settings, and the diagnostic discipline of Chapter 6 is built on reading exactly that state. Watchdogs guard both directions, a SubDevice that stops seeing MainDevice traffic drops its outputs to the fail state within the configured time, and a MainDevice that stops seeing a SubDevice's data faults the network in milliseconds, which is the failure behavior the machine's safety concept relies on.

Topology follows from the port structure. SubDevices have two or more ports and pass the physical line through, so the native topology is the line, with trees and stars built from junction SubDevices and no Ethernet switches anywhere in the real-time path. Hot-connect segments, couplers that detach a live machine section without dropping the loop, and cable redundancy, closing the line into a physical ring so one cable break halves nothing, are catalog options that price in at architecture time. Distance per hop is standard Ethernet physics, 100 meters on industrial Cat 5 class copper between devices, with fiber versions stretching each hop to kilometers where the plant spreads, and the topology drawing with distances on it belongs to the RFQ, not to site improvisation.

The profile layers carry the semantics. CoE, CANopen over EtherCAT, is the dominant object dictionary world: drives speaking the CiA 402 motion profile, I/O modules, valves, encoders, all configured through standard object dictionaries over SDO-like communication. SoE, the Servo Drive Profile, serves the servo-heritage drive families; FoE moves firmware files; EoE tunnels standard Ethernet for diagnostics and non-real-time traffic on the same cable. Safety over EtherCAT, FSoE, carries SIL 3 safety data as a black-channel protocol over the same medium, so the safety chain shares the plant but not the failure modes of the standard traffic. The RFQ names the profiles per device class, because a drive without CoE in a CoE machine is an integration tax paid forever.

Devices, Implementations, and Duty Boundaries

MainDevice selection divides by controller platform. The native path is a PLC whose CPU carries integrated EtherCAT MainDevice functionality, configured in the PLC engineering tool, with the drive and I/O ecosystem aligned to it; this is the low-integration-risk default for machine builders already in that controller family. The open path is an industrial PC running a real-time MainDevice stack, software-based or NIC-assisted, which suits test benches, measurement machines, and builders whose application lives in code rather than in ladder. The choice prices differently, native PLC MainDevices carry the ecosystem and the support, IPC MainDevices carry the timing headroom and the software freedom, and both drive the SubDevice compatibility universe, so the RFQ starts by naming the MainDevice platform and version.

SubDevice selection divides by function first, implementation second. Function: I/O terminals and block I/O, the dense digital and analog points; servo drives with CoE and DC, the motion population; encoder inputs reading absolute and incremental feedback; valve terminals; measurement devices; and gateways, Modbus, PROFIBUS, CAN, and IO-Link masters with an EtherCAT uplink, which fold legacy and device-level islands into the synchronized backbone. Implementation: ESC silicon families differ in performance class, port count, DC precision, and PDI, the process data interface, width, and the datasheet rows that matter are cycle-time support at the claimed I/O count, DC drift specification, and profile conformance, because the EtherCAT label alone guarantees none of the three at machine requirements.

Duty boundaries, sentence by sentence. Machine with a handful of slow actuators and no motion: a conventional fieldbus or remote I/O over Modbus TCP carries it for less integration effort, and EtherCAT is bought there for future-proofing, an honest reason, priced honestly. Machine with coordinated motion or synchronized measurement: EtherCAT's tier, with PROFINET IRT as the ecosystem-alternative at the same tier. Sensor-level intelligence and parameterization: IO-Link to a master, whose uplink is where this backbone earns its numbers. Plant-spanning data, dashboards, IT bridges: that traffic rides standard Ethernet above the real-time segment, through the controller or an EoE channel, not by putting web cameras on the motion network. Hazardous areas and intrinsic safety: fieldbarrier and segment coupler families extend the reach with their own engineering, named in the RFQ by certification. And the ultimate boundary is the same as every fieldbus: the best network cannot rescue an architecture whose control loops were never coherent to begin with.

Key Specification Parameters

The decode table is the architecture contract; each row is a number that either appears in the RFQ or gets discovered during commissioning.

The cycle row is budgeted, not quoted: cycle time equals frame round trip plus MainDevice processing plus task jitter, and the honest RFQ computes it for the actual I/O count rather than repeating the 30-microsecond headline. The same discipline applies to the DC row: synchronization quality is a property of the whole installation, clock hardware, topology, and traffic included, and the architecture states the class it will verify at commissioning, with the drift counters as the acceptance evidence.

The profile row carries the integration risk. A drive speaking a vendor dialect instead of CiA 402, an I/O family without CoE objects, a gateway that bridges bytes but not semantics: each is a working network with an unusable machine on top. The RFQ lists profiles per device class and requires conformance-tested status, and the vendor's implementation guide naming the tested MainDevice pair is part of the quote, because conformance is proven pairwise, in the standards' own vocabulary.

The redundancy and diagnostics rows decide availability and commissioning economics. Cable redundancy closes the ring and survives one break; MainDevice redundancy adds a standby controller with its own switchover time; neither is free, and the machine's availability target, not the catalog's ceiling, chooses. Diagnostics are where EtherCAT pays rent: state machine visibility per SubDevice, port error counters, and DC drift readouts turn network faults from archaeology into a screen, and the acceptance test at commissioning exercises them deliberately, one pulled connector at a time.

The conformance row closes the table with the standards themselves: EtherCAT is standardized as one of the IEC 61158 fieldbus types and in the IEC 61784 profile families, with the EtherCAT Technology Group, ETG, holding the specification and conformance testing regime. An RFQ that cites the profile family and requires ETG conformance-tested devices has done what a standards citation can do; the remainder is the pairwise engineering the implementation guide documents.

Selection Decision Factors and RFQ Language

The selection sequence is an architecture review in seven steps, and the order is the point.

1. State the machine's timing truth: control loop rates per axis, required synchronization between axes or channels, and worst-case scan for logic. This fixes the performance class the network must verify, or proves a slower bus would carry the machine and saves the premium.
2. Choose the MainDevice platform: native PLC integration for ecosystem and support, IPC with a real-time stack for headroom and code freedom. Name platform, version, and supported SubDevice count.
3. Lay out the SubDevice census: I/O points by signal class, drives with their profile, encoders, valve terminals, gateways for legacy islands including IO-Link masters for sensor blocks. This fixes the scan budget arithmetic of Chapter 4.
4. Draw the topology with distances: line, junctions, hot-connect segments, fiber hops, redundancy ring if the availability target demands. This fixes the cable schedule and the couplers on it.
5. Decide the safety architecture: which functions run FSoE over this network, which stay hardwired, and the safety controller that terminates them. This adds the FSoE conformance rows to the device RFQs.
6. Plan commissioning acceptance: DC drift measurement, cycle verification at full I/O count, redundancy switchover test, watchdog behavior on cable pull. This is the evidence file the machine ships with.
7. Write the RFQ per device class with Chapter 4 rows, profiles named, conformance status required, and the tested-with pairing documented.

Cost behavior follows class and integration depth. As a planning spread: an EtherCAT I/O slice prices in the same band as comparable industrial Ethernet I/O, the network premium lives in MainDevice integration effort and engineering tools more than in copper; drive populations price by drive class with the EtherCAT interface as a line item; gateways and IO-Link masters price by bridged complexity; redundancy hardware adds by topology; and the safety layer adds FSoE-capable devices and a safety controller at their own tier. Against a conventional remote-I/O bus on a slow machine, EtherCAT typically lands 10 to 30 percent above on hardware and pays it back only in the timing classes or ecosystem features the machine actually uses; against same-tier deterministic Ethernet, pricing converges and the decision rides the controller ecosystem. The comparison table holds the honest pairs.

The RFQ package is the architecture document plus per-device lines: the timing table from Chapter 4; the SubDevice census with signal classes; the topology drawing with distances and redundancy; MainDevice platform and version; per-device profile requirements, CoE for CANopen-heritage, CiA 402 for drives, FSoE rows where safety flows; conformance status with ETG test evidence and tested-with pairings; cable schedule with classes and lengths; and the commissioning acceptance list with the evidence each test produces. Quotes that answer those lines describe a machine that starts; quotes that answer fewer describe a whiteboard.

System context closes the loop: the same cabinet hosts the servo motor axes whose drives speak CoE, the axis feedback, whether a rotary encoder of the incremental school or an absolute encoder reporting true position after power loss, riding the same synchronized frames, the VFD and soft starter population on slower duties, the inductive sensor and discrete I/O fieldpoints, the HMI panel visualizing state, and the PLC or IPC orchestrating all of it. Each axis that joins the synchronized loop inherits the same clock and the same cycle budget, which is precisely why the census and the timing table of Chapter 4 are maintained as living documents rather than startup relics. EtherCAT is the decision that binds those citizens into one synchronized machine, and it is made, once, at architecture time, with the numbers this page has put on the table.

Installation, Standards, Failure Modes, and Maintenance

Installation follows the drawing or fails by improvisation. Cable classes are industrial Ethernet, shielded, continuous shield termination at every coupler, 100-meter rule per copper hop respected in the schedule, and separation from drive power cables by the plant's EMC convention, a dedicated tray or generous distance, with crossings at right angles where they cannot be avoided. Grounding is the classic single-point discipline on shields, and the DC reference devices, usually the first in the line, mount where the drawing says, because the reference clock belongs to the topology as designed. Junctions, hot-connect segments, and redundancy rings go where the availability plan put them, and every connector seats with its lock engaged: the intermittent field connector is this network's most common fault generator, as it is on every fieldbus that ever shipped.

Commissioning produces the evidence file: bus scan against the census, every SubDevice reaching OP; DC drift counters read and recorded at temperature; cycle time verified at full I/O count under load; watchdog behavior proven by pulling the line at a safe moment, outputs falling to their configured fail state inside the configured time; redundancy switchover tested with the machine in a safe state; and the safety layer's FSoE validation executed per its own standard's proof procedure. That file is the machine's network birth certificate, and every future fault investigation starts from it.

The standards frame is precise and worth citing by number: EtherCAT is standardized within IEC 61158 as a communication type and within IEC 61784 as profile family CPF 12; the EtherCAT Technology Group maintains the specifications, the conformance testing regime, and the implementation guides; FSoE, Fail Safe over EtherCAT, is evaluated under IEC 61508 with the black-channel principle separating transport from safety; and the physical layer inherits standard Ethernet component standards, which is why industrial Ethernet cable and connector practice applies unchanged. Citing the profile family and the conformance requirement in the RFQ is how a buyer buys the standard rather than a brand.

Failure modes rank by field history. Physical layer faults lead: crushed cables, unseated connectors, and failed couplers present as CRC and lost-frame counters rising and a SubDevice dropping from OP, and the ring, when present, holds the machine while the counters point at the segment. EMC corruption follows, usually on analog channels as noise that arrives synchronized with drive switching, and the cure is the cable and grounding discipline of the installation paragraph, not filter shopping. Configuration drift appears after engineering changes, a SubDevice left in PRE-OP after an object mismatch, and the state machine's exact vocabulary is the diagnostic. DC drift beyond class shows as motion coordination quality falling at temperature, read directly from the drift counters, and cured by clock hardware and topology review. Watchdog and fail-state misconfigurations, outputs that fail in the wrong direction, are safety-architecture findings that commissioning's pull-the-cable test exists to catch before production does. And firmware or stack version mismatches between MainDevice and a vendor SubDevice, the quietest failure, present as intermittent profile oddities, prevented by the tested-with pairing discipline of Chapter 5.

Maintenance is counters and discipline rather than scheduled wear: the network's own diagnostics, port error counters, DC drift, state transitions, are the condition monitoring, read by the controller and trended like any process variable; cable plant gets a visual and connector seating check on the machine's mechanical rounds; and changes to topology or device count reopen the commissioning evidence file, because a new SubDevice is a new timing budget and a new drift population. There are no lubrication points on a fieldbus, and the entire maintenance philosophy is keeping the evidence current so that the day a counter moves, someone knows what it was before.