Software unlocks EtherCAT Ethernet protocol diagnostics
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, released in 2003, can support 65,535 devices in real time on one 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 will provide a master-based software so all network users can use this data. 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 slave or EtherCAT slave controller (ESC) hardware. 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 approved 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 DS402 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 is already very good at locating errors with precision such as including loose connectors, incorrect cabling order, damaged cables, unintended effects on slaves, EMC interference and bit errors, among others.
The new diagnostic interface will not change this existing capacity, but will instead 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 will also maintain a minimal file size 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 runs in the background and 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 read and/or write commands for each WKC. 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. Physical layer errors are different from CRC errors, and the ratio of the errors is important in diagnosing intermittent errors from noise.
- State machine errors: This occurs when an EtherCAT slave’s internal state differs from the state commanded by the master.
- Product vision 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 link lost counters.
Without the ETG.1510 specification, masters that were not equipped to gather this information would require entirely new code. However, the specification also will enhance masters that could access the data by automatically locating it on the master. 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, email@example.com.
The benefits of the ETG.1510 specification
The range of diagnostics with ETG.1510
How will you benefit from the new data/diagnostics due to the new specification?