New: ETG.1510 “Profile for Master Diagnosis Interface”
Diagnostic capabilities are one of the key features in determining the success of a fieldbus technology. To further improve diagnostics in EtherCAT networks, the EtherCAT Technology Group (ETG) has defined a vendor independent diagnostic interface with the specification ETG.1510 “Profile for Master Diagnosis Interface”. This enables EtherCAT masters to provide detailed network diagnostic information and health status to third party tools in a user friendly and standard way.
In modern industry machine and plant availability represent one of the most important factors in order to guarantee efficiency and competitiveness, and EtherCAT enables this by means of a well proven technology relying on a robust communication infrastructure. Yet, industrial environments can be challenging even for reliable communication technologies such as EtherCAT: constantly moving parts or continuous vibrations could cause temporary link losses or even cable breaks in the long term, while EMC disturbances could falsify signals travelling on the communication path. In all these cases, the diagnostic capabilities of the fieldbus represent the key element in order to detect errors, determine its location and possible causes, and reduce thereby the machine downtime as much as possible.
In terms of diagnostic capabilities, EtherCAT supports outstanding features that go far beyond the corresponding capabilities of traditional Ethernet. The necessary information is either provided by the EtherCAT communication chips (ESCs) directly in hardware or by software functionalities. Therefore, no specific extensions are required on slave side. Each EtherCAT datagram ends with a 16-bit Working Counter field, which is expected to be incremented by all slave devices addressed by the datagram itself. A mismatch between the expected and the received value of the Working Counter means that not all slave devices successfully processed the datagram and that they are therefore not working with consistent data in the current cycle. This can trigger an immediate error reaction on control (master) side: by default, input data carried by the datagram is discarded in this case. Additional information can be acyclically retrieved by the master and enables to investigate the location as well as possible causes of the communication issue. At hardware level, each EtherCAT Slave Controller monitors and detects link loss as well as signal corruption on each port and increments in case the corresponding lost link counter or RX error counter, respectively. Communication errors at software level, like the expiration of the watchdog on the cyclic data or a loss of synchronization within the network, can instead determine an unexpected state transition in the EtherCAT State Machine. They are displayed by means of the AL Status Code value, which is returned by the software stack whenever the unexpected state transition occurs.
All the necessary diagnostic information to monitor the network state as well as to detect and locate errors is therefore available to the master in all EtherCAT networks. Yet, this “raw” information needs to be provided to diagnostic tools and to end users in order to be interpreted and used. With the ETG.1510 specification “Profile for Master Diagnosis Interface”, the ETG has defined a solution enabling external tools to access the diagnostic information provided by EtherCAT networks in a way that is independent from the specific master vendor and software implementation. The ETG.1510 enhances the ETG.1500 “EtherCAT Master Classes” specification. The diagnostic information is mapped into the EtherCAT Master Object Dictionary defined in the ETG.5001, which is extended for this purpose. In particular, objects in index range 0x8000 describe the network structure as expected by the master based on the “offline” configuration, while objects 0x9nnn report the current network topology as detected by an online scan. The diagnostic information itself is mapped in index range 0xAnnn in the form of consistent, cumulative counters summarizing the network state from its start up to the present. Thanks to this, the diagnostic interface can be accessed with a frequency which is independent from the cycle time of the EtherCAT network, and no real time performances are required to external tools.
The access to the diagnostic information takes place via the well established CAN application protocol over EtherCAT (CoE). The CoE services are routed to and from the Master Object Dictionary in the controller through the standard Mailbox Gateway functionality, which is described in the ETG.8400 specification. Being based on already existing and fully standard protocols and functionalities, the diagnostic interface can be easily implemented as lean software extension on top of any standard master implementation. The amount of resources required by such a software extension is very small, what makes the implementation of the diagnostic interface feasible for all master solutions including simple and compact embedded systems. Thanks to the EtherCAT diagnosis interface – introduced with the ETG.1510 specification – providers of machine and network diagnostic tools can use a general purpose, universal interface for collecting diagnostic data from EtherCAT networks. They are able to report this information to technicians and engineers in a user friendly, graphically intuitive way, without the need to change their behavior according to the specific master manufacturer or to use a vendor proprietary access protocol for each different master implementation.