What are the limits and constraints of EtherCAT? The most useful answer is not a list of disadvantages. EtherCAT has several different kinds of boundary: physical-link limits, address-space limits, cycle-budget limits, device-response limits and feature-support limits. Confusing those layers produces bad engineering decisions. A 100 m copper limit, for example, applies to one 100BASE-TX link between nodes; it is not a 100 m cap on the complete EtherCAT machine. Likewise, 65,535 addressable SubDevices is a protocol scale, not a guaranteed real-world node count at a chosen cycle time.[1]

This guide focuses on where EtherCAT stops being “automatic”. For the underlying mechanics see how EtherCAT works; for headline values see the separate technical specifications.

Distance is a per-link constraint, not a network-length headline

Classic copper EtherCAT commonly uses 100BASE-TX, with up to 100 m between two nodes. Because each EtherCAT node terminates and forwards the physical link, another active node starts another link budget. Fibre such as 100BASE-FX can be used where a longer single span is needed, subject to the actual optical interface specification.[1]

This is why a generic Ethernet cable-length number should not be copied directly into a complete EtherCAT network-length calculation.

Installation quality can become the real physical limit

ETG.1600 treats cable construction, shielding, grounding, bend radius, moving-cable duty and environmental exposure as engineering requirements rather than cosmetic details. In an electrically noisy machine, a link that is well inside 100 m can still become unreliable if connector assembly, shielding or routing is poor.[2]

That matters around drives, contactors and high-current motor wiring. A healthy Link LED does not prove that the physical layer is clean under all machine states. Port error counters and CRC behaviour belong in the EtherCAT diagnostic process.

The node-address space is far larger than most practical control systems

EtherCAT documentation refers to a theoretical scale of up to 65,535 SubDevices. Long before many applications approach that number, the MainDevice's supported node count, ENI complexity, process-image size, datagram plan, CPU budget and requested cycle time become the practical limits.[1]

A hundred slow digital I/O slices and a hundred synchronized servo axes are not equivalent loads. Network size has to be measured in devices and bytes and timing requirements, not in node addresses alone.

Fast communication cannot make slow I/O physics disappear

A common sizing mistake is to set a 250 µs EtherCAT task and assume every signal in the machine becomes a 250 µs signal. It does not. A device's local filter, A/D conversion, sensor physics, drive control loop and actuator response remain independent limits.

Concrete example: Beckhoff's EL1008 EtherCAT digital input terminal specifies a typical 3 ms input filter and no Distributed Clocks support. Reading the terminal four times per millisecond cannot turn that 3 ms physical input behaviour into a 250 µs input response.[3] The same distinction matters when selecting high-speed encoders, measurement I/O or motion hardware.

Process-data volume consumes cycle budget

Illustrative calculation: if 20 axes each exchange 24 bytes of commands and 24 bytes of feedback, the application process image is 960 bytes. At 100 Mbit/s, serializing those 960 bytes alone has a raw lower bound of about 76.8 µs. That figure excludes Ethernet/EtherCAT overhead, Working Counters, propagation, ESC forwarding, MainDevice execution and the devices' local processing.

The point is not to claim a 76.8 µs cycle; it is to show why data volume still matters even with efficient on-the-fly processing. Data-heavy acquisition, vision or unusually large cyclic payloads may need segmentation or a higher-rate extension such as EtherCAT G/G10.

Distributed Clocks are a capability, not a universal property

ETG describes Distributed Clocks as a hardware-assisted synchronization mechanism capable of system jitter significantly below 1 µs when correctly implemented. The important qualification is when supported and configured. Not every EtherCAT SubDevice implements DC, and supported sync modes differ by product.[4]

For coordinated robotics or electronic gearing, read the ESI and drive manual rather than assuming that the EtherCAT connector guarantees the required timing mode. Network clock accuracy also does not override slower mechanical or measurement dynamics.

A non-redundant line still has a physical failure path

EtherCAT topology is flexible, but a simple line is still a line. A break can isolate devices beyond the fault from the MainDevice. EtherCAT cable redundancy addresses this by returning the last node to a second MainDevice Ethernet port and letting the MainDevice redundancy function handle the failure.[5]

That mechanism is not automatic in every system. It needs the second port, MainDevice feature support and the right configuration. A MainDevice hardware failure is a different availability problem again and requires controller-level redundancy or Hot Standby if the application demands it.

MainDevice control is both a strength and an architectural dependency

Only the MainDevice actively initiates EtherCAT frames within a segment. That controlled medium access is a major reason timing is predictable, but it also means that normal cyclic network operation depends on the MainDevice application. If the MainDevice stops, the field network does not simply continue as an autonomous peer-to-peer LAN.[4]

The generic master/slave concept is useful background, but EtherCAT's on-the-fly access and logical process image are more specific than a generic polling bus.

SubDevice-to-SubDevice data is not unrestricted one-cycle peer traffic

EtherCAT does support SubDevice-to-SubDevice communication, but ETG documents an important timing qualification. A topology-dependent transfer from an upstream device to a downstream device can be arranged within one communication cycle; topology-independent SubDevice-to-SubDevice communication generally takes two cycles because the MainDevice manages medium access and process-image exchange.[6]

For most machine-control applications that is entirely acceptable. For an architecture that expects arbitrary nodes to originate independent traffic to arbitrary peers at any instant, however, EtherCAT should not be modelled like conventional switched Ethernet.

Interoperability does not mean identical application behaviour

Conformance is a prerequisite for devices from different vendors to cooperate on the same EtherCAT network. It does not mean that every vendor exposes identical PDO maps, CoE objects, drive profiles, DC modes, FoE/EoE support or vendor-specific parameters.[7]

This is particularly important in servo replacement work. Two EtherCAT drives may both be conformant yet require different ESI files, object mappings and commissioning parameters. Actual device integration has to be checked against the specific model and revision.

MainDevices do not all implement the same optional feature set

ETG distinguishes MainDevice implementations by supported functionality. Embedded or resource-constrained controllers may intentionally omit optional features. Cable redundancy, Hot Connect combinations, Distributed Clock handling and some mailbox services therefore have to be checked in the actual MainDevice documentation rather than inferred from the word “EtherCAT”.[4]

ETG's Hot Connect guidance explicitly notes that a MainDevice can impose product-specific limits such as the number of Hot Connect groups or restrictions when Hot Connect is combined with redundancy or DC.[8] This is an engineering-tool and controller-selection issue as much as a field-device issue.

A normal Ethernet device cannot simply become an EtherCAT SubDevice

A camera, PC, printer or ordinary Ethernet sensor does not become an EtherCAT SubDevice because it has an RJ45 port. ETG's EoE mechanism integrates standard Ethernet devices through a suitable EtherCAT Switchport; the Ethernet frames are then tunneled over EtherCAT mailbox communication.[9]

This is a useful integration feature, but it is different from inserting a standard Ethernet switch or arbitrary Ethernet endpoint directly into the real-time EtherCAT strand. For basic terminology see the communication-port guide and protocols over Ethernet.

EoE is useful IT tunnelling, not unlimited Ethernet bandwidth

ETG notes that EoE-capable SubDevices typically have enough performance and memory to handle one complete Ethernet frame at a time, and recommends that the MainDevice avoid launching multiple EoE frames in parallel to such a device. Frames may need to be queued and fragmented through the mailbox path.[9]

So EoE is appropriate for configuration, web interfaces and many standard Ethernet services, but a high-bandwidth camera stream should not be budgeted as though the EtherCAT mailbox path were an unrestricted IT backbone. Real-time control and bulk-data traffic need separate capacity planning.

Working Counter detects inconsistency; it does not diagnose everything

The Working Counter (WKC) is excellent for detecting that the expected participants did not all process a datagram. ETG's user-diagnostic material also makes clear that an invalid WKC is essentially a correct/incorrect result, not a complete root-cause code. Missing physical nodes, reset devices and devices outside Operational state can all produce WKC errors.[10]

Finding the fault still requires link status, port error counters, AL status, state-machine information and actual-versus-configured topology. That is especially important when a SCADA or HMI screen continues displaying the last valid process value after the network has become invalid.

Functional safety does not remove cybersecurity or machine-safety obligations

Safety over EtherCAT (FSoE) addresses safety-related communication. It does not turn the entire EtherCAT network into a cybersecurity mechanism, and the presence of FSoE does not by itself establish the SIL or Performance Level of the complete machine. Sensor, logic, actuator and validation requirements remain part of the safety function.

Likewise, industrial cybersecurity has its own concerns: access control, segmentation, engineering-station security and lifecycle management. The separate EtherCAT security article should keep those boundaries explicit.

Cost is an application constraint, not a protocol defect

EtherCAT does not inherently require a paid ETG membership or per-node protocol royalty for a machine builder. The practical cost comes from the selected controller, I/O, drives, cabling, engineering software and commissioning effort. For a high-performance motion system that architecture can reduce total machine complexity; for a few slow I/O points it may be more capability than the application needs. The separate licensing and cost guide covers that distinction.

A practical pre-design checklist

First, obtain the real MainDevice limits for node count, process data and minimum supported task cycle. Second, identify the slowest local device response, not only the network cycle. Third, check the installation against ETG.1600 for cable, EMC, motion and environmental conditions. Fourth, verify DC, Hot Connect, redundancy and mailbox options per ESI/manual. Fifth, measure the actual process-data and CPU budget at the target cycle. Those five checks usually reveal the real project boundary long before the theoretical protocol maxima do.