EtherCAT is one of several Industrial Ethernet field buses. It uses standard IEEE 802.3 Ethernet frames to transport information across the network. EtherCAT uses the registered EtherType 0x88A4 in its frames.

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:

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.

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 is used for process data.

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.

Sync Manager Assignment objects

Figure 4: 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.

Slave behavior in all EtherCAT states

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

Figure 5: 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.

Introduction to CC-Link IE TSN

CC Link IE TSN is an ethernet based industrial communication stack. It is based on earlier CC Link IE concepts, uniting them with the ideas of time synchronized networking (TSN). The standards are maintained by the CC Link Partners Association (CLPA).

In a CC-Link IE TSN network, all stations perform time synchronization using either PTP IEEE1588v2 or gPTP IEEE802.1AS. The time synchronization is performed in the initialization sequence and periodically during the runtime sequence.

Communications are performed with the communication cycle divided into time slots as a time sharing method. Settings related to the time sharing method are configured once in the initialization sequence.

Table 3: Example of time slots in a cycle

In this example Tslt1 is used for the cyclic communication, Tslt2 for the time synchronization and Tslt0 for everything else. Length and order of the timeslots can be configured as needed, but the catch all timeslot is usually last. Some extras, such as guard banding etc. are also possible options.

All devices taking part in the cyclic communication will observe these timeslots. Common start time of the timeslots is ensured by the time synchronization.

Note: 10ms is only for the example, cycle times are usually lower.

Central Concepts

SLMP

SLMP (Seamless Messaging Protocol) is a protocol used to implement communication between applications seamlessly without awareness of the network hierarchy and boundaries. It is often used in communication between the CC-Link family network and other general-purpose Ethernet devices.

SLMP messages are defined as payload, using a lower level network service such as TCP/IP, UDP or CC Link IE TSN as transport layer. In the port CC Link IE TSN implementation, SLMP is provided by GOAL and uses UDP.

The CC Link IS TSN stack uses SLMP messages extensively for the setup process.

TSN

Two methods for time synchronization are supported by CC Link IE TSN:

• PTP, described in IEEE1588v2

• gPTP, described in IEEE802.1AS

Both methods used timestamped ethernet frames to determine delays and derive a timestamp that is the same on all devices in the system. In the port CC Link IE TSN implementation, they are provided by the underlying GOAL runtime. For both methods, the ethernet controller of the hardware needs to support time stamping of incoming and outgoing frames. For gPTP, two hardware clocks should be provided, though the implementation in GOAL also works with just one.

Qbv

While TSN ensures common starttime of cycles, another mechanism is needed to ensure messages are only sent inside of the corresponding timeslots. For each message to be sent, it must always be checked if the timeslot is open and if the message can be fully transmitted inside of it. If not, the message must be queued for the next transmission cycle.

Every time a timeslot opens, it will check if there are queued message to be sent.

This is standardized in IEEE802.1Qbv. Qbv can be supported by hardware or simulated in software. The software variant requires calculation effort that often makes it only usable for Class A devices.

Link Devices

The data that is transferred, is locally organized in so-called link devices. These differentiate by direction and by data type.

Table 4: Overview of link devices

*not yet supported

Remote Stations provide data in link devices with predefined sizes, positions and meaning. The master device selects data for cyclic transfer from the available link devices by defining payloads during the communication setup.

The statusword link device is standardized data provided only in the direction from remote stations to the master. It contains predefined bit data concerning the status of the remote station and its cyclic connection.