Industrial Communication — Ch.04: EtherCAT [EN]

STATERA Library · Series 07 · Volume 07 · Chapter 04 · EN
Source: https://github.com/Statera-Library/07_Vol_07_Industrial_Communication/blob/main/Chapter_04_EtherCAT/Chapter_04_EtherCAT_EN.md

Volume 07. Industrial Communication

Chapter 04. EtherCAT

04.01. EtherCAT Operating Principle

EtherCAT is a real-time industrial Ethernet technology designed to exchange process data between a controller and distributed devices with extremely low latency and highly deterministic timing. Within the industrial communication structure, it belongs to the dedicated EtherCAT chapter alongside EtherCAT Slave Controller, CAN over EtherCAT, functional safety, and servo-network design topics.

The fundamental operating principle of EtherCAT differs significantly from conventional Ethernet communication. In a traditional Ethernet network, a frame is normally received by a device, processed by its protocol stack, and then another frame may be transmitted toward the next destination. EtherCAT instead allows a single Ethernet frame generated by the master to travel sequentially through many slave devices while process data is handled as the frame passes through them.

This mechanism is commonly described as processing frames "on the fly." Each EtherCAT slave examines the passing frame at hardware level and identifies the portion of the EtherCAT datagram assigned to it. Input information can be inserted into the appropriate data field, while output information intended for the device can be extracted simultaneously. The frame therefore does not need to be completely received and independently retransmitted by software at every node.

An EtherCAT network is normally controlled by one EtherCAT master that initiates communication cycles. The master constructs Ethernet frames containing one or more EtherCAT datagrams and sends them into the network. The slaves process the relevant data while the frame propagates through the physical topology. After passing through the final slave, the frame is returned toward the master, completing a communication cycle containing information exchanged with multiple devices.

This architecture produces unusually efficient bandwidth utilization. Instead of generating separate Ethernet frames for every servo drive, I/O module, encoder, or sensor, the master can place process data for many devices inside a small number of frames. Ethernet frame overhead is therefore shared across many transactions. This becomes particularly important in machines containing dozens of synchronized actuators and distributed I/O channels that must be updated every control cycle.

EtherCAT communication is based on standard Ethernet physical-layer technology, but its frame-processing behavior is optimized for deterministic industrial control rather than ordinary packet-switched networking. EtherCAT frames may use a dedicated EtherType, and EtherCAT datagrams carried inside the frame specify commands, addresses, data lengths, process data, and working counters. Hardware-based slave processing minimizes the variable software delays commonly associated with general-purpose Ethernet communication.

A major EtherCAT concept is logical addressing. The master can organize distributed process data as a logical address space rather than treating every transaction as an independent message to an individual device. Slave hardware maps selected portions of this logical space to local memory locations. Consequently, one EtherCAT datagram can read from or write to multiple slaves as it moves through the network, creating an efficient representation of distributed process I/O.

EtherCAT also supports physical addressing for configuration, identification, diagnostics, and other device-oriented operations. During initialization, the master discovers and configures the slaves according to their positions and device characteristics. Once the network enters cyclic operation, logical addressing can be used efficiently for process-data exchange. This separation allows EtherCAT to combine flexible network configuration with extremely efficient cyclic communication during normal machine operation.

The Working Counter is an important mechanism for verifying whether EtherCAT operations have been executed as expected. EtherCAT slaves increment or modify the counter according to successful processing of specific read, write, or read-write commands. The master compares the returned value with the expected Working Counter value. A mismatch can therefore reveal missing slaves, communication faults, incorrect states, or process-data transactions that were not successfully completed.

EtherCAT topology is another consequence of its frame-forwarding architecture. Although the communication logically behaves like a frame passing through sequential processing points, the physical network can support line, tree, star, and branched arrangements when appropriate EtherCAT hardware is used. EtherCAT ports embedded in slave controllers forward frames directly, reducing dependence on conventional Ethernet switches and enabling network structures that closely follow the physical layout of industrial machines.

When a frame reaches the end of an EtherCAT segment, the physical-layer processing within the slave infrastructure returns it through the network toward the master. Full-duplex Ethernet links make this forwarding structure possible without requiring ordinary store-and-forward switching behavior at every node. From the master\'s perspective, the entire distributed system can therefore be serviced through a highly structured cyclic exchange rather than through numerous independent request-response transactions.

Deterministic timing is especially important for motion control. Servo drives may require position, velocity, torque, and status information to be exchanged at precise intervals. EtherCAT minimizes communication uncertainty by moving much of the slave-side frame processing into dedicated hardware. The resulting short and predictable communication delays allow control systems to operate with cycle times suitable for coordinated multi-axis machines, robots, manipulators, and other high-performance automation equipment.

Distributed Clocks further improve synchronization among EtherCAT devices. Selected slaves contain local clocks that can be synchronized to a common reference with compensation for propagation delays through the network. This allows events at physically separated devices to occur at closely aligned times even though the Ethernet frame reaches each device at a slightly different instant. Synchronized sampling and actuation are therefore possible across distributed servo drives, sensors, and I/O modules.

The distinction between communication cycle timing and distributed device synchronization is important. Fast frame transmission alone does not guarantee that multiple actuators execute commands simultaneously. EtherCAT Distributed Clocks provide a common temporal reference so that slaves can schedule local operations relative to synchronized time. This capability is valuable in coordinated robot joints, electronic gearing, gantry systems, synchronized measurement equipment, and machines requiring precise relationships between motion axes.

EtherCAT slave devices generally contain an EtherCAT Slave Controller, or ESC, that performs real-time frame recognition, forwarding, address processing, memory mapping, and related protocol functions. The local application processor does not have to inspect every Ethernet bit in software. Instead, it exchanges process information with memory managed through the ESC. This hardware partitioning is one of the reasons EtherCAT can maintain predictable communication behavior across heterogeneous industrial devices.

The EtherCAT state machine controls how slaves progress from initialization toward operational communication. Typical states include INIT, PRE-OPERATIONAL, SAFE-OPERATIONAL, and OPERATIONAL. Configuration and mailbox communication become available progressively, while valid cyclic process-data operation is enabled only after required configuration and checks have been completed. This staged transition prevents an incompletely configured device from immediately participating in normal machine control.

Cyclic process communication and acyclic configuration communication serve different purposes within the same network. Time-critical process data such as actuator commands, encoder values, digital I/O, and drive status can be transferred cyclically with deterministic timing. Less time-critical parameters, diagnostics, configuration objects, and device-management information can use mailbox mechanisms. This separation prevents engineering and diagnostic traffic from unnecessarily defining the timing characteristics of the primary control loop.

EtherCAT therefore should not be understood merely as "faster Ethernet." Its performance results from the combination of master-controlled communication, on-the-fly hardware processing, efficient datagram packing, distributed logical addressing, predictable propagation, hardware slave controllers, working-counter verification, and precise clock synchronization. These mechanisms collectively transform standard Ethernet physical technology into a communication system optimized for deterministic distributed control.

In robotics, this operating principle is particularly suitable for the layer connecting a real-time controller to servo drives, joint actuators, encoders, force-torque sensors, and distributed I/O. A robot may contain many devices requiring updates within the same control period, and EtherCAT allows their process data to be transported through a coordinated cyclic frame structure rather than through numerous independent network conversations.

For an AMR or mobile manipulator, EtherCAT can therefore occupy a different architectural role from higher-level Ethernet communication. General Ethernet and TCP/IP may connect edge computers, perception computers, fleet systems, or supervisory applications, while EtherCAT can provide deterministic communication inside the machine-level control domain. The higher-level computer decides what behavior should occur, whereas the real-time control system and EtherCAT network execute synchronized actuator and I/O exchanges.

The essential EtherCAT operating sequence can ultimately be understood as a continuous cyclic pipeline. The master prepares process data, transmits an EtherCAT frame, each slave reads or modifies its assigned data while the frame passes, the frame returns to the master, communication validity is checked, and the next control cycle begins. Combined with synchronized clocks and hardware processing, this principle enables scalable, high-speed, and deterministic communication for modern industrial robotics and automation systems.

04.02. ESC and EtherCAT Slave

EtherCAT Slave Controller (ESC) is the hardware component that enables an EtherCAT slave device to participate in deterministic real-time communication. Within the EtherCAT architecture, the ESC sits between the physical Ethernet ports and the local application controller. It recognizes EtherCAT frames, processes relevant data while frames are passing through, manages process-data memory, and forwards frames with extremely small and predictable delay.

An EtherCAT slave is the complete network device connected to the EtherCAT master, whereas the ESC is the communication engine inside that slave. A slave may be a servo drive, remote I/O module, encoder, sensor, motor controller, or robotic actuator. In addition to the ESC, the device normally contains application electronics, firmware, interfaces, and functional circuitry required to perform its specific machine-level task.

The ESC implements the characteristic on-the-fly processing mechanism of EtherCAT. When a frame enters one Ethernet port, the ESC examines EtherCAT commands and addresses while the frame continues through the device. Relevant output data can be copied from the passing frame into local memory, while input data generated by the slave can be inserted into appropriate locations. This eliminates conventional software-based receive-process-retransmit operations at every network node.

Most EtherCAT slaves provide at least two communication ports so that frames can enter through one port and continue toward another device through the second. More complex ESC implementations may provide additional ports for branches or alternative physical topologies. Because forwarding is handled directly by dedicated hardware, EtherCAT networks can form line, tree, star-like, and branched structures without requiring conventional Ethernet switches between every group of slave devices.

The ESC contains internal memory resources that form the communication boundary between the EtherCAT network and the slave application. Process data received from the master is made available through this memory, while information generated by the local application is written into memory locations that the ESC can place into outgoing EtherCAT datagrams. The application processor therefore interacts primarily with structured local data rather than directly processing Ethernet frames.

A major ESC function is provided by Fieldbus Memory Management Units (FMMUs). An FMMU maps portions of the EtherCAT master\'s logical process address space to physical memory locations inside a slave. Through this mechanism, distributed devices can appear to the master as parts of one continuous logical memory space. The master can consequently exchange data with several slaves using a single datagram instead of performing separate transactions with every physical device.

SyncManagers provide another important memory-management function inside an EtherCAT slave. They coordinate access to shared memory areas between the EtherCAT communication side and the local application side. Depending on their configuration, SyncManagers can support cyclic process data or mailbox communication. Their control mechanisms help prevent inconsistent access conditions and provide structured transfer of data between the network and application domains.

Process Data Objects (PDOs) represent cyclic information exchanged during normal real-time operation. Examples include commanded motor torque, target velocity, actual joint position, encoder measurements, digital inputs, and device status. PDO data is typically mapped through ESC memory structures so that the EtherCAT master can exchange time-critical information efficiently. The ESC handles the network transfer while the application controller consumes or produces the corresponding local variables.

Mailbox communication supports information that does not normally require transmission during every real-time control cycle. Device parameters, configuration information, diagnostics, and higher-level protocol objects can be transferred through mailbox channels. This allows cyclic process traffic to remain optimized for deterministic control while less time-critical communication is handled independently. CAN over EtherCAT (CoE), for example, can use this mailbox infrastructure for object-oriented device configuration.

The ESC also participates in EtherCAT Working Counter processing. When a slave successfully performs an addressed operation, the appropriate Working Counter behavior is applied according to the command type. After the frame returns, the master compares the received Working Counter with the expected value. This provides an efficient network-level indication that the intended slaves actually processed the transaction rather than merely confirming that an Ethernet frame physically returned.

EtherCAT slaves operate according to the EtherCAT State Machine. After power-up, a slave normally begins in INIT and can progress through PRE-OPERATIONAL, SAFE-OPERATIONAL, and OPERATIONAL states. Different communication capabilities become available as the device advances through these states. The ESC maintains state-related communication functions, while the application and master coordinate configuration and validation before unrestricted cyclic process operation is permitted.

In INIT, communication resources are placed into an initial condition and normal process-data exchange is not yet active. PRE-OPERATIONAL permits configuration-oriented communication such as mailbox exchanges, allowing the master to configure device parameters. SAFE-OPERATIONAL enables valid input processing while outputs remain constrained by device behavior. OPERATIONAL represents normal cyclic operation in which configured input and output process data can participate fully in real-time machine control.

Distributed Clocks may be integrated into the ESC to provide precise time synchronization across multiple slaves. Each participating device maintains a local clock that can be synchronized with a reference clock in the EtherCAT network. The master determines timing relationships and compensates for propagation differences. As a result, physically distributed devices can perform sampling or actuation at coordinated instants rather than simply reacting whenever a frame happens to arrive.

This distinction is particularly important for servo systems. A frame necessarily reaches different slaves at slightly different physical times because signals propagate through cables and devices. Without synchronized clocks, these differences can become timing errors between axes. With Distributed Clocks, each servo slave can execute a command according to a common synchronized time base, supporting coordinated position control, electronic gearing, synchronized sensing, and precise multi-axis robotic motion.

The local application controller may be implemented using a microcontroller, DSP, FPGA, motor-control processor, or another embedded computing device. Its responsibility differs from that of the ESC. The ESC handles deterministic EtherCAT communication, frame processing, memory mapping, synchronization, and protocol-level functions, while the application controller performs device-specific tasks such as motor regulation, sensor processing, actuator diagnostics, or local control algorithms.

Communication between the ESC and application controller can use interfaces appropriate to the device architecture. Depending on the implementation, the application may access ESC resources through parallel memory interfaces, serial interfaces, or integrated internal buses. Some semiconductor solutions combine EtherCAT communication and application-processing capabilities within a single device. Regardless of implementation, the architectural objective remains separation between deterministic network processing and application-specific computation.

Slave configuration also requires a description of how the device behaves within the EtherCAT system. Configuration information identifies communication capabilities, process-data mappings, synchronization options, mailbox support, and device-specific parameters. The master uses this information when constructing the operational network configuration. Correct configuration is especially important because deterministic communication depends not only on frame speed but also on consistent mapping of data between the master and every slave.

Error detection and diagnostics are therefore essential parts of slave operation. The ESC can expose communication status, link conditions, state information, counters, and protocol-related error indicators. The application controller can combine these network diagnostics with device-specific information such as overtemperature, encoder failure, motor faults, or supply-voltage problems. Together, these mechanisms allow the master to distinguish communication problems from failures originating within the controlled device.

In robotics, the ESC-slave architecture creates a useful separation between network timing and local control timing. A robot joint module may receive target position, velocity, or torque through EtherCAT while its local processor executes a much faster motor-control loop. Encoder values and joint status are returned through process data. EtherCAT therefore coordinates distributed modules without requiring the central controller to perform every low-level electrical control operation directly.

For a mobile manipulator, multiple servo drives, grippers, force-torque sensors, safety-related devices, and distributed I/O modules can each operate as EtherCAT slaves. The master sees their process data through a coordinated logical representation, while individual ESCs perform deterministic communication locally. This allows a complex robotic machine to behave as a synchronized distributed control system rather than as a collection of independent Ethernet devices communicating through unrelated request-response exchanges.

The essential role of the ESC can therefore be summarized as a hardware bridge between the traveling EtherCAT frame and the local intelligence of each slave device. Physical ports receive and forward frames, ESC logic performs on-the-fly processing, FMMUs map logical addresses, SyncManagers coordinate memory access, Distributed Clocks synchronize time, and the application interface connects network data to device-specific control. Together, these functions form the foundation of an EtherCAT slave.

04.03. CoE (CAN over EtherCAT)

CAN over EtherCAT (CoE) is an EtherCAT application protocol that allows communication concepts and device profiles originating from CANopen to operate over an EtherCAT network. Within the chapter structure, CoE follows the EtherCAT operating principle and EtherCAT Slave Controller topics, establishing the connection between EtherCAT communication mechanisms and CANopen-style device configuration.

The name CAN over EtherCAT can initially suggest that complete CAN frames are simply transported through Ethernet, but CoE is more accurately understood as the reuse of important CANopen application-layer mechanisms over EtherCAT. EtherCAT provides the physical communication, frame processing, synchronization, and high-speed process-data transport, while CoE provides familiar CANopen concepts such as the Object Dictionary, Service Data Objects, and device profiles.

This separation is important because CANopen and EtherCAT solve different parts of the communication problem. CANopen defines standardized ways to represent parameters, communication objects, and device behavior, while EtherCAT provides a high-performance deterministic network. CoE combines these advantages, allowing engineers to retain structured CANopen device models while obtaining the bandwidth, synchronization capability, and short cycle times associated with EtherCAT.

At the center of CoE is the Object Dictionary, which provides a structured representation of device parameters and communication information. Individual objects are identified by an index and, where necessary, a sub-index. Parameters such as device identity, operating modes, control values, status information, limits, configuration settings, and communication mappings can therefore be accessed through a standardized addressing model rather than through arbitrary device-specific memory locations.

The Object Dictionary forms an important interface between the EtherCAT master and the application implemented inside a slave. The local application may internally use registers, variables, control structures, or hardware-specific representations, but externally relevant parameters can be exposed as standardized objects. This abstraction makes configuration and diagnostics easier because engineering software can interact with devices through defined objects without requiring direct knowledge of their internal firmware architecture.

Service Data Objects (SDOs) are used primarily for parameter-oriented access to the Object Dictionary. Through SDO communication, the EtherCAT master can read or write individual objects in a slave. Typical uses include configuring motor limits, selecting operating modes, reading identification information, adjusting controller parameters, retrieving diagnostic values, or establishing process-data mappings before the device enters normal cyclic operation.

In CoE, SDO communication is normally carried through the EtherCAT mailbox mechanism. Mailbox communication is intended for information that does not need to be exchanged during every real-time control cycle. This means configuration and diagnostic operations can coexist with deterministic cyclic traffic without forcing all parameter communication into the time-critical process-data path. The EtherCAT Slave Controller and application cooperate to transfer mailbox information to the appropriate local protocol processing.

Process Data Objects (PDOs) serve a different purpose from SDOs. PDOs represent data that must be exchanged repeatedly during normal machine operation, such as target position, target velocity, commanded torque, actual position, actual velocity, status words, digital I/O, or sensor measurements. Rather than performing an individual object transaction for every value, selected Object Dictionary entries can be mapped into compact process-data structures for efficient cyclic exchange.

This distinction between SDO and PDO communication is fundamental to CoE. SDOs provide flexible object-oriented access for configuration, commissioning, and diagnostics, while PDOs provide efficient deterministic transfer for operational control. A servo drive, for example, might use SDO communication during startup to configure limits and operating parameters, then exchange target commands and feedback continuously through PDOs once the system enters normal operation.

PDO mapping determines which application objects participate in cyclic process communication and how they are arranged. The master can use configuration information to establish the relationship between Object Dictionary entries and EtherCAT process data. Once configured, the EtherCAT Slave Controller can transfer process data through its memory structures while the application accesses the corresponding local variables, avoiding expensive object-by-object transactions during every control cycle.

CoE is especially significant for motion-control systems because CANopen device profiles can provide standardized semantics for servo drives and related devices. A master does not need to treat every drive as an entirely unrelated proprietary interface. Standardized control words, status words, operating modes, target values, and feedback concepts can provide a common device-control model, while manufacturer-specific objects remain available when specialized functionality is required.

CANopen over EtherCAT also benefits from EtherCAT\'s state and synchronization mechanisms. Configuration-oriented CoE exchanges can occur during appropriate initialization stages, while cyclic process communication becomes active as the EtherCAT slave progresses toward operational states. Distributed Clocks can then synchronize multiple servo devices so that PDO commands and feedback are associated with precisely coordinated control timing across physically distributed axes.

The relationship between CoE and the EtherCAT Slave Controller is therefore layered. The ESC handles EtherCAT frames, logical addressing, FMMU mapping, SyncManager operation, mailbox transport, process-data memory, Working Counter behavior, and potentially Distributed Clocks. CoE operates above these mechanisms to define how application objects, parameters, and CANopen-compatible device behavior are represented and accessed by the master.

SyncManagers are particularly relevant because they organize communication between EtherCAT network memory and the local application. Some SyncManager channels can support mailbox transfers used by CoE SDO communication, while others support cyclic process-data areas containing mapped PDO information. This hardware-supported separation helps maintain predictable process communication even when configuration or diagnostic transactions are occurring elsewhere in the slave communication architecture.

From the application-controller perspective, CoE provides a structured bridge between network communication and device functionality. A motor-control processor may internally execute current, velocity, and position loops at frequencies much higher than the EtherCAT network cycle. CoE objects expose selected parameters and operating states to the network, while PDO mappings carry the real-time command and feedback variables required by the supervisory motion controller.

A practical startup sequence illustrates how these mechanisms cooperate. After discovering the EtherCAT slave, the master can establish mailbox communication and access CoE objects to identify the device and configure required parameters. It can then establish PDO mappings and synchronization behavior. After configuration and validation are complete, the slave transitions toward operational communication, where mapped process data is exchanged cyclically with deterministic timing.

Diagnostics can also be organized through the Object Dictionary. Device-specific error information, communication status, operating conditions, and internal diagnostic values can be exposed as objects accessible through CoE. This allows commissioning software or the EtherCAT master to investigate a device without requiring a separate diagnostic network. Real-time fault indicators may simultaneously be mapped into PDOs when immediate reaction is required during machine operation.

For robotics, CoE is particularly useful when multiple intelligent actuator modules must share a consistent control interface. Servo drives for robot joints can expose standardized configuration parameters while exchanging target position, velocity, torque, actual position, and status through mapped process data. EtherCAT supplies deterministic high-speed transport, while CoE supplies a structured application-level representation of what those transmitted values actually mean.

In a mobile manipulator, for example, the EtherCAT master may coordinate arm joints, grippers, lift mechanisms, steering actuators, and distributed I/O. CoE allows these devices to expose parameters through compatible Object Dictionary structures while EtherCAT transports their operational data efficiently. The system therefore separates device configuration and semantic representation from the underlying high-speed mechanism used to move data across the machine.

CoE should consequently be viewed as an integration of two complementary architectural ideas rather than as a replacement for either CANopen or EtherCAT. CANopen contributes mature object-oriented device modeling and standardized application concepts, while EtherCAT contributes high-performance deterministic Ethernet communication. Their combination allows sophisticated industrial devices to retain structured configuration interfaces while participating in synchronized, high-speed distributed control.

The essential CoE architecture can therefore be understood as a layered path from the EtherCAT master through EtherCAT communication services to the slave Object Dictionary and ultimately to the device application. Mailbox-based SDO communication provides parameter access, mapped PDOs provide cyclic real-time data, and the ESC supplies the deterministic transport infrastructure underneath them. Together, these mechanisms make CoE an important bridge between standardized device semantics and high-performance EtherCAT control.

04.04. FSoE Functional Safety

Functional Safety over EtherCAT (FSoE) is a safety communication protocol designed to transmit safety-related information through EtherCAT networks while preserving the deterministic communication advantages of the underlying industrial Ethernet system. Within the EtherCAT chapter structure, FSoE follows the operating principle, EtherCAT Slave Controller, and CAN over EtherCAT topics, extending the communication architecture toward functional safety.

The fundamental purpose of FSoE is to allow safety functions to use the same communication infrastructure as standard machine-control data without assuming that the ordinary communication channel itself is inherently safe. Safety commands and safety status information are protected by additional protocol mechanisms so that communication faults can be detected independently of the behavior of the underlying EtherCAT transport network.

This approach is commonly associated with the black-channel principle. The communication network between safety endpoints is treated as a channel whose internal behavior does not have to provide the complete safety integrity of the safety function. EtherCAT frames, slave controllers, cables, connectors, and intermediate communication mechanisms transport the information, while FSoE safety mechanisms at the endpoints provide the additional protection required for safety-related communication.

An FSoE system normally contains safety communication participants such as a safety controller and one or more safety devices. The safety controller may be implemented as a safety PLC or another certified safety-capable controller, while safety devices may include emergency-stop modules, safety I/O, safety drives, safety encoders, light curtains, laser scanners, or robotic safety modules. These participants exchange safety data through protected FSoE communication relationships.

FSoE safety information is encapsulated within the process-data communication transported by EtherCAT. From the EtherCAT network perspective, the protected safety information can therefore travel through the same communication system used for ordinary process data. This avoids the need for a completely separate physical safety network while maintaining a logical distinction between standard control communication and safety-related communication.

The safety connection is established between defined FSoE communication endpoints. Each connection must ensure that received information belongs to the intended safety relationship rather than another device or communication path. Connection identification and protocol state information help prevent incorrect data from being accepted when devices are exchanged, communication paths change, or unexpected network behavior occurs.

Sequence monitoring is an important protection mechanism because safety communication must detect repeated, lost, inserted, or incorrectly ordered messages. Consecutive safety telegrams contain information that allows the receiver to determine whether communication is progressing according to the expected sequence. If the expected progression is violated, the receiving safety function can detect the abnormal condition and transition toward an appropriate safe reaction.

Data integrity is additionally protected through safety-specific error-detection mechanisms such as cyclic redundancy checking. The receiver verifies the protected information before accepting it as valid safety data. Corruption caused by transmission errors, memory faults, unintended modifications, or communication disturbances can therefore be detected with a defined level of diagnostic effectiveness rather than relying only on the normal Ethernet frame-checking mechanisms.

Timing supervision is also essential because safety data that arrives too late may be as dangerous as corrupted data. FSoE communication therefore operates with monitored timing relationships so that missing or excessively delayed safety messages can be recognized. If valid communication is not received within the expected interval, the safety system can interpret the condition as a communication failure and initiate a predefined safe-state response.

These protection mechanisms are designed to address communication fault classes that are important in functional safety. Possible faults include corruption, repetition, loss, insertion, incorrect sequence, unacceptable delay, and communication with an unintended participant. FSoE adds safety-related measures so that these conditions can be detected with sufficient reliability for the safety architecture in which the protocol is applied.

A safe state is defined according to the machine and the associated hazard analysis rather than by EtherCAT alone. For one machine, the appropriate response may be removal of drive torque; for another, it may involve controlled deceleration, restricted motion, brake activation, or disabling a hazardous actuator. FSoE transports the safety information required to coordinate these responses, while the safety application determines the actual safe behavior.

This distinction means that FSoE does not by itself make an entire robot or machine functionally safe. Functional safety depends on the complete safety function, including hazard identification, sensors, logic, communication, actuators, diagnostics, architecture, validation, and the required integrity level. FSoE addresses the safety communication portion of this chain and must therefore be integrated with appropriately designed safety controllers and safety-capable field devices.

The separation between standard control and safety control is particularly important in servo systems. Ordinary EtherCAT process data may command target position, velocity, or torque, while safety-related communication can request or supervise safety functions implemented by the drive. The normal motion controller continues to optimize machine performance, whereas the safety controller independently determines whether operation remains within the conditions permitted by the safety concept.

Safety-capable drives can implement functions that modify motion behavior without necessarily removing all power immediately. Depending on the drive and safety architecture, functions may stop torque generation, supervise speed, restrict motion, or support controlled stopping behavior. FSoE provides a network mechanism through which safety controllers and safety-capable drives can coordinate such functions across a distributed machine architecture.

One major advantage of this architecture is reduced wiring complexity. Traditional safety systems frequently rely on dedicated hardwired circuits for emergency stops, safety relays, guard switches, and actuator shutdown signals. Networked functional safety can consolidate many of these distributed signals into safety communication while retaining the required diagnostic mechanisms. Physical safety design remains necessary, but communication can become more scalable for complex machines.

Diagnostics can also become more informative than with simple binary safety wiring. A safety controller can distinguish communication faults, device states, safety requests, and other diagnostic conditions represented by safety-capable devices. This improves commissioning and troubleshooting because engineers can identify which part of a distributed safety function triggered a reaction rather than observing only that a generic safety circuit has opened.

FSoE operates alongside ordinary EtherCAT communication rather than replacing it. Standard EtherCAT mechanisms continue to transport high-speed cyclic process data for sensors, actuators, and servo drives, while protected safety information is carried within the same overall communication infrastructure. CoE may simultaneously provide configuration and device-profile mechanisms, demonstrating how several application-level functions can coexist over a common EtherCAT network.

The EtherCAT Slave Controller remains responsible for transporting frames, managing process-data areas, forwarding communication, and supporting deterministic network behavior. Safety interpretation is performed by appropriately designed safety-capable components above or alongside the ordinary communication mechanism. This architectural separation supports the black-channel concept because standard communication components are not required to interpret the semantic meaning of every safety command.

In robotics, FSoE becomes particularly relevant when several distributed actuators and safety sensors must participate in coordinated machine protection. Emergency-stop devices, safety scanners, joint drives, safety I/O, and a safety controller can exchange protected information across the robot network. The safety system can therefore supervise hazardous motion while the ordinary EtherCAT control network continues to support precise real-time operation.

A mobile manipulator illustrates the relationship clearly. Standard EtherCAT communication can coordinate arm joints, steering actuators, grippers, and distributed I/O, while FSoE carries safety-related information associated with emergency stopping, protected zones, drive safety functions, or other machine-specific safety conditions. The robot can therefore combine high-performance motion communication with a logically independent safety communication layer over the same network infrastructure.

The resulting architecture can be understood as two communication domains sharing one transport environment. The standard control domain focuses on performance, synchronization, and deterministic process-data exchange, while the safety domain focuses on detecting communication failures and ensuring that invalid or missing safety information cannot silently produce hazardous behavior. Their coexistence allows sophisticated industrial machines to achieve both high control performance and structured safety supervision.

FSoE should therefore be viewed as a safety communication layer within the broader functional-safety architecture rather than merely as another EtherCAT data format. Protected safety connections, identification, sequence monitoring, integrity checking, timing supervision, fault detection, and safe-state reactions work together so that safety information can traverse an ordinary EtherCAT infrastructure while remaining suitable for safety-related distributed control.

04.05. EtherCAT Servo Network Design

EtherCAT servo network design applies the deterministic communication principles of EtherCAT to distributed motion-control systems containing multiple servo drives, motors, encoders, sensors, and I/O devices. Within the industrial communication structure, this topic completes the EtherCAT chapter after the operating principle, EtherCAT Slave Controller, CoE, and FSoE, bringing those mechanisms together into a practical servo-network architecture.

A typical EtherCAT servo network consists of a real-time motion controller operating as the EtherCAT master and multiple servo drives operating as EtherCAT slaves. The master calculates motion commands and coordinates the overall machine, while each servo drive performs local motor-control functions. Position, velocity, torque, status, and feedback information are exchanged cyclically between the controller and drives through deterministic EtherCAT process communication.

The network architecture should separate centralized motion coordination from high-frequency local motor regulation. The EtherCAT master may generate trajectory references and synchronized commands at the machine-control cycle rate, while each servo drive executes current, torque, velocity, or position regulation internally at a significantly higher frequency. EtherCAT therefore coordinates distributed control loops without requiring every low-level motor-control calculation to run in the central controller.

Process Data Objects (PDOs) provide the primary mechanism for cyclic servo communication when CAN over EtherCAT (CoE) is used. Target position, target velocity, target torque, control words, actual position, actual velocity, actual torque, and status words can be mapped into process data. Efficient PDO mapping is important because only information required during real-time operation should occupy the cyclic communication image.

Service Data Objects (SDOs) serve the configuration and commissioning side of the servo network. Parameters such as motor characteristics, acceleration limits, current limits, operating modes, control gains, diagnostic information, and device-specific settings can be accessed through the CoE Object Dictionary. Once configuration is completed, time-critical motion information is transferred through PDOs rather than repeatedly using parameter-oriented SDO transactions.

Servo-network timing must be designed around the required control cycle rather than simply selecting the highest possible communication speed. The designer must consider the number of axes, process-data size, controller computation time, frame propagation, slave processing, synchronization requirements, and application dynamics. The resulting EtherCAT cycle should provide sufficient margin so that communication and control calculations complete predictably before the next cycle begins.

Distributed Clocks are fundamental when several servo axes must move in precise coordination. Although an EtherCAT frame reaches slaves sequentially, synchronized local clocks allow each drive to perform sampling or command execution according to a common time reference. Propagation-delay compensation reduces timing differences between physically separated slaves, enabling synchronized multi-axis control even when the drives occupy different positions in the network.

This synchronization is particularly important for coordinated trajectories. In a robot arm, for example, each joint contributes to the end-effector position, so small timing differences between axes can become trajectory errors. Distributed Clocks allow position measurements and command updates to be associated with coordinated instants, improving the temporal consistency required for interpolation, electronic gearing, gantry control, and high-performance robotic motion.

The EtherCAT master is responsible for constructing the cyclic process image and scheduling communication with the servo slaves. During each cycle, it sends commands to the drives and receives feedback representing their current states. The motion-control application uses this feedback to calculate subsequent commands. The network therefore forms a repeated sense-compute-command sequence whose timing must remain sufficiently deterministic for the selected servo-control architecture.

Each servo slave contains an EtherCAT Slave Controller (ESC) that handles frame processing independently of the motor-control processor. The ESC performs on-the-fly communication, logical-address mapping, SyncManager operation, Working Counter processing, and potentially Distributed Clock synchronization. The servo application accesses process data through local memory interfaces while dedicated motor-control hardware executes the electrical control loops required by the motor.

The separation between ESC communication and servo application processing improves determinism because Ethernet frame handling does not depend on unpredictable software execution inside each drive. The ESC transfers network information into defined memory areas, and the local processor consumes the corresponding command values. Feedback generated by the servo application is written back into process memory so that it can be inserted into EtherCAT communication efficiently.

Network topology should reflect both machine layout and communication requirements. EtherCAT can support line, tree, star-like, and branched structures using appropriate slave ports and junction devices. A line topology is often convenient for servo axes arranged sequentially along a machine, while branches can simplify cabling for robot modules or distributed mechanisms. Topology planning should also consider service access, cable routing, replacement, and future expansion.

Physical network engineering remains important even though EtherCAT provides deterministic protocol behavior. Industrial Ethernet cabling, connectors, shielding, grounding, electromagnetic compatibility, bending requirements, and routing near motor-power cables can affect communication reliability. Servo drives and motors are significant electromagnetic-noise sources, so communication cables should be integrated into the machine\'s grounding and EMC architecture rather than treated as independent low-risk wiring.

Fault detection should be incorporated into the network design from the beginning. Working Counter mismatches, link failures, slave-state changes, synchronization faults, and drive diagnostics provide different indications of system health. The master should distinguish between a communication failure and an application-level servo fault such as overcurrent, encoder failure, overtemperature, following error, or motor-control protection event, because the appropriate system response may differ.

The EtherCAT State Machine also influences servo startup. Slaves progress through INIT, PRE-OPERATIONAL, SAFE-OPERATIONAL, and OPERATIONAL states as communication resources, parameters, process mappings, and operational conditions are established. A motion system should not enable unrestricted actuator operation merely because Ethernet communication exists; configuration, synchronization, drive readiness, and machine-level conditions should be validated before normal motion begins.

Functional safety can be integrated through Functional Safety over EtherCAT (FSoE) when the servo network requires safety-related communication. Standard EtherCAT process data continues to carry performance-oriented motion commands and feedback, while FSoE can carry protected safety information between a safety controller and safety-capable drives or sensors. This creates a logical separation between normal motion control and independent safety supervision over shared network infrastructure.

The resulting drive architecture may therefore contain several control layers. A central motion controller coordinates trajectories, EtherCAT provides deterministic cyclic communication, the servo drive performs local closed-loop regulation, and a safety controller supervises safety-related conditions. These layers operate at different frequencies and with different responsibilities, preventing high-level trajectory planning, network synchronization, electrical motor regulation, and functional safety from becoming one monolithic control function.

For a multi-axis industrial robot, the EtherCAT master may communicate with servo drives for the base, shoulder, elbow, wrist, and end-effector mechanisms through one synchronized process-data image. Each drive receives its commanded variables and returns encoder and status information. Distributed Clocks align axis timing, while CoE provides standardized parameter access and FSoE can provide protected safety communication where required.

A mobile manipulator introduces additional integration considerations because the manipulator and mobile platform may contain different control domains. EtherCAT can be used inside the deterministic actuator domain for arm joints, steering modules, lift mechanisms, grippers, and distributed I/O, while higher-level Ethernet communication can connect the real-time controller to perception computers, edge AI computers, supervisory software, or fleet-management systems.

This distinction is useful in Physical AI and advanced robotics architectures. AI or planning computers may operate at comparatively slower and less deterministic decision frequencies, whereas servo control requires predictable command execution and feedback acquisition. The higher-level computer can determine desired robot behavior, trajectories, or task objectives, while the EtherCAT servo network provides the deterministic machine-level communication needed to execute those decisions through physical actuators.

Scalability should be considered when determining process-data structures and network organization. Adding more axes increases communication payload, controller computation, diagnostic requirements, power distribution, and synchronization complexity. A well-designed EtherCAT servo architecture therefore defines reusable drive interfaces, consistent PDO mappings, standardized state handling, diagnostic conventions, and modular topology rules so that additional actuators can be integrated without redesigning the complete control system.

Ultimately, EtherCAT servo network design is the coordinated engineering of communication timing, servo-control partitioning, process-data mapping, synchronization, topology, physical networking, diagnostics, and safety. EtherCAT supplies deterministic transport, ESCs provide hardware-level frame processing, CoE structures servo parameters and process objects, Distributed Clocks synchronize axes, and FSoE can protect safety communication. Together, these mechanisms create a scalable real-time communication backbone for synchronized robotic and industrial motion systems.