An Introduction to EtherCAT

EtherCAT is an Industrial Ethernet field bus. It uses standard IEEE 802.3 Ethernet frames to transport information across the network. Ethernet frames transporting EtherCAT datagrams use the registered EtherType 0x88A4. EtherCAT networks have a single master and multiple slaves. The master uses a standard MAC controller to send and receive EtherCAT frames. The slaves require an EtherCAT Slave controller (ESC).

EtherCAT Slave Controller

All EtherCAT slaves must have an EtherCAT slave controller. It is able to process EtherCAT frames sent from the master “on the fly”, i.e. the ESC reads and writes date from/to the frame while the frame passes the slave. This allows a low latency and low jitter frame processing. Each slave forwards the frame to the next slave. The last slave loops the frame back to the master. An ESC has registers and Process Data RAM. The master can access these registers and the RAM through EtherCAT frames. The slave’s CPU must use the ESC’s Process Data Interface (PDI). The ESC is responsible for data consistency. The registers are used for configuration and status information. The Process Data RAM is used to exchange cyclic and acyclic data between master and slave.

Sync Managers

An ESC has usually at least four Sync Managers. These can be used to guard areas of the Process Data RAM. They provide locking mechanisms for consistent process data. They can also be used to inform both master and slave about new data. Sync Managers can be configured to run in Buffered Mode or Mailbox Mode.

Mailbox Sync Managers are used to transfer acyclic data (Application Layer Protocols). A mailbox can either be written by the master and read by the slave or vice versa. Thus two Mailboxes are required for acyclic communication in both directions. They lock the buffer for one side while he other side is accessing the buffer.

Sync Managers in Buffered Mode are used to transfer process data (realtime data). They allow simultaneous reading and writing by reserving three buffers of the same size. Only the first buffer is visible to both sides. One buffer is used for writing data and one buffer is used for reading data. The third buffer is used to store the last written data. Thus new data can be written while the old data is still read. Usually two Sync Managers in buffered Mode are used to transfer the process data in both directions.

The EtherCAT specification requires this Sync Manager usage:

Table: Sync Manager Usage

Input Only slaves can use Sync Manager 2 as Input.

Mailbox Protocols

As stated above the ESC usually provides two Mailboxes for acyclic data exchange. This section introduces the Application Layer Protocols transfered via mailbox.

CANopen over EtherCAT (CoE)

This protocol allows to access a CANopen object dictionary. CANopen is a common field bus based on CAN. CoE allows to organize the acyclic data in an object dictionary. The object Dictionary is divided into different areas.

Table: CoE Object Dictionary

Just like in CANopen there are services to upload and download these objects also known as SDOs (Service Data Objects). The slave can also send an Emergency message to the master to propagate local errors. In contrast to CANopen a CoE message is not limited to 8 bytes, thus allowing a more efficient data transfer. Additionally the SDO Info Service is provided that enables the master to completely read all meta information about all objects. CoE also introduces Complete Access. This method can be used to upload or download all sub-indices of an object at once. If an object does not fit into a mailbox, it can be exchanged via Segmented SDO transfer.

There are special objects reserved to define the PDO mapping. A PDO (Process Data Object) determines which objects are cyclically transfered as process data. There are special PDO mapping objects. Each object can have several entries. Each entry defines the index, sub-index and bit size of an object that should be used for process data.

Table: PDO mapping objects

Each Sync Manager has a PDO Assignment Object (0x1C10 - 0x1C2F). Its entries list the PDO Mapping objects that are assigned to a Sync Manager.

Table: Sync Manager Assignment objects

Open

Figure: PDO Mapping in EtherCAT

With the help of the PDO Assignment objects and the PDO Mapping objects it is possible to define the byte stream transfered via Process Data Sync Managers.

In the order of the entries of the PDO Assignment Object each PDO Mapping Object’s content is mapped to the byte stream without alignment. This means the byte stream starts with the objects listed in the first assigned PDO Mapping object followed by the objects listed in the second assigned PDO mapping object, etc.

Depending on the direction either the objects are mapped from the Object Dictionary into the byte stream (TxPDO) ore vice versa (RxPDO).

The PDO configuration can be static or dynamic. If the PDO mapping is static the PDO Mapping and Assignment Objects cannot be altered. Dynamic PDO configurations allow at least the PDO Assignment Objects to be changed. Thus allowing to use different predefined PDO Mapping objects. Additionally the PDO Mapping Objects can also be writable. Thus allowing to freely choose which objects in which order are used as process data.

Ethernet over EtherCAT (EoE)

The EoE mailbox protocol allows the transfer of normal Ethernet frames via EtherCAT. The frames are fragmented and transfered without interrupting the cyclic process data. The slave can both receive and transmit Ethernet frames via EoE. Thus standard Ethernet based protocols like HTTP, SMTP, etc. can be used. This way an EtherCAT slave can run a web server.

File Access over EtherCAT (FoE)

The FoE services allow the upload and download of files to/from the slave similar to the TFTP protocol. This can be used to download new firmware to the slave or to exchange large configuration data.

Servo Profile over EtherCAT (SoE)

This mailbox protocol is used access SERCOS identifiers in the EtherCAT slave.

Vendor specific Profile over EtherCAT (VoE)

This mailbox protocol allows vendors to implement their own mailbox protocol. The protocol is identified by the Vendor ID and a vendor specific protocol number. VoE can only be used if the master also knows this protocol.

ADS over EtherCAT (AoE)

This protocol allows the exchange of Automation Device Specification (ADS) messages via EtherCAT. It is usually used to embed the other mailbox protocols in asynchronous messages. This can be used by modular devices or fieldbus gateways. They usually forward the message to the actual recipient.

EtherCAT State Machine

An EtherCAT slave has different states. The master configures the slave and requests a state change. The slave must check the configuration and either acknowledge or reject the state change. In case of error the slave writes an error code to one of its registers.

Table: Slave behavior in all EtherCAT states

Not all state transition are possible. The following figure shows all allowed transitions.

Open

Figure: EtherCAT State Machine

Distributed Clocks

An EtherCAT Slave Controller might support Distributed Clocks (DC). These timer units are used to synchronize all slaves of an EtherCAT segment to a common system time. Further more one of the following behavior can be configured

• Generating synchronous output signals (SyncSignals)

• time stamping of input events (LatchSignals)

• interrupt generation for synchronizing the slave application

Explicit Device Identification

The master can request the slave to put its Explicit Device ID into a special ESC register. This way the master can explicitly identify a slave. The Explicit Device ID must be configured in the slave by non-EtherCAT means, e.g. via rotary switches, a display, etc.

EtherCAT Slave Information Interface (SII)

The SII is an EEPROM that is directly connected to the ESC via I2C. It contains information for the ESC configuration and slave identification. These information are used to describe the slaves capabilities.

The EEPROM can be accessed via EtherCAT frames by the master. Thus the master can identify a slave. It is also possible for the slave to access the EEPROM via PDI. But this requires the permission of the master.

Some ESCs, usually FPGA IP cores, do not need an EEPROM. They emulate the EEPROM by issuing the read and write commands to the slave application. The application must store the virtual EEPROM in non-volatile memory.

Acknowledgment by Write

If an ESC IP Core is implemented into an FPGA it might be connected to a Soft-CPU via a 32bit memory bus. There are buses that do not allow byte access. Since most ESC events are cleared by reading a register, it might be possible that an ESC event is accidentally cleared without processing it. If this feature is enabled in the IP Core ESC, events can only be cleared by writing the corresponding ESC register or memory.