EtherCAT (Ethernet for Control Automation Technology) is an Ethernet-based fieldbus system, invented by Beckhoff Automation. The protocol is standardized in IEC 61158 and is suitable for both hard and soft real-time computing requirements in automation technology.
1 General principle
With EtherCAT, the standard Ethernet packet or frame (according to IEEE 802.3) is no longer received, interpreted, and copied as process data at every node. The EtherCAT slave devices read the data addressed to them while the telegram passes through the device, processing data “on the fly”. Similarly, input data are inserted while the telegram passes through. A frame is not completely received before being processed; instead processing starts as soon as possible. Sending is also conducted with a minimum delay of small bit times. Typically the entire network can be addressed with just one frame.
EtherCAT in a standard ethernet frame (according to IEEE 802.3) :
example of inserting process data “on the fly” :
2 EtherCAT system architecture
The basic EtherCAT system configuration is shown in below figure. The EtherCAT master uses a standard Ethernet port and network configuration information stored in the EtherCAT Network Information file (ENI). The ENI is created based on EtherCAT Slave Information files (ESI) which are provided by the vendors for every device. Slaves are connected via Ethernet, any topology type is possible for EtherCAT networks.
EtherCAT general architecture :
3 EtherCAT Slave informations
3.1 EtherCAT slave architecture
Figure below shows the EtherCAT network with focus on the slave architecture. Basically, the slave contains three main components :
EtherCAT slave architecture :
Physical layer - network interface : standard ethernet physical layer components. The network interface contains the physical layer components to process fieldbus signals. It forwards network data to the slave controller (ESC) and applies signals from the ESC to the network. The physical layer is based on the standards defined by standard Ethernet (IEEE 802.3).
Data link layer - EtherCAT slave controller (ESC) : The ESC is a chip for EtherCAT communication. The ESC handles the EtherCAT protocol in real-time by processing the EtherCAT frames on the fly and providing the interface for data exchange between EtherCAT master and the slave’s local application controller via registers and a DPRAM. The ESC processes EtherCAT frames on the fly and provides data for a local host controller or digital I/Os via the Process Data Interface (PDI). PDI availabilities depend on the ESC type. The PDI is either : Up to 32 Bit digital I/O ; Serial Peripheral Interface (SPI) ; 8/16-bit synchronous/asynchronous Microcontroller Interface(MCI) ; With FPGA (specific on-board-bus).
Data link layer - EEPROM (Electrically Erasable Programmable Read-Only Memory) : The EEPROM, also called Slave Information Interface (SII) contains hardware configuration information for the ESC which is loaded to the ESC’s registers during power-up. The ESC registers are then e.g. configured for the PDI so that the DPRAM can be accessed from the local μC. The EEPROM can be written by the configuration tool (via EtherCAT) based on the ESI file. The μC can also access the EEPROM if access rights are assigned. However, the EEPROM is always accessed via the ESC, which in turn interfaces to it via Inter-Integrated Circuit (I2C) data bus.
Application layer - host controller : Application layer services, i.e. communication software and device specific software, can be implemented on a local μC. This controller then handles the following :
- EtherCAT State Machine (ESM) in the slave device
- Process data exchange with the slave application (e.g. application and configuration parameters, object dictionary (SDO))
- Mailbox based protocols for acyclic data exchange (CoE, EoE, FoE)
- Optional TCP/IP stack if the device supports EoE. The μC performance depends solely on the device application, not on the EtherCAT communication. In many cases an 8-bit μC / PIC is sufficient.
3.2 EtherCAT slave configuration
3.2.1 EtherCAT slave information file (ESI)
Every EtherCAT device must be delivered with an EtherCAT Slave Information file (ESI), a device description document in XML format. Information about device functionality and settings is provided by the ESI. ESI files are used by the configuration tool to compile network information (ENI) in offline mode (e.g. process data structures, initialization commands).
3.2.2 EEPROM EtherCAT slave configuration
The DPRAM in the ESC is a volatile RAM, so it is connected to an EEPROM. The EEPROM stores slave identity information and information about the slave’s functionality corresponding to the ESI file, see below figure. The content of the EEPROM has to be configured by the vendor during development of the slave device. EEPROM information can be derived from the ESI file.
3.2.3 Fieldbus memory management unit (FMMU)
Fieldbus Memory Management Units (FMMUs) are used to map data from the (logical) process data image in the master to the physical (local) memory in the slave devices. Process data in the master’s image is arranged by tasks. Related to this, the master configures via the FMMUs which EtherCAT slave devices can map data in a same EtherCAT datagram to automatically group process data. Thus, process data mapping in the master is not necessary anymore and a significant amount of CPU time and bandwidth usage are saved.
Since both the EtherCAT network (master) and the PDI (local µC) access the DPRAM in the ESC, the DPRAM access needs to ensure data consistency. The SyncManager is a mechanism to protect data in the DPRAM from being accessed simultaneously. If the slave uses FMMUs, the SyncManagers for the corresponding data blocks are located between the DPRAM and the FMMU. EtherCAT SyncManagers can operate in two modes.
Mailbox : The mailbox mode implements a handshake mechanism for data exchange. EtherCAT master and μC application only get access to the buffer after the other one has finished its access. When the sender writes the buffer, the buffer is locked for writing until the receiver has read it out. The mailbox mode is typically used for application layer protocols and exchange of acyclic data.
Buffered Mode : The buffered mode is typically used for cyclic data exchange, i.e. process data since the buffered mode allows access to the communication buffer at any time for both sides, EtherCAT master and μC application. The sender can always update the content of the buffer. If the buffer is written faster than it is read out by the receiver, old data is dropped. Thus, the receiver always gets the latest consistent buffer content which was written by the sender.
3.3 EtherCAT Slave State machine
The slave runs a state machine to indicate which functionalities are actually available. This EtherCAT State Machine (ESM) is shown in figure below. ESM requests are written by the master to the slave’s AL Control register in the ESC. If the configuration for the requested state is valid, the slave acknowledges the state by setting the AL Status register. If not, the slave sets the error flag in the AL Status register and writes an error code to the AL Status Code register. Next table describes available function for each steps.
The EtherCAT protocol is optimized for process data and is transported directly within the standard IEEE 802.3 Ethernet frame using Ethertype 0x88A4. It may consist of several sub-telegrams, each serving a particular memory area of the logical process images that can be up to 4 gigabytes in size. The data sequence is independent of the physical order of the nodes in the network; addressing can be in any order. Broadcast, multicast and communication between slaves is possible, but must be initiated by the master device. If IP routing is required, the EtherCAT protocol can be inserted into UDP/IP datagrams. This also enables any control with Ethernet protocol stack to address EtherCAT systems.
For synchronization a distributed clock (DC) mechanism is applied, which leads to very low jitter, significantly less than 1 µs, even if the communication cycle jitters, which is equivalent to the IEEE 1588 Precision Time Protocol standard (PTP). Therefore, EtherCAT does not require special hardware in the master device and can be implemented in software on any standard Ethernet MAC, even without dedicated communication coprocessor. Slave devices are generally synchronized either by datas arrived on SyncManager buffer or by synchronize signal (SYNC0 and/or SYNC1). For more informations about DC you can read this page.
6 Communication Profiles
In order to configure and diagnose slave devices, it is possible to access the variables provided for the network with the help of acyclic communication. This is based on a reliable mailbox protocol with an auto-recover function for erroneous messages. In order to support a wide variety of devices and application layers, the following EtherCAT communication profiles have been established:
CAN application protocol over EtherCAT (CoE) : With the CoE protocol, EtherCAT provides the same communication mechanisms as in CANopen-Standard : Object Dictionary, PDO Mapping (Process Data Objects) and SDO (Service Data Objects) and the network management is similar.
Servo drive profile (SERCOS), according to IEC 61800-7-204 (SoE) : The SERCOS profile for motion control applications for servo drives is included in the international standard IEC 61800-7. The standard also contains the mapping of this profile to EtherCAT. The service channel, including access to all drive-internal parameters and functions, are mapped to the EtherCAT Mailbox.
Ethernet over EtherCAT (EoE) : With the Ethernet over EtherCAT (EoE) protocol any Ethernet data traffic can be transported within an EtherCAT segment. The Ethernet frames are tunneled through the EtherCAT protocol, similarly to the internet protocols (e.g. TCP/IP, VPN, PPPoE (DSL), etc.) as such, which makes the EtherCAT network completely transparent for Ethernet devices.
File access over EtherCAT (FoE) : This simple protocol similar to TFTP (Trivial File Transfer Protocol) enables file access in a device and a uniform firmware upload to devices across a network. The protocol has been deliberately specified in a lean manner, so that it can be supported by boot loader programs – a TCP/IP stack isn’t required
ADS over EtherCAT (AoE) : As a Mailbox-based client-server protocol, ADS over EtherCAT (AoE) is defined by the EtherCAT specification. While protocols such as CAN application protocol over EtherCAT (CoE) provide a detailed semantic concept, AoE complements these perfectly via routable and parallel services wherever use cases require such features.
EtherCAT communication profile :
A slave device isn’t required to support all communication profiles; instead, it may decide which profile is most suitable for its needs. The master device is notified which communication profiles have been implemented via the slave device description file.
7 For more informations
- Official Beckhoff website : Beckhoff Automation Group
- Official EtherCAT website : EtherCAT Technology Group
- EtherCAT Groups Brochure
- EtherCAT : the Ethernet fieldbus EN ,FR
- Slave implementation guide ETG2200 V3.0.4
- Slave Datasheet section 1 - Technology V2.3
- Slave Datasheet section 2 - Register description V2.9
- Slave Datasheet section 3 - Hardware description for ET1100 V2.0 and ET1200 V2.0.