EtherCAT stands for Ethernet for Control Automation Technology. It is an industrial communication technology for exchanging time-critical data between a controller and field equipment: remote I/O, measuring devices and servo drives, for example. It belongs to the real-time Ethernet family. Its value is not simply a high bit rate; it is the ability to organize control data around the timing requirements of a machine. ^[2]

A useful starting question is: what must this device do, and when must its data be available? An Ethernet socket does not answer that question. Neither does an “EtherCAT supported” label without a device role, process-data definition and supported operating mode. This guide concentrates on classic 100 Mbit/s EtherCAT; the P, G and G10 extensions are addressed separately.

Start with the data contract, not the cable

Before connecting an axis, identify the command it will consume and the feedback the controller will trust. “A 32-bit position” is incomplete: signedness, units, scaling, reference position and validity all matter. The same discipline applies to encoders, analog measurements and digital I/O. A connection can be operational while the application interprets its data incorrectly.

Process Data Objects (PDOs) carry the values needed repeatedly during operation. Service Data Objects (SDOs) provide requested access to parameters instead. PDO selection is part of the configuration, not something that can safely be inferred from the connector or channel count. Some devices offer editable mappings; others restrict the available combinations. ^{[3] [4]}

Which way is the data moving?

Device terminology	Meaning at the controller
Transmit PDO / TxPDO	Controller input. The field device transmits a measurement, status or other mapped value.
Receive PDO / RxPDO	Controller output. The field device receives a mapped command or setpoint.
PDO mapping	The selected objects, data types and bit/byte layout. An object must support the required mapping direction.
SDO access	A requested parameter operation. A successful read does not prove that the cyclic data layout is correct.

CoE (CANopen over EtherCAT) brings the CANopen application approach—object dictionaries and profiles—to EtherCAT. An object is identified by index and subindex and has a defined type and access permission. This does not mean that the EtherCAT cable carries CAN electrical signaling or uses CAN bus arbitration. CoE itself is optional for an EtherCAT device; the supported services must be checked rather than assumed. ^[5]

That distinction matters when choosing compatible devices and sensors. A conventional encoder can be connected through a suitable input terminal, but its pulse or other output interface does not become a native EtherCAT interface merely because the terminal is on EtherCAT. Document the entire signal path, including the conversion between the sensor and the network.

Keep the device description and the real device in agreement

An ESI file, or EtherCAT SubDevice Information file, describes device capabilities for the engineering tool. Older documentation calls it EtherCAT Slave Information. It is XML, not a firmware image or a PLC application. Check the actual vendor/product identity, revision and supported firmware against the intended ESI and PDO configuration. An XML file for a similar name is not adequate evidence of compatibility. ^[6]

Two physically identical units are another trap. A position-based configuration may identify the correct device type without proving that it is connected to the intended machine function. Check supported explicit identification or alias mechanisms where swapping two devices could swap two axes or stations. Network position and functional identity are different checks. ^[7]

Keep commissioning changes in the project’s startup configuration, where appropriate. A replacement device may return with factory filter and scaling settings even though the old unit retained its online changes. The relevant servo manuals should establish the exact interface, operating mode and parameter-storage behavior; a family name is not a substitute for that record. ^[5]

A worked process-image example

Why the EL3102 contributes eight bytes, not automatically four

The real Beckhoff EL3102 has two differential ±10 V inputs with 16-bit resolution including the sign. Its manufacturer lists an 8-byte input process image, with standard and compact image options. The listed conversion time is approximately 60 µs, or approximately 40 µs in fast mode. Channel resolution alone therefore does not specify either the selected PDO length or the complete measurement delay. ^[11]

It is also a voltage input, not a 4–20 mA current input. A pressure transmitter must have an electrically compatible output or an appropriate interface. The network cannot correct an unsuitable input circuit. Likewise, measurement accuracy and calibration remain separate from the rate at which the measured value is delivered.

The EK1100 provides a second useful distinction: it couples 100BASE-TX EtherCAT to the terminal row’s E-bus. It is not a general TCP/IP gateway or an ordinary switch. Its specified 2 A E-bus supply limit is an electrical design constraint; terminal loads and system/field power supplies still need to be checked even when the network link appears healthy. ^[10]

How a frame serves multiple devices

The master, also called the MainDevice, sends an Ethernet frame through the network. Each field device’s EtherCAT Slave Controller (ESC) reads or inserts its mapped data while the frame is passing. This is on-the-fly processing. A single frame can serve multiple devices instead of requiring a separate application request and reply for every one. Larger or differently scheduled configurations can use more than one frame. ^[1]

This makes EtherCAT master/subdevice communication more specific than the generic phrase “one device controls another.” The master organizes communication; the device application interprets the command. Receiving a target position is not evidence that an axis has reached it. An acceptance test must examine actual feedback and state, not just the transmitted command.

The two ends have different hardware requirements. A master can use a suitable standard Ethernet interface together with the required driver, master runtime and scheduling. A field device requires ESC functionality. The fact that a PLC or PC has an Ethernet port does not establish that it can act in either EtherCAT role.

What “EtherCAT versus Ethernet” actually compares

Ethernet supplies physical and frame-transmission mechanisms; it does not define a universal request/reply application. EtherCAT builds a control-data mechanism on that foundation. EtherNet/IP is a different industrial protocol, not another spelling of EtherCAT. Matching plugs and similar product names do not make their device interfaces interchangeable.

Classic cyclic EtherCAT does not require a separate TCP/IP session to each node. That does not eliminate IP from the entire machine: the controller may use it for HMI or SCADA access, and supported devices may provide additional services such as EoE. Keep those paths separate in the design. A maintenance connection to the wrong communication port can otherwise look like a mysterious device failure.

Treat timing as several requirements, not one headline figure

Bit rate describes transmission speed. Cycle time describes the repeated update interval. End-to-end latency concerns the complete path from a physical change to the result that uses it. Jitter describes variation in the relevant timing. A claim about one does not establish the others. This is the starting point for evaluating real-time performance and building a useful latency budget.

Distributed Clocks (DC) synchronize time bases in devices that support them. Support and configuration both matter: Free Run, SyncManager synchronization and DC are not equivalent modes. Submicrosecond clock synchronization, where supported and correctly configured, is not a promise that the entire sensor-to-actuator path completes in that time. ^[8]

DC aligns supported local clocks with a reference while accounting for propagation delay. Actions need not be triggered simply by the instant a frame arrives. The data must still arrive before the device needs to use it. Clock synchronization does not remove the master’s application deadline. ^[1]

For a PID control loop, ask when a sample was taken, when the controller used it and when the output took effect. A fast communication cycle cannot by itself repair an unsuitable filter or a poorly chosen control task. The commissioning record should describe those application deadlines rather than replacing them with the network’s bit rate.

Lay out the field network deliberately

An EtherCAT line, star or tree is built using the appropriate ports and junction devices. An ordinary Ethernet switch is not a drop-in substitute for a classic EtherCAT junction. In a line, full-duplex communication provides a logical return path; a separate cable from the last node back to the master is not required simply to make ordinary line communication work. ^[9]

The familiar 100 m copper limit applies to an appropriate 100BASE-TX link between neighboring ports, not to the total length of a machine’s network. Select the cable type, connectors and installation method for the environment, including repeated movement where applicable. The link-length limit must not be transferred unchanged to fiber or another physical medium. Follow the specific device’s IN/OUT port documentation. ^[10]

Redundant cabling is a configured feature. A physical ring requires the appropriate master port and software support. Connecting spare ports together does not establish redundancy. Hot Connect is similarly a planned grouping and application behavior, not permission to unplug an arbitrary device from a running machine.

Diagnose communication before changing the application

Start by separating four observations: a missing device, a failed state transition, invalid cyclic data, or a wrong application value. They are not interchangeable fault descriptions. Save the actual topology and diagnostic state before changing several parameters at once. The fault-finding process should preserve enough evidence to explain why a corrective action worked.

A missing device: check the selected master interface, device power, port direction and physical path. If several downstream units disappear together, inspect their common upstream connection before treating them as independent failures. A device stuck below OP: compare requested and actual states, AL status information, identity/revision, PDO lengths, startup commands and synchronization settings. ^[15]

The EtherCAT State Machine is a communication state machine. INIT provides neither normal mailbox nor process-data exchange; PREOP enables mailbox/configuration; SAFEOP permits input updates with device/watchdog-dependent output handling; OP enables operational process-data exchange. BOOT, where supported, is a separate firmware-transfer state. SAFEOP is not a certificate that the complete machine is safe. ^[12]

Nor does OP mean “drive enabled.” A drive or valve has its own application state. Check enable conditions, limits, actual axis status and Safe Torque Off independently. A functioning network is only one condition for controlled motion. ^[13]

Working Counter and data freshness: use the master’s expected WKC for the configured datagram rather than treating WKC as a convenient count of healthy devices. Also distinguish it from TwinCAT’s WcState status. The documented WcState values are 0 for valid and 1 for invalid real-time communication; input data may remain at its last value after invalid exchange. A stationary number on a screen is therefore not proof of a live measurement. ^[14]

An intermittent failure: record link-loss and receive-error counters, their timing and the master task load before clearing them. Repetition during a particular machine movement suggests a different investigation from repetition during a task-load peak, but correlation still needs confirmation. OP with the wrong value: return to direction, data type, engineering units and channel status instead of repeatedly reconnecting the network.

For authorized passive inspection at a suitable capture point, Wireshark’s display filter is ecat. The fields ecat.cmd and ecat.cnt expose the command and Working Counter respectively. These are display filters, not scan or write commands. An office-switch connection should not be assumed to reveal all EtherCAT traffic; the capture arrangement must be chosen for the actual topology. ^[16]

Specify the loss-of-communication response separately

There is no universal rule that every motor stops, or that every output holds its last command, when EtherCAT communication is lost. Device watchdog behavior, application logic and the safety function have different responsibilities. Define the required response and restart conditions before the test. Disabling protection to obtain an OP indication is not a substitute for resolving the fault.

Safety over EtherCAT (FSoE) addresses safety communication using the black-channel approach. The manufacturer identifies IEC 61784-3 and IEC 61508 support up to SIL 3. This does not turn an ordinary I/O device into a safety device or establish SIL 3 for an entire machine. The selected safety components and machine safety function still require their own assessment. ^[17]

Cybersecurity asks different questions: who may connect, alter a program or access the controller from another network? FSoE must not be treated as general-purpose encryption or user authentication. Define OT/IT boundaries and permitted communications. In this context, protecting the master’s engineering and supervisory connections is different from inserting an arbitrary firewall into a classic EtherCAT chain. ^[18]

Beckhoff, third-party devices and the limits of a compatibility claim

Beckhoff originated EtherCAT, but the technology is not confined to Beckhoff equipment. Check the exact role nevertheless. Delta Motion documents RMC200 with an ECAT module as a MainDevice, not as an EtherCAT SubDevice or a MainDevice-to-MainDevice link. This is a practical example of why “supports EtherCAT” needs a qualifier before equipment is connected. ^[2]

Conformance and interoperability testing provide important evidence, but they do not make different products functionally identical. A substitute still needs the required objects, operating modes, electrical characteristics and compatible revision. Standards compliance and acceptance of the machine’s behavior are separate checks. ^[21]

The master platform also determines the programming languages and engineering tools. EtherCAT is not itself a PLC programming language. Project cost includes the selected runtime, development environment, diagnostics and maintenance as well as the field equipment. TwinCAT runtime licensing, for example, is a separate product consideration; protocol support does not imply that every implementation or tool is free. ^[22]

P, G and G10 solve different extension requirements

EtherCAT P combines communication with two separate 24 V supplies using compatible cabling and connectors. Do not treat it as a generic Power over Ethernet port. Verify the interface and power budget rather than relying on a similar-looking connector. ^[19]

EtherCAT G and G10 address 1 Gbit/s and 10 Gbit/s transmission respectively. Supported branch arrangements can integrate classic 100 Mbit/s devices, but they do not make those devices operate at a higher speed. Changing a cable does not turn a classic device into a Gigabit Ethernet device. Check extensions and device support against the actual master and branch hardware. ^[20]

Choose against a machine requirement. Coordinated axes, robotics, synchronized measurement and dense I/O impose different constraints. Compare alternatives such as PROFINET or SERCOS using equivalent device scope, update requirements, diagnosis and maintenance assumptions—not a collection of unrelated headline maxima. Keep practical limits visible, and do not accidentally place edge analytics or supervisory reporting in a time-critical motion-control dependency.