IOC Robotic's Lab

This section has been designed to provide a relatively fast and simplified introduction to the EtherCAT protocol in order to comprehend the SOEM commands easily, to understand the various kind of data and how they are addressed to the right slave. It can be especially useful to understand the difference between PDO data and SDO data and the synchronisation mechanism of DCclock.

EtherCAT introduction

EtherCAT is a fast, low cost, and flexible Ethernet network protocol. It consists of a master with several slaves. The computer on which the controller runs is the Master, while devices that make data of connected I/O devices available for the master are called slaves.1


EtherCAT has been released in 2003 by Beckhoff. In 2004, Beckhoff helped to create a new group to promote the EtherCAT protocol and its efforts led to the EtherCAT Technology Group (ETG) to which they donated the rights of EtherCAT too. The ETG is a global organization in which OEM, End Users and Technology Providers join forces to support and promote the further technology development.

Nowadays Beckhoff provides a large number of different terminals that make it possible to access from almost any I/O device. Anyway EtherCAT is an open protocol, therefore everybody can make its own terminal.2

Protocol functional principle

Going on analysing the protocol we have to know that EtherCAT commands are transported in the data area of an Ethernet telegram and can either be coded via a special Ether type or via UDP/IP. While the first variant is limited to an Ethernet subnet the second one, designed for less time-critical applications, enables normal IP routing.

Each EtherCAT command consists of an EtherCAT header, the data area and a subsequent counter area (working counter). This working counter is incremented by all EtherCAT devices that were addressed by the EtherCAT command and have exchanged associated data.

Ethernet telegram processing

Each Ethernet ``data pack, called telegram, is processed directly ``on the fly. While the telegram (delayed by only a few bits) is already passed on, the slave recognizes relevant commands and executes them accordingly. Each slave processes the incoming telegrams directly and extracts/inserts the relevant user data and transfers the telegram to the next EtherCAT slave (fig.\ref{fig:EtherCAT_logical_addressing}). The last EtherCAT slave sends the fully processed telegram back, so that it is returned by the first slave to the control as a kind of response telegram.

Telegram processing is done within the hardware and is therefore independent of the response times of any microprocessors that may be connected. Each device has an addressable memory of 64 kB that can be read or written, either consecutively or simultaneously.

The Telegram processing functional principle of EtherCAT can be explained using the analogy of a fast train expressed in three points:

  1. With EtherCAT, the "train" (the Ethernet Frame) does not need to have the same combination of cars (datagrams) in each cycle.
  2. The person (data) in the car (datagram) is identified by the car number (datagram header) and the offset, and then removed or inserted on the fly.
  3. If more process data are to be communicated more than fit within one train (frame) (1488 bytes), a second train is used within the same communication cycle.
EtherCAT logical addressing

Figure A.2: EtherCAT logical addressing


Thanks to FMMU in the slave nodes and DMA access to the network card in the master, the complete protocol processing takes place within hardware and is thus independent of the run-time of protocol stacks, CPU performance or software implementation.

The update time for 1000 distributed I/Os is only 30 us. Up to 1486 bytes of process data can be exchanged with a single Ethernet frame - this is equivalent to almost $12.000$ digital inputs and outputs. The transfer of this data quantity only takes 300 us. The communication with 100 servo axes only takes 100 us. During this time, all axes are provided with set values and control data and report their actual position and status. The distributed clock technique enables the axes to be synchronized with a deviation of significantly less than 1 microsecond.


EtherCAT supports almost any topology:line, tree or star. The Fast Ethernet physics enables a cable length of 100 m between devices while the E-Bus line is intended for modular devices. The size of the network is almost unlimited since up to 65535 devices can be connected.

EtherCAT terminology

WARNING!!: EtherCAT imposes no restrictions on what can be transmitted into its "data" payload field. Consequently, this data field is frequently used to encapsulate and transmit messages of well-established industrial bus protocols like CAN, SERCOS, et cetera. Therefore, EtherCAT literature always mix concepts from other protocols like Object dictionaries, SDO, PDO, etc.


The ESC (fig. A.3) 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 can either be implemented as FPGA (Field Programmable Gate Array) or as ASIC (Application Specific Integrated Circuit). The performance of the EtherCAT communication does not depend on the implementation of the application software in the host controller. In turn, the performance of the application in the host controller does not depend on the EtherCAT communication speed. 3

Another feature of the ESC is to provide data for a local host controller or digital I/Os via the Process Data Interface (PDI).Process data and parameters are exchanged via a DPRAM in the ESC. To ensure data consistency, appropriate mechanisms are provided by the ESC hardware such as SyncManagers.

Figure A.3: EtherCAT Slave Controller (ESC) with the Distribuited clock Unit


The EEPROM (fig. A.4) (Electrically Erasable Programmable Read-Only Memory, also called Slave Information Interface, SII) contains hardware configuration information for the ESC which is loaded to the ESC's registers during power-up.4

Figure A.4: Slave EPROM structure


Fieldbus Memory Management Units (FMMU) convert logical addresses into physical addresses by means of internal address mapping. Thus, FMMUs allow to use logical addressing for data segments that span several slave devices: one datagram addresses data within several arbitrarily distributed ESCs. Each FMMU channel maps one continuous logical address space to one continuous physical address space of the slave. The access type supported by an FMMU is configurable to be either readable, writable, or readable/writable (For an example see table A.1).

FMMU Setup

  1. Master reads hardware configuration including input and output data length of each slave
  2. Master organizes mapping of process data using SDO.
  3. Master distributes information (start address etc.) for every slave about where process data in logical process image is provided.
  4. Process data communication starts

Table A.1: FMMU example: map 6 bits from logical address 0x14711.3 to 0x14712.0 to the physical register bits 0x0F01.1 to 0x0F01.6

FMMU config.registerFMMU reg. offsetValue
Logical start adress0x0:0x30x00014711
Length (Byte)0x4:0x50x0002
Logical Start bit0x60x03
Logical Stop bit0x70x00
Physical Start Adress0x8:0x90x0F01
Physical Start Bit0xA0x01
Type0xBRead and/or Write
Activate0xC1 (Enable)


Since both the EtherCAT network (master) and the PDI (local $\mu$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 Mode

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 (SDO) (e.g. parameter settings)(fig. A.5).

  • Buffered Mode

The buffered mode is typically used for cyclic data exchange, i.e. process data (PDO) 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.

It can be noted that SyncManagers running in buffered mode need three times the process data size allocated in the DPRAM (fig. A.5).

EtherCAT State Machine (ESM)

Every EtherCAT slave device implements the EtherCAT State Machine (ESM) (fig. \ref{fig:States}) that governs the slave's functions as, in every moment, the actual state defines the available range of functions.

Four mandatory and one optional state are defined for an EtherCAT slave: Init, Pre-Operational, Safe-Operational, Operational, Bootstrap (Optional).For every state change a sequence of slave specific commands have to be sent by the EtherCAT master to the EtherCAT slave devices.

Figure A.6: EtherCAT state Machine

Avaiable functions for every EtherCAT State

  • Init: Master: Initial state. Slave:Initial state after power-on. Communication:No mailbox communication and process data exchange.
  • Pre-Operational: Master: Initialization of Sync Manager channels for mailbox communication during the transition from Init to Pre-Operational. Slave: Validation of Sync Manager Configuration during the transition from Init to Pre- Operational. Communication: Mailbox communication but no process data exchange.
  • Safe-Operational: Master: Initialization of Sync Manager channels for process data exchange, initialization of FMMU channels, PDO mapping/assignment (if the slave supports configurable mapping), DC configuration and initialization of device specific parameter which differ from the defaults during the transition from Pre-Operational to Safe-Operational. Slave: Validation of all configured values during the transition from Pre-Operational to Safe-Operational. Communication: Mailbox communication and process data exchange but the slave keeps its outputs in a safe state while the input data is updated cyclically.
  • Operational: Master: Fully operational. Slave: Fully operational. Communication: Mailbox communication and process data exchange is fully working.
  • Bootstrap: Master: Optional state which can only be entered from Init. Slave: Optional state which can only be entered from Init for a firmware update. Communication: Limited mailbox communication (only the FoE protocol is supported) and no process data exchange.

Object Dictionary

The CANopen Object Dictionary (OD) is an ordered grouping of objects; each object is addressed using a 16-bit index. To allow individual elements of structures of data to be accessed an 8-bit subindex has been defined as well. For every slave in the network an OD exists. The OD contains all parameters describing the device and its network behaviour.

Distributed clock

In EtherCAT, distributed clock enable all fieldbus devices to have the same time. A particular device contains the reference clock5, which is used to synchronize the clocks of the other devices.

To this end, the control sends a special telegram at certain intervals (as required in order to avoid the slave clocks diverging beyond specified limits), in which the bus device containing the reference clock enters its current time. The fieldbus devices with slave clocks then read the time from the same telegram.

This mechanism has the final objective to make independent the moment when the Ethernet frame passes through the slave from the time to whom the read data6 refer and/or the written data are applied and could be optionally implemented inside the slave in a part of the ESC (fig. A.3)

Free running, Synchronous with SM event and Sync0

The Distributed clock mechanism ensures the best synchronization but EtherCAT provides three possibilities to synchronise slaves that can be chosen writing the dictionary objects 0x1C32/1C33.

When the subindex 1 of these objects is set to 0 (default) the sync manager will be configured for free running mode. When the master sends an EtherCAT packet to write/read the process data to/from the drive, the data it will write/receive will be from the most recent servo cycle.In ``Free Run'' mode the local cycle operates independent of the communication cycle and/or the master cycle.

When the subindex 1 of these objects is to 1 (default) the sync manager will be configured for Synchronous with SM event. The local cycle is started when the SM2 event [with cyclical outputs] or the SM3 event [without cyclical outputs] is received. Using this mode, the slave will update the input/output process data available for the master to read on every slave update, that is every time an Ethernet frame passes through it. If the outputs are available, the slave is generally synchronized with the SM2 event. If no outputs are available, the slave is synchronized with the SM3 event, e.g. for cyclical inputs.

When the subindex 1 of these objects is set to a value of 2, the sync manager will be placed in SYNC0 synchronization mode. In this mode, the drive will sample the output/input data at the time of the SYNC0 pulse, and update the buffers used to transmit/receive this data to the master shortly after that time. Therefore the master has two advantages:

  1. it can read data back and know what the state of the drive was at the SYNC0 time
  2. it is allowed to transmit the data intended to be used at SYNC0 time early, and the slave will not use the data until the SYNC0 signal occurs.

Using the second and the third synchronisation mode, it is possible to set an offset to shift the input latch and output valid events with respect to the synchronization pulse reference.

How it works

To measure the offset times, the EtherCAT master sends a broadcast read datagram to a special address in all ESCs during the startup phase that causes each slave to record the time when the telegram is received (based on its local clock) in both directions. The master then reads the stored times as a basis for the calculation. These measuring cycles take place several times for all EtherCAT slaves. This enables the EtherCAT master to create a very precise map of the topology in relation to the frame delays between the EtherCAT slaves. 7 The following effects must be taken into account by the distributed clock control in the EtherCAT master8:

  • Offset compensation of each slave relative to the reference clock. After system start-up the local clocks may start with different start values.
  • Offset compensation of the reference clock relative to the master clock. To be taken into account during system start-up.
  • Propagation delay measurement: Measurement of the offset times depending on the number of devices, cable lengths, dynamic changes in the configuration, etc.
  • Drift compensation/drift correction. Each slave clock usually has its own source (quartz, PLL, ...), which means that offset times do not remain constant over a prolonged period (minutes, days). Drift correction deals with this irregularity.

Avoiding jitter 9

It's very common in an EtherCAT system for the master to run on a complex PC operating system, and therefore it doesn't have the high degree of real time performance that the slaves ensure. In such cases there can be a significant amount of timing jitter on the process data messages that the master sends.

For example, if the master has +/- 100 $\mu$s of jitter on it's PDO transmission timing, then the slave may receive the process data update anywhere from 150 μs before SYNC0 to 50 μs after SYNC0. Configuring the slave to use SYNC0 synchronization mode can resolve the problems caused by timing jitter in the master.

In this mode the master can compensate for its worst case timing jitter by transmitting the process data to the slaves sufficiently early to ensure that the data will be received before the SYNC0 signal. The slaves will not use the process data received until the SYNC0 pulse, so the system can remain well synchronized even with a significant amount of timing jitter in the master.

For example, in a system with a cycle time of 1ms and +/-100 μs of timing jitter on the master, the master could be configured to transmit its process data with a 500 μs offset (half the cycle time) from the SYNC0 time on the slaves. This would ensure that the slave devices received the process data of the SYNC0 update ``well clear''. 10

Configuration files

EtherCAT Slave Information File

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 and it could be used by the configuration tool to compile network information (ENI) in offline mode.

EtherCAT Network Information File

The ENI file describes the network topology, the initialization commands for each device and the commands which have to be sent cyclically. The ENI file could be provided to the master in order to provide an easier and faster configuration. Then the master would send data to slaves according this file. Its use is not compulsory but could automate a part of the master's configuration without reading every slave's information from the SII11.

A.3 Message syntax

EtherCAT can provide the same communication mechanisms as the familiar CANopen mechanisms: object dictionary, PDO (process data objects) and SDO (service data objects).

Service Data Objects (SDO)

The Service Data Object (SDO) are used to access the Object Dictionary of a device. The requester of the OD access is called the Client and the EtherCAT device, whose OD is accessed and services the request, is called the Server. A Client request is always confirmed by a reply from the Server.12

              (a) SDO download request.                         (b) SDO download respone.

                    Figure A.7: SDO read: download request and download response

Process Data Objects(PDO)

Process Data Objects are used to transfer real-time data among various nodes. Data are transferred from one (and only one) producer to one or more consumers.One PDO can contain multiple object dictionary entries. The objects within a PDO are configurable using the mapping (see section A.3) and the parameter object dictionary entries (fig. A.8). There is a maximum of 64 bits for PDO. There are two kinds of PDO:

  • Transmit PDO: reads data from device
  • Receive PDO: sends data to device

PDO mapping

To configure how many and which object dictionary entries have to be cyclically updated using PDO, the user has to send a sequence of SDO that "map" all the desired variables 13 in the objects that would be transmitted using PDO. The PDO mapping procedure (fig. A.8) could be performed only when the slave is in pre-operational state. The objects mapped in the PDO input could be different from the objects of the PDO output.



1 EtherCAT Technology Group:

2 EtherCAT Technology Group:

3 Beckhoff. ''Hardware Data Sheet Guide ETG.2200.2012.

4 Beckhoff. ''Hardware Data Sheet Guide ETG.2200.2012.

5 The reference clock can be the EtherCAT master's clock or not. It depends on which variant is chosen during the implementative phase.The two possibilities are: force DC time to sync with that of the master (require a master with a good clock) or synch Master's loop to the DC System Time. Usually, in this case, the clock of the first slave that is DC capable is chosen as the reference clock.

6 Data read from the slave and written in the datagram.

7 Beckhoff Infosys. URL:

8 ETG.1400 gives an example for the clock synchronization initialization, containing propagation delay measurement, Offset compensation to the Reference clock and drift compensation

9 Jitter is the undesired deviation from true periodicity of an assumed periodic signal in electronics and telecommunications

10 Copley Controls. EtherCAT network synchronization. 2012. URL:

11 This tool isn't officially provided in SOEM library yet. But a part of the slave depending information could be manually added to the file ec_configlist.h 6.1.3

12 H.Boterenbrood. CANopen high-level protocol for CAN-bus. 2000

The object dictionary values can be larger than the 8 byte (limit of CANframe) because the SDO protocol implements segmentation and de-segmentation functions. There are 3 mechanisms for SDO transfer depending on the Data size: Expedited (Data <=4 byte), Normal(4 Byte < Data < MBX size), Segmented (Data > MBX size) [^ EtherCAT Technology Group. EtherCAT Technology Group.

13 Every dictionary entry if it is readable and writeable could be seen as a variable.