Purpose of this document

EtherCAT Diagnostic This slide set intends to provide an overview over the diagnostic
 Diagnostic Features capabilities provided by EtherCAT.
Overview
 Cyclic Synchronous
Diagnostic
It contains a description of the basic diagnosis functionalities and the
 Hardware Diagnostic most typical error scenarios within an EtherCAT network.
 Software Diagnostic
 Diagnostic Procedure
It is primarily intended for end users, as well as for machine
Example builders and system integrators.
The knowledge of EtherCAT basics is taken for granted.
For additional information about EtherCAT diagnostics - including
more detailed error scenarios – which could be of interest for
EtherCAT master and slave manufacturers, please refer to slide set
“EtherCAT Diagnosis For Developers”.

For comments regarding the slides please contact info@[Link]

Nuremberg, November 2018,

EtherCAT Technology Group
November 2018 © EtherCAT Technology Group 1
Diagnostic Features
Overview
 EtherCAT functional principle

EtherCAT Diagnostic In an EtherCAT network, information is exchanged by means of Ethernet

 Diagnostic Features frames, each one consisting of one or more datagrams.
Overview
Regardless of the hardware topology (line, daisy-chain, star, …), frames
 Cyclic Synchronous
Diagnostic are always sent by the master, go through all slaves and return to the
 Hardware Diagnostic master after completing the „loop“.
 Software Diagnostic Data carried by frames are processed by slaves „on-the-fly“.
 Diagnostic Procedure
Example

November 2018 © EtherCAT Technology Group 3

 Network Error Types

EtherCAT Diagnostic Errors which can affect an EtherCAT (like any other fieldbus) network
 Diagnostic Features can be grouped in two categories:
Overview
 Cyclic Synchronous
Diagnostic 1. Hardware errors
 Hardware Diagnostic
 Software Diagnostic a. The physical medium is interrupted or the network topology is
 Diagnostic Procedure unexpectedly changed, and frames do not reach all the network
Example
slaves or do not return to the master at all (e.g. damaged
cables, loose contacts, slave reset during operation).

b. All slaves are reached by frames, but the correct bit sequence
is corrupted (e.g. EMC disturbances, faulty devices).

2. Software errors

a. The parameters sent by the master during the start-up phase

are wrong or do not match the slave expectations (e.g. wrong
process data size/configuration, unsupported cycle time).

b. A slave previously working error-free detects an error during

operation (e.g. synchronization loss, watchdog expiration).

November 2018 © EtherCAT Technology Group 4

 EtherCAT diagnostic information overview

EtherCAT Diagnostic EtherCAT provides extensive diagnostic information both at hardware

 Diagnostic Features and at software level. For the sake of simplicity, this diagnostic
Overview
information can be classified according to the following scheme:
 Cyclic Synchronous
Diagnostic
 Hardware Diagnostic
 Software Diagnostic
 Diagnostic Procedure Cyclic Diagnostics
Cyclic

Example

• Lost Frame Counters

• Working Counter

Hardware Diagnostics Software Diagnostics

Acyclic

• Lost Link Counters • State Machine Errors

• RX Error Counters • Diagnostic History Object

Hardware Software

November 2018 © EtherCAT Technology Group 5

Cyclic Diagnostic
 Working Counter

EtherCAT Diagnostic
 Diagnostic Features
Overview
 Cyclic Synchronous
Diagnostic
 Hardware Diagnostic
 Software Diagnostic
 Diagnostic Procedure
Example

Each datagram in an EtherCAT frame ends with a 16-bit Working

Counter (WKC), which is incremented by each slave addressed by the
datagram itself. In case a datagram returns to the master with an invalid
(= unexpected) WKC, the input data carried by that datagram are
discarded by the master.

Master devices can optionally inform the control

application (PLC, NC, …) about the Working
Counter state (at least for datagrams carrying
cyclic process data) by means of some cyclic
variable in the network process image.

November 2018 © EtherCAT Technology Group 7

 Working Counter – Example 1

EtherCAT Diagnostic All addressed slaves (Digital Inputs, in the example below) successfully
 Diagnostic Features process the datagram.
Overview
 Cyclic Synchronous
Diagnostic WKC value returning to the master = expected value → WKC valid
 Hardware Diagnostic
 input data in the datagram forwarded by the master to the control
 Software Diagnostic
application (PLC, NC, …)
 Diagnostic Procedure
Example

November 2018 © EtherCAT Technology Group 8

 Working Counter – Example 2

EtherCAT Diagnostic One addressed slave (Digital Input, in the example below) fails to process
 Diagnostic Features the datagram.
Overview
 Cyclic Synchronous
Diagnostic WKC value returning to the master ≠ expected value → WKC invalid
 Hardware Diagnostic
 input data in the datagram are discarded by the master (PLC/NC
 Software Diagnostic
uses old data)
 Diagnostic Procedure
Example

November 2018 © EtherCAT Technology Group 9

 Working Counter Summary

EtherCAT Diagnostic The Working Counter is always received by the master together with the
 Diagnostic Features corresponding datagram, and enables therefore an immediate reaction in
Overview case of invalid or inconsistent data.
 Cyclic Synchronous
Diagnostic The information concerning the Working Counter is basically a digital
 Hardware Diagnostic
information (“WKC correct” vs. “WKC invalid”), and therefore does not
 Software Diagnostic
distinguish among different error causes. An invalid WKC can result from
 Diagnostic Procedure
Example several different situations:
- One or more slaves are not physically connected to the network, or
they are not reached by the frames.
- One or more slaves have been reset
- One or more slaves are not in Operational state
Whenever Working Counter errors occur, the problem should be
investigated deeper by means of further Hardware Diagnostic and
Software Diagnostic functionalities.

November 2018 © EtherCAT Technology Group 10

 Sync Units

EtherCAT Diagnostic Masters can optionally enable to group network slaves into disjoint
 Diagnostic Features subsets called Sync Units. Slaves belonging to different Sync Units are
Overview served by separate datagrams, and therefore are also independent from
 Cyclic Synchronous the point of view of the Working Counter diagnostics.
Diagnostic
 Hardware Diagnostic
- One (default) Sync Unit: if one drive fails incrementing the WKC, the
 Software Diagnostic
input data of all three drives are discarded by the master:
 Diagnostic Procedure
Example

- Separate Sync Units: if one drive fails incrementing the WKC, only the
input data of that slave are discarded:

November 2018 © EtherCAT Technology Group 11

Hardware Diagnostic
 Hardware Diagnostic

EtherCAT Diagnostic The basic diagnostic information at hardware level consists of error
 Diagnostic Features counters provided by slave devices at standard memory addresses.
Overview
 Cyclic Synchronous
Diagnostic
 Hardware Diagnostic
 Software Diagnostic
 Diagnostic Procedure
Example

These memory addresses can be accessed by the master device and be

provided to the control application (for example by means of dedicated
variables, or via function blocks in the PLC program).
November 2018 © EtherCAT Technology Group 13
 Master Lost Frames Counter

EtherCAT Diagnostic A frame shall be considered as „lost“ by the master either if it does not
 Diagnostic Features return to the master at all (a), or it is corrupted and therefore the
Overview information contained in it is meaningless (b).
 Cyclic Synchronous
Diagnostic Both situations can be monitored by the master by checking suitable
 Hardware Diagnostic fields of the incoming frames, and reported to the user by means of a
 Software Diagnostic corresponding Lost Frame Counter.
 Diagnostic Procedure
Example

The master Lost Frame Counter can be considered as the first indicator
of communication issues at hardware level in an EtherCAT network:
an increment should trigger a deeper investigation by reading and
interpreting Hardware Error Counters of slave devices.
November 2018 © EtherCAT Technology Group 14
 Hardware Error Counters

EtherCAT Diagnostic • Lost Link Counters (optional): incremented when physical link is
 Diagnostic Features interrupted
Overview
 Cyclic Synchronous Register Length Meaning
Diagnostic
0x0310 1 byte Lost Link Counter port 0
 Hardware Diagnostic
 Software Diagnostic 0x0311 1 byte Lost Link Counter port 1
 Diagnostic Procedure 0x0312 1 byte Lost Link Counter port 2
Example
0x0313 1 byte Lost Link Counter port 3

• RX Error Counters (mandatory): incremented in case of signaling

error:

Register Length Meaning

0x0300 1 byte Frame Error Counter port 0
Rx Error Counter port 0
0x0301 1 byte Physical Layer Error Counter port 0
0x0302 1 byte Frame Error Counter port 1
Rx Error Counter port 1
0x0303 1 byte Physical Layer Error Counter port 1
0x0304 1 byte Frame Error Counter port 2
Rx Error Counter port 2
0x0305 1 byte Physical Layer Error Counter port 2
0x0306 1 byte Frame Error Counter port 3
Rx Error Counter port 3
0x0307 1 byte Physical Layer Error Counter port 3

November 2018 © EtherCAT Technology Group 15

 Link/Activity LEDs

EtherCAT Diagnostic EtherCAT slave devices mandatorily support a Link/Activity LED for each
 Diagnostic Features port with removable connector.
Overview
 Cyclic Synchronous
Diagnostic Before checking Link Lost Counters (or for slaves which do not support
 Hardware Diagnostic Link Lost Counters at all), a visual inspection of Link/Activity LEDs can
 Software Diagnostic therefore easily enable to detect permanent interruptions of the physical
 Diagnostic Procedure
Example
link: in this case, the LED will be permanently off.

No Link!

November 2018 © EtherCAT Technology Group 16

 Lost Link Counters

EtherCAT Diagnostic An increment in a Lost Link Counter indicates an interruption in the

 Diagnostic Features hardware communication channel – during link down frames are not send
Overview to the neighboring device:
 Cyclic Synchronous
Diagnostic
 Hardware Diagnostic
 Software Diagnostic
 Diagnostic Procedure
Example

Lost Link Counter: +1

Most likely reasons for link loss are:

• Temporary or permanent device power-supply loss, or device reset.
• Damaged cables or connectors or poor/oxidized contacts
• EMC disturbances

November 2018 © EtherCAT Technology Group 17

 Hardware Coding of Information

EtherCAT Diagnostic In order to be transmitted on a physical medium, digital information needs

 Diagnostic Features to be encoded (on transmitter side) and decoded (on receiver side) into
Overview specific current/voltage „symbols“.
 Cyclic Synchronous
Diagnostic
 Hardware Diagnostic
 Software Diagnostic
 Diagnostic Procedure
Example

Coding results are dependent from the state of the link:

• The hardware coding defines valid and invalid symbols.
• Symbols are transmitted on the physical medium both within and
outside frames (in order to enable the receiver to detect link losses).

November 2018 © EtherCAT Technology Group 18

 RX Error Counters

EtherCAT Diagnostic A change of RX Error Counters indicates that the hardware signal
 Diagnostic Features received was corrupted and that the carried data will be discarded:
Overview
 Cyclic Synchronous
Diagnostic
 Hardware Diagnostic
 Software Diagnostic
 Diagnostic Procedure
Example

RX Error Counter: +1

Most likely reasons for signal corruption are:

• External EMC disturbances (usually sporadic counter increment)
• Damaged devices or interconnections (usually fast and systematic
counter increment)

November 2018 © EtherCAT Technology Group 19

 Physical Layer and Frame Errors

EtherCAT Diagnostic Invalid Frame Counters report the following compound information:
 Diagnostic Features
Overview  Physical Layer Errors (counted by Physical Layer Error Counters):
 Cyclic Synchronous
Diagnostic • Correspond to individual invalid symbols
 Hardware Diagnostic • Can occur both within and outside frames (when occurring within
 Software Diagnostic
frames, they represent usually also Frame Errors)
 Diagnostic Procedure
Example
 Frame Errors (counted by Frame Error Counters):
• Correspond to frames whose overall bit sequence was corrupted
• Can occur only within frames

The difference between the two error types can be explained taking a
written language as comparison:

November 2018 © EtherCAT Technology Group 20

 Frame Error Detection

EtherCAT Diagnostic In particular, Frame Errors are checked by each slave port (which in case
 Diagnostic Features increments the corresponding Frame Error Counter) when frames reach
Overview the port from the outside (x).
 Cyclic Synchronous
Diagnostic
 Hardware Diagnostic
 Software Diagnostic
 Diagnostic Procedure
Example

November 2018 © EtherCAT Technology Group 21

 Comments on Hardware Errors

EtherCAT Diagnostic Some additional comments about hardware errors:

 Diagnostic Features
Overview • Physical Layer Errors (and occasionally also Frame Frame) can be
 Cyclic Synchronous detected by a device immediately after the device itself was powered-
Diagnostic
 Hardware Diagnostic
on, or immediately after a neighbouring device was powered-off. Only
 Software Diagnostic
hardware errors occurring during operation should be considered as a
 Diagnostic Procedure actual or potential problem, and investigated.
Example

• No communication interface is totally error-free. Typically

communication interfaces ensure a Bit Error Rate of 10-12 (one
corrupted bit every thousand billion bits transmitted), which would
mean a sporadic change of hardware error counters (in a timeframe of
days or weeks) even if no critical situation is present. Only burst or
often occurring (in a timeframe of seconds or minutes) hardware errors
should be considered as a actual or potential problem, and
investigated.

• Errors occurring outside frames, when occurring often and during

operation, are also a symptom of hardware problems. Yet, the main
attention should be focused on the Frame Errors as these indicate a
corruption of the frame content and therefore of the information itself.
Frame Error Counters should be interpreted in the following way.
November 2018 © EtherCAT Technology Group 22
 Diagnostic Procedure

EtherCAT Diagnostic 1. Follow the frame path through the network and determine in which
 Diagnostic Features sequence the CRC check is performed (according to Frame Error
Overview
 Cyclic Synchronous
detection by each port).
Diagnostic
 Hardware Diagnostic
 Software Diagnostic
 Diagnostic Procedure
Example

November 2018 © EtherCAT Technology Group 23

 Diagnostic Procedure

EtherCAT Diagnostic 2. Detect the first port reporting a Frame Error Counter ≠ 0 according to
 Diagnostic Features this sequence:
Overview
 Cyclic Synchronous
Diagnostic
 Hardware Diagnostic
 Software Diagnostic
 Diagnostic Procedure
Example

First port reporting Frame Error Counter ≠ 0 → most likely problem location.
November 2018 © EtherCAT Technology Group 24
 Hardware Diagnostic Procedure

EtherCAT Diagnostic 3. Check the following hardware aspects:

 Diagnostic Features
Overview • Check cable between detected and previous slave:
 Cyclic Synchronous - EtherCAT cable is routed near to power cables or noise sources
Diagnostic
 Hardware Diagnostic
- Self-made cable connectors have been badly implemented
 Software Diagnostic - Cable is not properly shielded
 Diagnostic Procedure
Example • Check detected and previous device:
- Not suitable power-supply (for example, low LVDS current)
- Devices don´t share the same ground potential

• Try to replace/swap devices at two ends of the detected location,

in order to check if errors are related to a specific device part.

As external EMC disturbances are asynchronous with the communication,

both Pgysical Layer and Frame Errors should be counted in this case
(even if their ratio can vary). Completely unbalanced counter values
(many Physical Layer Errors with no Frame Errors, or many Frame Errors
with no Physical Layer Errors) could instead indicate an internal device
issue: replace the devices could be therefore the first suggested step in
this case.

November 2018 © EtherCAT Technology Group 25

 Installation Guideline

EtherCAT Diagnostic A careful planning and implementation of the network infrastructure is the
 Diagnostic Features first and most important requisite in order to obtain a stable and error-free
Overview transmission.
 Cyclic Synchronous
Diagnostic
 Hardware Diagnostic
For this purpose, the ETG.1600 “EtherCAT Installation Guidelines” is
 Software Diagnostic
available for download (not only for ETG members!) on the ETG website:
 Diagnostic Procedure
Example

November 2018 © EtherCAT Technology Group 26

Software Diagnostic
 EtherCAT State Machine

EtherCAT Diagnostic The operation of every EtherCAT slave device is governed by the
 Diagnostic Features EtherCAT state machine.
Overview
Init: neither acyclic (Mailbox)
 Cyclic Synchronous
Diagnostic nor cyclic (Process Data)
communication is possible
 Hardware Diagnostic
PreOP: acyclic, but not cyclic
 Software Diagnostic
data exchange is possible
 Diagnostic Procedure
Example SafeOP: both acyclic and
cyclic data exchange are
possible, yet cyclic outputs
remain in a predefined state.
OP: both acyclic and cyclic
exchange possible without
limitations.
Boot: optional state for
firmware update, only file
transfer over Mailbox
enabled.

• Each slave reports its current state, as well as the flag of an error
condition in the state machine, in AL Status register 0x0130.
• The master requests a new state to a slave by writing AL Control
register 0x0120 of the slave itself. Spontaneous (backward) transitions
can be performed by a slave without master request only in case an
error in the state machine occurs.
November 2018 © EtherCAT Technology Group 28
 Run LED

EtherCAT Diagnostic The EtherCAT state machine provides the basic diagnostic information at
 Diagnostic Features software level.
Overview
 Cyclic Synchronous Slaves with removable connectors support a Run LED indicator reporting
Diagnostic
the current state of the slave device in the state machine:
 Hardware Diagnostic
 Software Diagnostic
 Diagnostic Procedure
Example
- Init: off
- PreOP: blinking slowly
- SafeOP: single flash with longer pause
- OP: on
- Boot: flickering fast or off

Each slave leaving OP state during operation without an explicit request

from the controller should require a diagnostic investigation.

November 2018 © EtherCAT Technology Group 29

 Error/Status LED and AL Status Code

EtherCAT Diagnostic Slaves with removable connectors can optionally support an Error LED
 Diagnostic Features indicator reporting the main State Machine error categories:
Overview
 Cyclic Synchronous
Diagnostic
- No error: off
 Hardware Diagnostic
- Blinking: configuration error
 Software Diagnostic
- Single Flash: generic runtime error
 Diagnostic Procedure
Example
- Double Flash: process data watchdog expired
- …

Run and Error LEDs can also be combined in a two-coloured Status LED:

Whenever a slave cannot be in the last state requested by the master, an

error is reported in AL Status register and a corresponding error code is
written in AL Status Code register 0x0134. The AL Status Code can be
read by the master and reports the diagnostic information provided by the
state machine, completing the visual information provided by the
Error/Status LED (if one of these LEDs is supported).
November 2018 © EtherCAT Technology Group 30
 AL Status Code

EtherCAT Diagnostic State Machine errors (and corresponding AL Status Codes) can be
 Diagnostic Features grouped into the following two categories:
Overview
 Cyclic Synchronous • Initialization errors (slave does not reach OP state during start-up):
Diagnostic
 Hardware Diagnostic
the master requests a state transition, but the slave refuses it because
 Software Diagnostic one or more necessary conditions to enter the new state are not
 Diagnostic Procedure satisfied.
Example
Typical initialization errors:

- 0x0003 : Invalid Device Setup

- 0x001D : Invalid Output Configuration
- 0x001E : Invalid Input Configuration
- 0x0035 : Invalid Sync Cycle Time

• Runtime errors (slave autonomously steps back from OP to a lower

state): the slave detects an error during operation and spontaneously
performs a backward-transition without master request.
Typical runtime errors:

- 0x001A : Synchronization error

- 0x001B : Sync manager watchdog
- 0x002C : Fatal SYNC error
November 2018 © EtherCAT Technology Group 31
 AL Status Code – Initialization Errors

EtherCAT Diagnostic The information needed by the master to properly configure a slave is
 Diagnostic Features derived from the ESI file (typical) or from the slave EEPROM content.
Overview
 Cyclic Synchronous If a slave does not reach the OP state during start-up:
Diagnostic
 Hardware Diagnostic
 Software Diagnostic
1. Check if slave default settings were changed, and in case delete and
 Diagnostic Procedure append/scan the slave again (default settings will be restored).
Example

2. (In case network configuration is based on ESI) Check if the ESI file
containing the slave description is correctly provided to the master
configuration tool.

3. (In case of modular slaves) Check if the configured module list

corresponds to the physically connected hardware modules.

4. (In case of DC-Synchronous devices) Check if the master jitter could

prevent from a proper slave synchronization.

November 2018 © EtherCAT Technology Group 32

 AL Status Code – Runtime Errors

EtherCAT Diagnostic Once a slave reached OP state successfully, it should never leave this
 Diagnostic Features state without an explicit master request.
Overview
 Cyclic Synchronous If a slave suddenly leaves the OP state:
Diagnostic
 Hardware Diagnostic
 Software Diagnostic
1. Check if hardware errors (like link loss or frame corruption - see
 Diagnostic Procedure hardware diagnostic features) occur, as such errors could indirectly
Example cause a watchdog reaction or a loss of synchronization.

2. (In case of process data watchdog errors) Check if the master

application (PLC, NC, …) is running.

3. (In case of synchronization errors) Check if the master jitter

performances could justify a synchronization loss (synchronization
errors can easily occur if maximum jitter > 20÷30% of the
communication cycle time).

November 2018 © EtherCAT Technology Group 33

 Diagnosis History Object

EtherCAT Diagnostic In order to report application-specific errors, slave devices can optionally
 Diagnostic Features support CoE Diagnosis History Object 0x10F3, which can be read by the
Overview master via standard SDO services.
 Cyclic Synchronous
Diagnostic
 Hardware Diagnostic
Configuration tools can support a graphical interface for the Diagnosis
 Software Diagnostic
History Object:
 Diagnostic Procedure
Example

November 2018 © EtherCAT Technology Group 34

 Diagnostic Steps
on Machine or Plant
 Diagnostic Steps on Machine or Plant

EtherCAT Diagnostic Sometimes diagnostic registers are not directly accessible to machine
 Diagnostic Features operators, therefore the suggested steps for hardware and software
Overview diagnostics cannot be immediately applied: in this case, some preliminary
 Cyclic Synchronous
Diagnostic
steps can help to locate, and often solve the problem (especially if this is at
 Hardware Diagnostic hardware level).
 Software Diagnostic
If these steps do not help to troubleshoot the issue, deeper Hardware
 Diagnostic Procedure
Example and/or Software Diagnostic should be performed with the help of the
operating interface (if diagnostic information is available) or of the machine
builder.
Whenever communication issues on the EtherCAT network occur:

Check Failed when… If failed…

1 Check Link/Activity LEDs of slave LED is stable OFF Check that devices at both ends of the link are on
ports connected to the network for
each link
Check that cable connectors are properly inserted

Check that cable is not mechanically interrupted or

damaged along its path

Check pin-to-pin continuity between end connectors for

each wire by means of a tester

Try to replace the cable.

November 2018 © EtherCAT Technology Group 36

 Diagnostic Steps on Machine or Plant

EtherCAT Diagnostic Check Failed when… If failed…

 Diagnostic Features
Overview 2 Check time elapsed between cable Delay > 6÷7 seconds Check that devices at both link ends are grounded to
insertion (or device power-on) and the same potential
 Cyclic Synchronous Link/Activity LED goes ON (or
Diagnostic flickering) for each link Check that connectors have been properly
manufactured (only in case of self-assembled cables)
 Hardware Diagnostic
Check maximum cable length according to cable
 Software Diagnostic section (should be ≤ 100 m for AWG 22, cables with
smaller sections like AWG 24 or 26 have more strict
 Diagnostic Procedure limitations)
Example
Check end-to-end cable resistance (should be ≤ 57,5
Ω/km for AWG 22 cables)

3 Check Run LED for each slave LED is not stable ON Check that Link/Activity LED is flickering (confirming
device that data are received by slave)

Check blinking code shown by Error/Status LED (if

supported)

Check slave-specific diagnostic information (if

supported)

4 In all cases when the available information enables to identify a Check cables like at points 1 and 2, starting from the
precise location in the network where communication issues network segment(s) affected by the issue.
start to appear (only one part of the machine stops working, the
operator interface reports errors coming from a precise subset Replace cables, starting from the network segment(s)
of slaves, …) affected by the issue.

One at a time, replace the devices at two ends of

segment(s) affected by the issue.

5 In the case when communication issues affect the whole Check cable between master and first slave like at
network points 1 and 2.

Restart the master

Replace the master

November 2018 © EtherCAT Technology Group 37

 EtherCAT Diagnostics

EtherCAT Diagnostic Please visit

 Diagnostic Features
Overview [Link]
 Cyclic Synchronous
Diagnostic
for more information
 Hardware Diagnostic
 Software Diagnostic
 Diagnostic Procedure
Example

EtherCAT Technology Group

ETG Headquarters
Ostendstr. 196
90482 Nuremberg, Germany
Phone: +49 911 54056 20
info@[Link]
November 2018 © EtherCAT Technology Group 38