Introduction to EtherCAT Technology and the EtherCAT Protocol

1 What is EtherCAT?

EtherCAT® (Ethernet for Control Automation Technology) is a high-performance Ethernet Fieldbus technology that provides a reliable, efficient, and cost-effective communication solution for a wide variety of industrial automation applications. Originally developed as an open technology by Beckhoff Automation in 2003, and subsequently turned over to an independent organization known as the EtherCAT Technology Group, EtherCAT has since become one of the most widely used industrial Ethernet protocols in the world with over 6,000 member organizations.

EtherCAT is based on the IEEE 802.3 Ethernet standard and uses a master/slave architecture to enable communication between devices on the same network. The master device acts as a controller, sending commands to slave devices and receiving data back from them. In addition to master-to-slave communication, EtherCAT also supports master-to-master and slave-to-slave communication. EtherCAT supports many different types of devices such as sensors, distributed I/O, actuators, motors, and other controllers.

EtherCAT is also a very cost-effective option. Since EtherCAT is an open and standardized technology, the market is rich with readily available and competitively priced off-the-shelf EtherCAT hardware products and software solutions from thousands of different manufacturers. Compared to other Fieldbus technologies that have notoriously long lead times and limited, high-cost hardware options, EtherCAT has emerged as a popular cost-effective choice. Furthermore, EtherCAT can reduce costs from a maintenance and downtime perspective thanks to its reliability and hardware replacement options.

One of the main advantages of EtherCAT is its high-speed and low-latency communication. EtherCAT’s unique method of frame processing and data transfer allows for extremely high bandwidth utilization that cannot be matched by other Fieldbus technologies. The topology design makes cycle times deterministic and allows EtherCAT to be suitable for hard real-time requirements. Additionally, EtherCAT supports Distributed Clocks (DC) which allow for very precise nanosecond-level synchronization throughout the network.

EtherCAT’s flexibility, exceptional performance, and reliability make it a clear choice for high-speed and safety-critical applications such as medical robotics, testing and measurement, machine tools, and factory automation.


2 The EtherCAT Protocol Fundamentals

2.1 Frame Structure

As with standard Ethernet communication, EtherCAT utilizes Ethernet frames to transmit data throughout the network. EtherCAT frames are based on the IEEE 802.3 Ethernet standard; however, they are structured in a special way that optimizes them for increased bandwidth and short cyclic process data. EtherCAT frames also eliminate bulkier protocol stacks such as UDP/IP or TCP/IP, meaning that EtherCAT is not an IP-based protocol, more similar to a Layer 2 or Data Link Layer protocol.

The EtherCAT frame, or telegram, consists of an Ethernet header, followed by the EtherCAT data, and is ended by a frame check sequence (FCS). The EtherCAT protocol is identified by using the 0x88A4 identifier in the EtherType field within the Ethernet header. Wireshark contains a dissector to graphically analyze EtherCAT frames.

The EtherCAT data contains an EtherCAT-specific header followed by the EtherCAT Datagrams. The EtherCAT header specifies the total length and type of the subsequent EtherCAT datagrams. Following the EtherCAT header is the EtherCAT datagram, which contains the actual data that is going to be read or written in the network. This data includes address specifications, the command type (i.e. read, write, or read-write) that the master would like to execute, and the cyclic process data (PDOs). A single EtherCAT frame may contain up to 1,498 bytes.

If more than 1,498 bytes are required, the master will send out multiple frames of data, and each frame will contain identifiers signaling whether devices on the network should expect another frame behind the current one.

The EtherCAT Master is responsible for assembling the EtherCAT frames and sending them through the network. Every frame sent out by the master will pass through each node in the network (logical ring). Additionally, thanks to flexible topology options, there is no need for network switches or routers, further reducing timing delays and hardware costs.

2.2 Functional Principle

Along with the frame structure, EtherCAT further differentiates itself with its unique method of exchanging data on the network. Many other Ethernet-based protocols require a separate frame to be sent to each node on the network—and require a response from every node in the network—in each cycle resulting in high network traffic and longer cycle times. Additionally, since each frame only contains data for one node, bandwidth utilization is usually very low and inefficient.

EtherCAT utilizes “on the fly” processing, which allows just one frame to be sent to all nodes. The EtherCAT master controller assembles the frames and sends them out. In each cycle, the frame travels around the network, passing through each node before returning to the master. The frames contain information for the slave nodes including addressing, EtherCAT command type (read, write, or read-write), and the actual process data. As each frame travels around the network, each device will look for and extract the data that is addressed to it and insert new data back into the frame all while it travels downstream. When the frame reaches the last node in the network, the frame is sent back to the master device using the full duplex capability of Ethernet.

EtherCAT’s on-the-fly processing provides many performance and cost-saving benefits. For example, although multiple frames can be used in the case of very large networks, a single frame is typically sufficient to send and receive data to and from all nodes. Furthermore, the EtherCAT master device is the only one allowed to send new frames. All other devices on the network simply receive the frame, process the frame, and forward it on. This eliminates unexpected delays and makes EtherCAT suitable for real-time applications.

2.3 Topology

EtherCAT technology offers flexible network topology options, making it a great choice for large and complex networks. EtherCAT networks contain a master device that is controlling the network and subsequent slave devices. The slave devices typically have two or more ports that allow them to be connected together.  Network topology possibilities include line, tree, star—or any combination thereof. Since EtherCAT operates in full duplex mode—taking advantage of the line pair in bidirectional Ethernet cables—any topology can maintain a logical ring structure, meaning the frame will always be able to get back to the master device once it is sent out. This flexibility also eliminates the need for network switches.

EtherCAT also supports advanced topology features such as Hot Connect and Hot Swap, meaning devices can be changed, added, or removed from the network all while remaining in the operational state. EtherCAT also supports several redundancy options including cable redundancy and master redundancy, adding extra protection against line breaks and device failures, further reducing downtime and maintenance costs.

2.4 Process Data

In each cycle, the EtherCAT master assembles data into the frame and sends it out to the nodes in the network. The nodes read the data addressed to them and write new return data into the frame as it travels downstream. Once the frame reaches the end of the network and returns to the master, the master will read the new data, and build the next frame. This data exchanged between the master and slaves is known as cyclic process data.

The slave devices—using their Fieldbus Memory Management Units (FMMU)—are responsible for reading and writing their data to the correct location in the frame. This is known as data mapping and is essential to ensure that the EtherCAT master device receives a completely sorted process image each cycle. The cyclic process data can be assembled according to project needs by activating optional process data objects. Organizing the process data this way enables EtherCAT’s fast and reliable performance.

Different slave device types may have different hardware and process data layout options. For example, simple devices, such as digital I/O, have fixed hardware and fixed process data layouts. Complex devices, such as drives, have fixed hardware and variable process data layout. Furthermore, modular devices, such as bus couplers or gateways, have variable hardware and variable process data layout.

2.5 Communication Profiles and Mailbox Protocols

In addition to cyclic process data, EtherCAT also supports acyclic communication including various mailbox protocols. These EtherCAT communication profiles were established to provide support for a wider variety of field devices and application layers. According to the EtherCAT specification, slave devices are not required to support all communication profiles; instead, they may support whichever profile or profiles are most suitable and relevant for their use case. Furthermore, in contrast to cyclic process data, mailbox protocol data transfers are not guaranteed to be delivered in any real-time constraint.

2.5.1 CAN Application Protocol over EtherCAT (CoE)

CANopen® is a popular communication protocol for embedded systems often used in automation applications. The EtherCAT communication profile known as CoE allows the implementation of the CAN Application Protocol over an EtherCAT network. This includes support for the CANopen object dictionary, mapping of Process Data Objects (PDOs), CoE Emergency error messages, diagnostics, and Service Data Objects (SDOs). Furthermore, many standardized CANopen profiles, such as the CiA 402 profile for drives and the CiA 406 profile for encoders, can be reused for EtherCAT communication. CoE is often utilized when project-specific parameters are sent to the slave device upon startup according to the network configuration. Slave device parameters can also be inspected and modified while the network is in the operational state via CoE.

2.5.2 Ethernet over EtherCAT (EoE)

Another powerful communication profile is Ethernet over EtherCAT. With EoE, Ethernet data traffic can be transmitted within an EtherCAT network. Switchport devices can be used in the EtherCAT segment to connect to Ethernet devices such as computers and routers. The switchport device is responsible for inserting the TCP/IP fragments into the EtherCAT traffic. EoE is commonly used to access a slave device’s web server for device configuration and diagnostics. In this way, the devices appear as if they are connected directly to a non-EtherCAT local network.

2.5.3 File Access over EtherCAT (FoE)

File Access over EtherCAT, or FoE, is another popular mailbox protocol used in EtherCAT communication. FoE is typically used to update firmware to devices in an EtherCAT network.

2.6 Synchronization (Sync Managers and Distributed Clocks)

Synchronization in EtherCAT communication makes real-time performance possible and enables precise and coordinated processes which are common in complex and critical applications. Synchronization guarantees that all nodes in the EtherCAT network are working with the same time base. For example, in high-speed motion control applications, it is critical to have all motor drives receiving and sending commands at the exact same time to ensure that the movements are executed quickly and accurately.

The most precise EtherCAT synchronization mechanism is based on Distributed Clocks (DC), and the calibration of the clocks across nodes in the network is based on hardware. EtherCAT utilizes a reference clock, typically from the first DC slave in the network. The time from this reference clock is distributed throughout all nodes in the network, and the resulting jitter is less than one microsecond. To compensate for the various clock drifts due to speed differences of each clock in the network, the devices regularly adjust themselves according to the reference clock. With all nodes operating on the same reference clock, the process data and output signals can be applied simultaneously across the network using a periodic trigger which is managed by the precise local clock.


3 EtherCAT Implementation

3.1 System Architecture

The system architecture of an EtherCAT implementation can be broken down into three main components: configuration files, the EtherCAT master, and the EtherCAT slave devices.  EtherCAT configuration files are used by the master to configure and initialize an EtherCAT network. The configuration files contain detailed information about the slave configuration and network topology. The master device, also known as the EtherCAT master, is responsible for managing the EtherCAT network, exchanging data with the slave devices, and interfacing with outside applications. The slave devices, known as the EtherCAT slaves, are typically sensors, drives, actuators, and simple digital/analog I/O, that perform specific tasks in the automation system.

3.2 EtherCAT Slave Information (ESI)

An ESI file, or "EtherCAT Slave Information" file, is a type of configuration file used in EtherCAT systems to describe the functionality and configuration settings of EtherCAT slave devices. ESI files, which are XML based, are provided by the manufacturer or vendor of the slave device, and they contain information necessary for the master to configure and communicate with the slave device. The ESI file contains detailed information about the EtherCAT slave, including its device type, its supported mailbox protocols, synchronization settings, and the mapping of its input and output process data (PDO). The slave device may contain service data objects (SDOs) and list them in an Object Dictionary. When including the Object Dictionary, the ESI file then includes the complete list of objects.

3.3 EtherCAT Network Information (ENI)

An ENI file, or "EtherCAT Network Information" file, is a type of standardized configuration file used in EtherCAT systems to define the network topology, positioning of the slaves in the network, and the process data structures of all EtherCAT slaves. The ENI file is typically built using an EtherCAT configuration tool that has defined the network topology (either by scanning the network for EtherCAT slave devices, or by manually adding slave devices) and parses the information from the provided ESI files from each slave device. The ENI file is used by the EtherCAT master to configure and initialize the network, and it contains all the necessary information for the master to communicate with each device on the network.

3.4 Master

An EtherCAT master is a device that manages and controls an EtherCAT network. It is typically a PC or embedded microprocessor, a programmable logic controller (PLC), or a motion controller that is responsible for communicating with and controlling the EtherCAT slaves that are the devices connected to the network. The EtherCAT master acts as the point of control for the network, and it is responsible for managing the communication between the slaves, issuing commands to the slaves, and receiving data from the slaves.

The master is also responsible for managing the network clock and synchronization across the network, and for error-handling mechanisms such as watchdog timers and automatic retries. It also uses the information from the ENI and ESI files to configure the network and to understand the network topology and slave capabilities.

3.5 Slave

An EtherCAT slave is a device that is connected to an EtherCAT network and controlled by an EtherCAT master. These devices are typically sensors, drives, actuators, or other types of automation devices that perform specific tasks in the automation system. In order to enable EtherCAT’s unique on-the-fly frame processing, EtherCAT slave devices require an EtherCAT Slave Controller (ESC). The ESC can be a dedicated chip like an ASIC, implemented as an IP Core in an FPGA, or even integrated directly into the processor. ESCs can be designed manually but are also widely available off-the-shelf from many different manufacturers.

EtherCAT slaves communicate with the master by reading data from and writing data into the EtherCAT frames sent from the master as they move through the network, and they are also able to communicate with other slaves on the network via slave-to-slave communication. Each slave device is automatically assigned a unique identification number called an "address", and the master device uses this address to communicate with the slave device. The functionality of a slave device is defined by the slave's ESI file which is typically provided by the slave’s manufacturer. The ESC allows various topologies and enables cable and master redundancy.

The slaves also have built-in error handling mechanisms, such as watchdog timers and automatic retries, which help to ensure reliable communication and prevent errors from causing the system to fail.

3.6 Error Detection and Diagnosis

EtherCAT has many useful and convenient error detection and diagnostic features built in that make troubleshooting and maintenance fast and easy. Error detection and diagnostics play a major role in determining a machine’s availability, operability, and commissioning time.

EtherCAT includes the ability to scan and compare the actual network topology with the configured topology during boot-up. This comparison is useful in detecting cabling issues and other physical layer problems and is an enormous advantage in comparison to conventional fieldbus systems.

Furthermore, with EtherCAT it is possible to determine the exact node in the network where the error was initiated. This is known as error localization. EtherCAT can detect and localize occasional disturbances before the issue impacts the machine’s operation.

The EtherCAT Slave Controller in each node checks the moving frame for errors with a checksum. Information is provided to the slave application only if the frame has been received correctly. If there is a bit error, the error counter is incremented and the subsequent nodes are informed that the frame contains an error. The master device will also detect that the frame is faulty and discard its information. The master device can detect where the fault originally occurred in the system by analyzing the nodes’ error counters.

Within the frames, the Working Counter enables the information in each Datagram to be monitored for consistency. Every node that is addressed by the Datagram and whose memory is accessible increments the Working Counter automatically. The master is then able to cyclically confirm if all nodes are working with consistent data. If the Working Counter has a different value than it should, the master notifies the application about the discrepancy. The master device is then able to automatically detect the reason for the unexpected behavior with help from status and error information from the nodes as well as the Link Status.

Thanks to EtherCAT’s unique principle of bandwidth utilization, which is orders of magnitude better than industrial Ethernet technologies that use single frames, the likelihood of disturbances induced by bit errors within an EtherCAT frame is substantially lower – if the same cycle time is used. If much shorter cycle times are used, the time required for error recovery is significantly reduced. Thus, it is also much simpler to address such issues within the application.

Since EtherCAT utilizes standard Ethernet frames, Ethernet network traffic can be recorded with the help of free Ethernet software tools. For example, the well-known Wireshark software comes with a protocol interpreter for EtherCAT, so that protocol-specific information, such as the Working Counter, commandos, etc. are shown in plain text.

Contact Us