Diagnostics with EtherCAT - Part 2 | Automation.com

Diagnostics with EtherCAT - Part 2

Diagnostics with EtherCAT - Part 2

July 2014 - In a previous article, the Working Counter was described as a powerful mechanism for EtherCAT master devices to cyclic-synchronously monitor slave behavior. In addition to cyclic-synchronously monitoring, fieldbuses typically support further diagnostic mechanisms that allow master devices to precisely detect the location and cause of error conditions both at the hardware and at the application level of a slave.

Due to their specific characteristics, fieldbuses comply with a simplified 7-Layer ISO/OSI model where only Physical Layer, Data Link Layer and Application Layer are typically defined as follows (Fig. 1):

Physical Layer and Data Link Layer
With EtherCAT, these two levels take care of all the time-critical functions (such as frame routing, CRC evaluation, and memory access) and are implemented by a dedicated component called the 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.
 

Figure 1: Simplified ISO/OSI model for fieldbus systems

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 (Fig. 2).
 

Figure 2: Internal structure of the EtherCAT Slave Controller (ESC)


The ESC address space is logically split in two areas:
User memory (address ≥ 0x1000)
The user memory is used as dual-ported RAM to exchange application data between master and slave, both in the form of process data and 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)
This memory area has a standard structure which is used to configure, control, and monitor the slave behavior. Both the master and the local application can access this memory area directly.

The 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) (Table 1).
 

ESC DL Status Register (0x0110:0x0111)

Bit

Description

4

Physical Link Port 0

0 : No link detected

1 : Link detected

5

Physical Link Port 1

0 : No link detected

1 : Link detected

6

Physical Link Port 2

0 : No link detected

1 : Link detected

7

Physical Link Port 3

0 : No link detected

1 : Link detected

(Table 1)
 

Lost Link CounterRegister (0x0310:0x0313)

Bit

Description

7:0

Lost Link Counter Port 0

(counting stopped at 0xFF)

15:8

Lost Link Counter Port 1

(counting stopped at 0xFF)

23:16

Lost Link Counter Port 2

(counting stopped at 0xFF)

31:24

Lost Link Counter Port 3

(counting stopped at 0xFF)

(Table 2)

Link Lost Counters are incremented as a consequence of a physical medium interruption such as a faulty slave or broken cable. Link Lost Counters can be globally reset by the master device with write access to any of them. To delete errors which can occur during power-up, this step should be done before counter monitoring 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 also reports information about the loop status of each port (Table 3):
 

ESC DL Status Register (0x0110:0x0111)

Bit

Description

8

Loop Status Port 0

0 : port open

1 : port closed

10

Loop Status Port 1

0 : port open

1 : port closed

12

Loop Status Port 2

0 : port open

1 : port closed

14

Loop Status Port 3

0 : port open

1 : port closed

(Table 3)

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 into 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 (Fig. 3).

 
Figure 3: Network topology change detection and location

Besides forwarding frames, each open port of an EtherCAT Slave Controller performs CRC evaluation on incoming frames (Figure 4):

 
Figure 4: Each open port performs a 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 detecting 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 (Table 4).

 

RX Error CounterRegister (0x0300:0x0307)

Bit

Description

7:0

CRC Error Counter Port 0

(counting stopped at 0xFF)

15:8

Physical Interface Error Counter Port 0

(counting stopped at 0xFF)

23:16

CRC Error Counter Port 1

(counting stopped at 0xFF)

31:24

Physical Interface Error Counter Port 1

(counting stopped at 0xFF)

39:32

CRC Error Counter Port 2

(counting stopped at 0xFF)

47:40

Physical Interface Error Counter Port 2

(counting stopped at 0xFF)

55:48

CRC Error Counter Port 3

(counting stopped at 0xFF)

63:56

Physical Interface Error Counter Port 3

(counting stopped at 0xFF)

(Table 4)

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

 

Forwarded RX Error CounterRegisters (0x0308:0x030B)

Bit

Description

7:0

Forwarded CRC Error Counter Port 0

(counting stopped at 0xFF)

15:8

Forwarded CRC Error Counter Port 1

(counting stopped at 0xFF)

23:16

Forwarded CRC Error Counter Port 2

(counting stopped at 0xFF)

31:24

Forwarded CRC Error Counter Port 3

(counting stopped at 0xFF)

(Table 5)

In addition, CRC and Forwarded CRC error counters can be reset by the master device by a write access to any of them.

Example 2: EMC disturbances corrupting a frame
Strong environmental EMC disturbances can corrupt the bit sequence of frames travelling 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, ignore data in the frame, and increment the Forwarded CRC error counter. This will also cause an invalid Working Counter (WKC) (Fig. 5).
 

Figure 5: Counter increment following a CRC error detection in case all ESCs support both CRC Error Counters and Forwarded CRC Error Counters.

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 (Fig. 6/Fig. 7).

 
Figure 6: EtherCAT State Machine
 

Figure 7: Each state enables specific communication functions.

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.


 Figure 8: Example of successful (top) and unsuccessful (bottom) state transition

 
Figure 9: Some examples of possible standard AL error codes

Typical error conditions that affect state machine operation include incorrect configuration of the memory areas used for data exchange, loss of synchronization between master and slave, or application-specific slave internal failures.

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 output 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 coming 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 (Fig. 10).

 
Figure 10: SyncManager watchdog error reaction in a slave and its notification to the master device.

Back to top
Posted in:
Article
Related Portals:
EtherCAT, Industrial Networks

MORE ARTICLES

VIEW ALL

RELATED