TechnologyJanuary 7, 2015

Diagnostics with EtherCAT: monitoring of master/slaves

Abstract background

The Working Counter is a mechanism for EtherCAT master devices to monitor slave behavior cyclically and synchronously. In addition to monitoring, fieldbuses support diagnostic tools that enable masters to precisely detect the location, and cause of error conditions at the hardware and application levels of a slave.

Physical Layer and Data Link Layer. With EtherCAT, these two levels take care of all time-critical functions such as frame routing, CRC evaluation and memory access, and they are implemented by a dedicated component called an EtherCAT Slave Controller (ESC).

Application Layer. The Application Layer is responsible for the state machine management, cyclic and acyclic data exchange, as well as device-specific application functions. With EtherCAT, this layer is typically implemented in the firmware of a microcontroller.

EtherCAT provides additional information in several sets of registers within the ESC memory. The address and meaning of these registers are the same for all ESCs, which allows the master devices to read the diagnostic information by means of standard access procedures, independent of the specific slaves connected to the network.

Diagnostics in the ESC address space

Each data exchange between master and slave takes place within the slave’s address space. The ESC address space is logically split in two areas. The user memory (address = 0x1000) is used as dual-ported RAM to exchange application data between the master and slave, both in the form of process data and as a mailbox. The access to this memory area is mediated by functional elements called SyncManagers which guarantee consistent data exchange between the master and the local application.

Registers (address < 0x1000) are a memory area that has a standard structure which is used to configure, control and monitor the slave behavior. Both master and local application can access this memory area directly. Diagnostic information is part of the register area. It can be divided into hardware information and application information.

Hardware diagnostic registers

EtherCAT slaves report the physical link status for each port. This information is provided in the Data Link Status Register (ESC DL Status Register). Every time a link loss is detected on a port, the corresponding Lost Link Counter is incremented.

Lost Link Counters are incremented as a consequence of a physical medium interruption such as a faulty slave or broken cable. Lost Link Counters can be globally reset by the master device with a write access to any of them. To delete errors, which can occur during power-up, this step should be done before the monitoring of the counters begins.

The link status influences the loop status of a port while the latter determines the forwarding direction of frames. An open frame will route frames outwards while a closed port will forward frames internally to other ports of the same slave. DL Status Register reports also provide information about the loop status of each port.

Example 1: Location of network topology changes

EtherCAT master devices can monitor possible changes in the topology by checking the Working Counter value of commands contained in the cyclic frames like, for example, the broadcast read command used to read the slave states. A change in the received Working Counter value for these commands indicates some alteration in the network topology. In order to detect where the change took place, the master device can send a sequence of unicast commands reading the DL Status Register from each slave, and compare the actual loop status of all ports with the values expected according to the configured network topology.

Besides forwarding frames, each open port of an EtherCAT Slave Controller performs CRC evaluation on incoming frames. CRC errors occur as a consequence of bit sequence corruption provoked by EMC disturbances such as those induced by power cables passing very close to the fieldbus connections.

The first open port that detects a new CRC error increments its error counter on this port (RX Error Counter, CRC Error Counter) and marks the frame as corrupted by adding an additional nibble to it.

ESCs can also increment a set of Forwarded RX Error Counters. All open ports receiving an already-detected corrupted frame will identify the added nibble via a previous port, and will therefore increment the Forwarded RX Error Counter instead of RX Error Counter.

Example 2: EMC disturbances corrupting a frame

Strong environmental EMC disturbances can corrupt the bit sequence of frames traveling along an EtherCAT network. In case all network slaves support Forwarded CRC Error Counters, the first port receiving the frame will increment its CRC Error Counter and will add the nibble to the frame marking it as corrupted. All the ports receiving the frame afterwards will detect the additional nibble, will ignore data in the frame and will increment the Forwarded CRC error counter. This will also cause an invalid Working Counter (WKC).

Application diagnostic registers

In order to coordinate master and slave operations, each network node works according to the EtherCAT State Machine, where each state enables a specific communication function.

Each state transition is requested by the master and acknowledged by the slave after the successful initialization of a specific set of parameters, both at data link and at the application level. When the initialization of one or more of these parameters fails, the slave does not acknowledge the state transition.

In case of an internal error the slave changes to a lower state. In both cases, the slave informs the master about the state machine behavior by setting an error indication bit and writing a corresponding error code into the Application Layer Status Code (AL Status Code) register. Master devices can monitor the error indication bit by means of cyclic commands and read the corresponding AL Status Code when an error indication is detected.

Example 3: SyncManager watchdog error

As a monitoring mechanism for process data SyncManagers, a corresponding watchdog can be activated. This watchdog is particularly important for the output of process data in order to guarantee a safe state for the output signal in case of communication loss with the master device. The watchdog is triggered every time a new write command from the master accesses the memory area corresponding to the output process data SyncManager. In case the master application does not provide new output process data within the configured watchdog time, the slave will go to ERROR-SAFEOP state with AL Status Code 0x001B “Sync Manager Watchdog” and the master device will be able to detect the unexpected transition and its cause.

Technology story by Alessandro Figini and Florian H�fele, EtherCAT Technology Group, Technology Support and Test.

www.ethercat.org