Software unlocks EtherCAT diagnostics

Through a vendor-independent diagnosis interface, an EtherCAT master can provide detailed slave diagnostic information and network health status via human-machine interfaces (HMIs) or third-party tools.

By Robert Trask, PE January 12, 2019

Specification of a vendor-independent diagnosis interface for the EtherCAT Ethernet protocol was among the announcements the EtherCAT Technology Group (ETG) made at SPS IPC Drives 2018. This interface will help EtherCAT vendors gather and analyze data to determine internal or external issues affecting components throughout an EtherCAT network. This specification, known as ETG.1510, “Profile for Master Diagnosis Interface,” will provide an accessible upgrade to allow easy access to the network’s health status.

EtherCAT protocol, released in 2003 and managed by ETG, can support 65,535 devices in real time on one industrial Ethernet network. It also has a range of cyclic and acyclic diagnostic information for rapid reactions to errors and in-depth analysis for intermittent issues.

The interface provides access to the network diagnostic data in a master-independent way. As a result, plants can expect to improve machine performance and increase uptime through the diagnostic interface without having to implement any changes to the EtherCAT slave. To understand the value of a diagnostic interface, it is important to know what kinds of built-in diagnostics EtherCAT offers.

New diagnosis interface plan

More than 200 EtherCAT masters range from traditional programmable logic controllers (PLCs) to PC-based software. Many call the diagnostic information quite easily, but not all. One consideration is EtherCAT network diagnostics are found in three locations: the slave registers, the CAN protocol over EtherCAT (CoE) and in the cyclic process data with the working counter (WKC) concept.

The issue is not the amount of network data available; EtherCAT already can locate errors.

The new diagnostic interface will not change this existing capacity, but instead will act like a dragnet, integrating all information. The interface will gather errors created by hardware and software to assess the network’s health status. It also will require minimal resources so it can be used on any EtherCAT controller—even compact embedded devices with limited memory.

The diagnostic interface’s access mechanism will provide diagnostic information from the EtherCAT slaves based on the existing EtherCAT master object dictionary and mailbox gateway functionality.

The interface enables the master to cast a wide net to pull in all of the diagnostic data stored in the subordinate devices. The vendor-independent design will also allow any master implementation to use third-party analysis tools in conjunction with ETG.1510.

Different network diagnostic variants

With the interface in place, engineers will have access to a range of diagnostics. These rely heavily on the WKC, which is a 16-bit field at the end of each datagram. The EtherCAT slaves increment the WKC of each read and/or write command. The master then compares the datagram against the expected value, discarding any bad frames and forwarding all good frames to the control application.

Other variants of EtherCAT network diagnostics reported by the interface include:

  • Lost link errors: When a component that is physically attached to a slave disappears, the slave signifies internally that it has lost a physical connection to the next slave.
  • Invalid frame errors (CRC): Each frame is mathematically checked and bad frames are counted and discarded.
  • Physical layer errors: Similarly, this detects frame corruption and increments a counter.
  • State machine errors: This occurs when an EtherCAT slave’s internal state differs from the state commanded by the master.
  • Product revision serial number errors: These often happen when the network topology does not match with the one expected by the master or when slave devices were connected in an incorrect order.

These mechanisms add analysis and comparison capabilities, such as examining invalid frame against lost link counters and vice versa, for cyclic and acyclic diagnostics. While cyclic synchronous diagnosis for hardware and software relies on WKCs, acyclic hardware diagnosis involves link lost counters and invalid frame counters. Acyclic software diagnosis also involves state machine errors. EtherCAT slaves incorporate all diagnostic mechanisms at the chip level, and as a result, they will remain available on legacy and future components.

Masters, network architectures

The diagnostic interface unlocks a wealth of EtherCAT topology information, providing significant advantages for end users, vendors of master components, and diagnostic tool suppliers. With this data, engineers will be able to conduct rapid troubleshooting and pinpoint where errors occurred. For example, a slave that might have seemed to operate without issue could require service, repair, or replacement because it is storing 400 RX error counters. [RX errors are malformed frames from a switchport.]

Without the ETG.1510 specification, masters that were not equipped to gather this information would require extensions. However, the specification also will enhance masters that already provided diagnostic information, yet in manufacturer-specific format. It also will make it easier to access data with third-party diagnostic tools and HMIs. In general, the software interface will benefit all EtherCAT system architectures and master implementations.

Robert Trask, PE, North American representative, EtherCAT Technology Group. Edited by Emily Guenther, associate content manager, Control Engineering, CFE Media, eguenther@cfemedia.com.

MORE ANSWERS

KEYWORDS: EtherCAT

The benefits of the ETG.1510 specification

The range of diagnostics with ETG.1510

Consider this

How will you benefit from the new data/diagnostics due to the new specification?


Author Bio: Robert B. Trask, P.E. is the North American Representative for the EtherCAT Technology Group.