• EtherCAT is a real-time capable fieldbus system.
• A PC with real-time OS, like Linux with RT-patch, and Ethernet hardware can be used as the master.
• The slaves require special EtherCAT hardware.
• With EtherCAT, data packets, so-called PDOs (process data objects), are sent cyclically from the master to the slaves and from the slaves to the master.
• A PDO can, for example, be an encoder value or an output value for a drive.
• Acyclic messages, so-called SDOs (service data objects), are not discussed in this documentation.

At its lowest level, ethercat uses an ethernet frame to send EtherCAT datagrams containing commands to read or write data, or both ('r', 'w', 'rw'). Each Datagram consists of a header, its data and the working counter, which servers as a status indicator or checksum. Depending on the operation, the counter is either not incremented at all (+0), by 1, 2 or 3, if data was read, written or both. (: which is read and which is write?)

The data that is actually read or written is accessed using a 4Gbit address space using byte.bit addressing. EtherCAT technically bit alignment, though in practice most things seem to be byte aligned. This address space is called the Process Data Image or PDI. Object living in that space are often referred to as Process Data Objects or PDOs, though it's not entirely clear, whether that strictly refers to PDOs in the sense of CANOpen or is to be understood as a separate term.

Each Slave Device can be configured to output some of its PDOs on the EtherCAT bus. This is done through the ENI file.

The PDOs can then be accessed on the master by caclulating their offset into the respective buffer (RX buffer for TX PDOs, TX buffer for RX PDOs). An example mapping is shown below.

Ec-Engineer specific: Note that that the TX buffer is padded to the size of the RX buffer. This ensures that a device's first RX & TX PDO will allways be at the same offset. In general, whichever buffer is smaller is padded to the size of the bigger one.

This article deals mainly with Linux based masters.

In this example workflow a Linux based master with Acontis stack and EEROS is used.

We build our system with Yocto. The necessary recipes and resources can be found in the private repository meta-ntb-ethercat together with information about acquired licenses. This repository must be private as it contains the licensed runtime libraries.

1. Choose Linux master
2. Set up the Linux master
3. Test and tune real-time performance of the Linux master
4. Create ENI file
5. Install the Acontis stack on the Linux master
6. Test the installed stack
7. Get the ecmasterlib, build, and install, see ecmasterlib
8. Test the examples packed with ecmasterlib
9. Use with EEROS
10. Full example with Teststand.

ecmasterlib and EtherCATInterface contains two examples (standalone and EEROS application). See Teststand how to build them.

The ecmasterlib and EtherCATInterface offer a relative easy way to use EtherCAT with EEROS or in a standalone project. ecmasterlib offers the low level interface to the Acontis stack (class A). It is based on the demo application EcMasterDemoDC from Acontis. EtherCATInterfaceElmo interface is specific for Gold Twitter drives from ElmoMC. Other drives (i.e. Maxon Maxpos 50/5) need a different interface. You may copy and adapt EtherCATInterfaceElmo for your drive type.

EEROS > EtherCATInterfaceElmo > ecmasterlib & EtherCATInterfaceBase > Acontis Stack

Detailed description

• The EtherCAT demo or application does not start
• Timing problems
• Wireshark

The „EC-Teststand“ (EtherCAT test setup) is a setup with 2 Elmo Drives, 2 motors, powersupply and PC with RT-Linux and the following software:

• Acontis EtherCAT stack
• EEROS
• ecmasterlib
• EtherCATInterfaceElmo including test application

More detailed description here.

Christoph Widmann Geschäftsführer / Managing Director
acontis technologies GmbH
St.-Konrad-Str. 51, 88250 Weingarten, Germany
Phone: +49 (0) 751 5 60 30 32
http://www.acontis.com