Mastering EtherCAT Debugging in TwinCAT for Beginners

Stuck during the initial I/O check, with nothing working and no movement in sight? Are TwinCAT’s cryptic error messages and baffling ADS error codes leaving you scratching your head, with no clear indication of what’s gone wrong?

Don’t worry—you’re not alone! In this blog post, we’ll explore some practical tips and handy tools to help you troubleshoot and resolve these issues, getting your machine running smoothly in no time.

In this article, we will describe various tools and methods for troubleshooting EtherCAT networks with TwinCAT 3. Cyclical diagnostics using checksums and error counters, monitoring device states using the state machine, and visual error analysis in the topology view will be explained in detail. For particularly difficult cases, we show you the emergency scan, which can localize communication problems using targeted test frames. So let’s get started!

EtherCAT (Ethernet for Control Automation Technology) is a high-performance, real-time fieldbus system based on Ethernet, which is used for terminals and hardware modules from Beckhoff and third parties in the TwinCat environment. It is widely utilized in industrial automation for its speed, flexibility, and efficiency in communicating between controllers (like PLCs) and devices (such as sensors, actuators, and I/O modules).

Let’s dig a bit deeper and have a look on the EtherCat protocol:

Each datagram contains process data addressed to a specific participant of the bus. The EtherCAT master sends a frame checksum at the end of the frame, called FCS. Each participant checks whether one or more datagrams are directed to itself and processes them accordingly or ignores them. At the same time, each participant verifies the checksum of the complete frame. If the verification fails, the device informs all following nodes about the corruption of the frame and increments its own error counter (working counter). In this way, the master not only knows that the frame is damaged and that there is an error, but also, by evaluating the error counters of all nodes, which node caused the error.

In TwinCAT, each slave provides a working counter input WcState that can be linked and evaluated at application level (your PLC program).

Beckhoff already provides useful function blocks, e.g. FB_EcGetSlaveState or FB_EcGetAllSlaveStates, which do the evaluation for you. You can also use the online value to see if there are problems with a specific device.

You maybe already know that you can define Sync Units in your IO configuration. They are usually used to assign different EtherCAT bus cycle times to groups of slaves (e.g. drives need to be updated more often than normal IO terminals). Keep in mind that each Sync Unit has its own datagram from the Master. This means that a faulty working counter only indicates a corrupted datagram for its own Sync Unit while other Sync Units may still work correctly.

For proper diagnostics, it is also important to know that both master and slaves use an internal state machine to initialize communication between all participants.

A detailed description of the individual states and transitions can be found on the InfoSys page in the info box above. Ideally, all slaves are in the operational state (OP). You can see the state of all devices by clicking on your EtherCAT Master in TwinCAT and then selecting the ‚Online‘ tab.

If the state of a device is INIT NOCOMM, it means that the device is not reachable. The previous device in the topology has the state OP LNKMIS B, which indicates that this device is in operational state but has no connection to its subsequent node. If a device remains in PREOP or SAFEOP, it means that it is reachable, but the device has either a configuration or initialization error that needs to be fixed.

In addition, the power supply is listed for all devices. A negative current for a specific terminal indicates that the bus power supply is not sufficient. In this case you should check if there are any leaks or shortages at this terminal or if there is a general error in the power calculation.

The State of a device is also provided as an input (like the WcState). You can link it and evaluate it in your application if necessary, or use the online value to check it directly.

Most EtherCAT devices are installed only by ESI files (EtherCAT Slave Information). But sometimes you need to adjust a few more things both on the software and hardware side. For example, I was involved in a project to re-commission a machine that was working very well before, but at the customer site a complete branch of the bus was not communicating with the master. All the devices had a green status LED indicating that there was a connection to the bus. After searching the IO configuration in TwinCAT for a while, I realized that one of the field nodes was still in PREOP. But the problem was not in the software configuration. There are some devices that can be configured via DIL switches, such as the address switches on safety devices. In my case, someone accidentally moved one of the switches so that it no longer matched the configuration in TwinCAT.

A more visual overview of the condition of the bus is obtained with the topology view (EtherCAT Master → EtherCAT → Topology).

When you select the Online state, any faulty parts of the bus are immediately highlighted in red, making it easy to identify problematic devices. This is typically the first step to verify whether all participants are communicating with the master. Additionally, the overview helps to pinpoint the exact location to check electrical connections.

In this example all devices are green and in the OP state, but you can see immediately that there are CRC errors on some devices. By checking the devices, some loose bus connectors were found and fixed easily.

In some cases, it might to hard to detect an issue, e.g. when you are losing complete frames at some point of your network from time to time. If the frame does not return at all, there will not be any information about the link or the the current state of a device. Beckhoff provides a feature called Emergency Scan for those tricky situations, but it is only available in config mode.

You can find it at EtherCAT Master → EtherCAT → Advanced Settings.

The emergency scan sends a specified number of test frames (10, 100, or 1000) to each device individually. This process is repeated for all configured devices. The results display the number of complete frames returned by each participant, helping you pinpoint the exact location where frames might be lost.