Many library exists to create and use an EtherCAT Master but we focuses on “Simple open EtherCAT Master” (SOEM) develops by Open EtherCAT Society and “EtherCAT Master” from EtherLab software develops by the Engineering Association IgH.

1 IgH EtherCAT Master Library

IgH EtherCAT Master library is a component of EtherLab. EtherLab is a technology combining hard and software for test and automation purposes. EtherLab is not a product but a technique built from reliable and well known components and also new technical approaches. Basically EtherLab works as a Real Time kernel module attached to the open source operating system Linux communicating with peripherals devices by a special Ethernet technology, known as EtherCAT.

This section will first introduce the master’s general features and the concepts used for master development and will then explain the master’s general architecture.

1.1 Features Summary

The list below gives a short summary of the master features.

  • Designed as a kernel module for Linux 2.6 / 3.x.
  • Implemented according to IEC 61158-12.
  • Comes with EtherCAT-capable native drivers for several common Ethernet chips, as well as a generic driver for all chips supported by the Linux kernel.
    • The native drivers operate the hardware without interrupts.
    • Native drivers for additional Ethernet hardware can easily be implemented using the common device interface provided by the master module.
    • For any other hardware, the generic driver can be used. It uses the lower layers of the Linux network stack.
  • The master module supports multiple EtherCAT masters running in parallel.
  • The master code supports any Linux realtime extension through its independent architecture.
    • RTAI (including LXRT via RTDM), ADEOS, RT-Preempt, Xenomai (including RTDM), etc.
    • It runs well even without realtime extensions.
  • Domains are introduced, to allow grouping of process data transfers with different slave groups and task periods.
    • Handling of multiple domains with different task periods.
    • Automatic calculation of process data mapping, FMMU and sync manager configuration within each domain.
  • Communication through several finite state machines.
    • Automatic bus scanning after topology changes.
    • Bus monitoring during operation.
    • Automatic reconfiguration of slaves (for example after power failure) during operation.
  • Distributed Clocks (DC) support.
    • Configuration of the slave’s DC parameters through the application interface.
    • Synchronization (offset and drift compensation) of the distributed slave clocks to the reference clock.
    • Optional synchronization of the reference clock to the master clock or the other way round.
  • CANopen over EtherCAT (CoE)
    • SDO upload, download and information service.
    • Slave configuration via SDOs.
    • SDO access from userspace and from the application.
  • Ethernet over EtherCAT (EoE)
    • Transparent use of EoE slaves via virtual network interfaces.
    • Natively supports either a switched or a routed EoE network architecture.
  • Vendor-specific over EtherCAT (VoE)
    • Communication with vendor-specific mailbox protocols via the API.
  • File Access over EtherCAT (FoE)
    • Loading and storing files via the command-line tool.
    • Updating a slave’s firmware can be done easily.
  • Servo Profile over EtherCAT (SoE)
    • Implemented according to IEC 61800-7 standard.
    • Storing IDN configurations, that are written to the slave during startup.
    • Accessing IDNs via the command-line tool.
    • Accessing IDNs at runtime via the the user-space library.
  • Userspace command-line-tool “EtherCAT”
    • Detailed information about master, slaves, domains and bus configuration.
    • Setting the master’s debug level.
    • Listing slave configurations; Access to slave registers; Slave SII (EEPROM) access; Generation of slave description XML and C-code from existing slaves.
    • Reading/Writing alias addresses.
    • Controlling application-layer states.
    • Viewing process data; SDO download/upload; listing SDO dictionaries; Loading and storing files via FoE; SoE IDN access.
  • Virtual read-only network interface for monitoring and debugging purposes.

1.2 General master architecture

The EtherCAT master is integrated into the Linux kernel. It has been made for several reasons:

  • Kernel code has significantly better realtime characteristics, i. e. less latency than userspace code. It was foreseeable, that a fieldbus master has a lot of cyclic work to do. Cyclic work is usually triggered by timer interrupts inside the kernel. The execution delay of a function that processes timer interrupts is less, when it resides in kernelspace, because there is no need of time-consuming context switches to a userspace process.

  • It was also foreseeable, that the master code has to directly communicate with the Ethernet hardware. This has to be done in the kernel anyway (through network device drivers), which is one more reason for the master code being in kernelspace.

1.2.1 Master Module

The EtherCAT master kernel module can contain multiple master instances. Each master waits for certain Ethernet devices identified by its MAC addresses. These addresses have to be specified on module loading via module parameter. The number of master instances to initialize is taken from the number of MAC addresses given.

1.2.2 Device Modules

EtherCAT-capable Ethernet device driver modules, that offer their devices to the EtherCAT master via the device interface. These modified network drivers can handle network devices used for EtherCAT operation and “normal” Ethernet devices in parallel. A master can accept a certain device and then is able to send and receive EtherCAT frames. Ethernet devices declined by the master module are connected to the kernel’s network stack as usual.

1.2.3 Application

A program that uses the EtherCAT master (usually for cyclic exchange of process data with EtherCAT slaves). These programs are not part of the EtherCAT master code, but have to be generated or written by the user. An application can request a master through the application interface. If this succeeds, it has the control over the master: It can provide a bus configuration and exchange process data. Applications can be kernel modules (that use the kernel application interface directly) or userspace programs, that use the application interface via the EtherCAT library, or the RTDM library.

2 Open EtherCAT Society (SOEM)

SOEM (Simple Open EtherCAT Master) is an EtherCAT master library written in c with the following functionality : Master Class; Support for CAN over EtherCAT (CoE); Support for File over EtherCAT (FoE); Support for Servo over EtherCAT (SoE); Support for Distributed Clocks.

As all applications are different SOEM tries to not impose any design architecture. Under Linux it can be used in generic user mode, PREEMPT_RT or Xenomai. under Windows it can be used as user mode program.

2.1 Features Summary

The list below gives a short summary of the master features.

  • Designed in c for Linux 2.6 / 3.x.

  • Comes with EtherCAT-capable a generic driver for all chips supported by the Linux kernel. It uses the lower layers of the Linux network stack.

  • The master module supports redundant EtherCAT masters running in parallel.
  • The master code supports Linux realtime extension through its independent architecture. It can be used in:
    • generic user mode
    • RT-Preempt, Xenomai (including RTDM), etc.
  • Distributed Clocks (DC) support.
    • Automatic configuration of DC slaves.
    • Automatic sync of clocks with process data exchange.
    • Synchronization (offset and drift compensation) of the distributed slave clocks to the reference clock.
  • CANopen over EtherCAT (CoE)
    • SDO upload, download and informations service.
    • PDO upload and download.
    • Slave configuration via SDOs.
  • File Access over EtherCAT (FoE)
    • Loading and storing files.
  • Servo Profile over EtherCAT (SoE)
    • Support read and write request, segment transfert.
    • Auto configuration of SoE process data.

3 Comparison and choice

In order to choose the best library, we have made a comparative table of some importants characteristics.

  IgH Master SOEM
Developers EtherLab Rt-Labs
Licence (master) GPL v2 GPL v2
Licence (API) LGPL v2.1  
Sources SourceForge (mercurial) Githib (git)
Activity (updates, …) recently recently
Language C, makefile, kbuild C, Cmake
System compatibility Linux 2.6 + Linux 2.6 +
RT compatibility all RT Linux generic RT Linux
NIC compatibility Native / generic driver generic driver
Class Master type A type B (simple)
Master mode Multi master Simple master (expendable to multi)
Master redundant mode yes yes
Distributed Clock (DC) yes yes
Supported mode:    
CoE (SDO/PDO) yes yes
SoE yes yes
EoE yes not yet
FoE yes yes
VoE yes not yet
Architecture Kernel module free

NIC: Network Interface Card. CoE: Canopen over EtherCAT. SoE: Sercos over EtherCAT. EoE: Ethernet over EtherCAT. FoE: File over EtherCAT. VoE: Vendor over EtherCAT.

Regarding previous table, two solutions are very similar. The advantage of IgH is to be more compatible with EtherCAT mode than SOEM. However, its architecture is locked in a kernel module. To develop our framework, we need a more flexible architecture and SOEM is develop in this way. So, we have used SOEM from Rt-Labs library to develop our framework.