EtherCAT Network Diagnosis and Error Detection

Introduction

EtherCAT networks are the backbone of modern industrial automation — delivering deterministic, high-speed communication between controllers and field devices. But what happens when something goes wrong? A disconnected cable, a swapped cable, a misconfigured SubDevice, a SubDevice firmware crash, an intermittent frame loss — these are everyday realities for engineers deploying and maintaining EtherCAT systems.

This article walks through the most common EtherCAT network errors, how the acontis EC-Master stack detects and reports them, and how tools like EC-Engineer help you pinpoint root causes quickly. Based on the acontis AT3014 test case suite, we cover real error scenarios with actual log output so you know exactly what to look for.

Test System Architecture

Before diving into error categories, it helps to understand how the diagnostic components fit together. The EC-Master stack runs alongside the real-time application and exposes a RAS server. EC-Engineer connects as a RAS client over TCP/IP — no project files are needed, just an IP address — and can display the full topology, states, process data, and error counters in real time.

Three test networks are used throughout these scenarios:

• Network 1: Beckhoff EK1100 bus couplers with EL2004, EL4132, and EL1004 terminals — a typical I/O configuration with two branches.
• Network 2: Three Bosch Rexroth ctrlX DRIVE XCS servo drives in a daisy-chain — representing a multi-axis motion control scenario.
• Network 3: Network 1 extended with an "EC-Training Disturber" — a acontis SubDevice on an Infineon XMC4800 board that can simulate firmware crashes, frame dropping, and unexpected state changes on demand.

acontis SubDevice EC-Training Disturber

Certain error conditions cannot be replicated at all—or only with great difficulty—using standard SubDevices. For this reason, acontis has developed special firmware for the Infineon XMC4800 Relax Kit to make it easy to trigger these errors. The corresponding function is selected using Button 1 and activated using Button 2.

The following functions are implemented:

• Function Code 1 — Create an unexpected SubDevice state
• Function Code 2 — No frames returned at all
• Function Code 3 — Firmware crash which leads to a PDI watchdog error
• Function Code 4 — Some frames are lost to simulate a bad cable or connector

The three categories of EtherCAT errors

Every error an EtherCAT MainDevice encounters falls into one of three categories, depending on when it occurs and how persistent it is.

Category 1 — Permanent errors during network startup. These prevent the network from reaching Operational state at all. The ENI configuration file might be missing, the physical cabling might not match the planned topology, or a SubDevice rejects its initialization commands. You'll see these immediately when launching your application.

Category 2 — Permanent errors while the network is operational. The network was running fine, and then something broke: a cable was pulled, a SubDevice lost power, or a device's firmware crashed. These errors require intervention — the problem won't resolve on its own.

Category 3 — Intermittent errors during operation. The network is still running, but not perfectly. Some frames are being lost, or Working Counter (WKC) mismatches are appearing in cyclic process data. These are often the hardest to diagnose because they may be transient and hardware-related.

Category 1: Startup Errors — When the Network Won't Come Up

ID 100: Missing ENI Configuration

The simplest failure: the EtherCAT Network Information file isn't where the application expects it. EC-Master reports Configuration not found (0x98110070) and the demo application exits immediately.

ID 101: Topology Mismatch

The ENI file expects five SubDevices but only three are physically connected — for example, because the cable between SubDevice 1001 and SubDevice 1004 was removed. EC-Master scans the bus, compares what it finds against the configuration, and reports the specific mismatch location.

ID 102: Swapped SubDevices

A subtler problem — all five SubDevices are present, but one has been physically relocated to a different position in the chain. The SubDevice count matches, but the topology is wrong. EC-Master detects an unexpected device type at a particular position.

EC-Engineer's Network Mismatch Analyzer (accessible via Network → Network Mismatch Analyzer) presents a side-by-side comparison of configured vs. found devices, highlighting mismatches in red.

ID 103: IN/OUT Port Swap — A Dangerous Cabling Error

This scenario is particularly relevant for servo drives. On the Bosch Rexroth ctrlX DRIVE, the EtherCAT IN connector is at the bottom of the unit. If someone swaps the IN and OUT cables at a drive, the third axis may appear as the second axis — silently reversing the Y and Z axes of a machine. This can cause serious physical damage.

EC-Engineer's Line Crossed Analyzer visually marks the incorrectly connected SubDevice in red, making the problem immediately obvious.

ID 105–106: SubDevice Initialization Failures

When a SubDevice's Sync Manager configuration or PDO mapping doesn't match what its firmware expects, it will reject the state transition from PREOP to SAFEOP. This manifests as an AL Status Error with a specific error code (e.g., Invalid Output Configuration (0x001D) or Object does not exist in object dictionary (0x9811004A)).

These errors typically arise from mismatches between the ESI (EtherCAT SubDevice Information) file, the ENI configuration, and the actual SubDevice firmware version.

Category 2: Runtime Errors — When an Operational Network Breaks

ID 200–201: MainDevice Disconnect and Reconnect

Pulling the Ethernet cable at the MainDevice kills all communication instantly. EC-Master detects the link-down condition, reports frame loss errors, and marks all SubDevices as absent.

Upon reconnection, EC-Master detects the link-up, rescans the bus, and reports all SubDevices as present again. Note that some SubDevices may have fallen to SAFEOP state during the outage — the application must explicitly command them back to OP.

ID 202–203: SubDevice Disconnect and Reconnect

Disconnecting a cable between SubDevices is more nuanced — only the devices downstream of the break are lost. EC-Master reports WKC errors on the affected process data commands and identifies exactly which SubDevices have become absent.

After reconnection, EC-Master's automatic bus scan detects the topology change and notifies the application. The key point: EC-Master does not automatically restore SubDevices to OP state. This is a deliberate design decision — the application must decide whether it's safe to resume operation.

ID 204–205: Power Failure and Recovery

When SubDevices lose power, the behavior is similar to a cable disconnect, but with one important difference: when power returns, the SubDevices start in INIT state (not their previous state). The application must walk them through the full state machine again.

ID 206: Unexpected SubDevice State

A SubDevice may autonomously drop to a lower state due to an internal error. The EC-Training Disturber simulates this by reporting a synchronization error (0x1A) and falling from OP to SAFEOP ERROR. EC-Master detects the AL status change and provides the specific error code to the application via EC_NOTIFY_SLAVE_ERROR_STATUS_INFO.

ID 207: Total Frame Loss from a SubDevice Failure

One of the most challenging scenarios: a SubDevice stops forwarding frames entirely, but its link status remains active. Since the upstream SubDevice doesn't see a link-down, it can't close the loop, and all frames are lost — even to healthy SubDevices earlier in the chain.

EC-Master's ecatRescueScan() API is designed for exactly this situation. It probes SubDevices one by one to determine which device is blocking frame forwarding, allowing the application to identify the faulty device even when normal communication has completely stopped.

ID 208: Unexpected SubDevice Connected

Connecting a device that isn't part of the ENI configuration triggers a bus configuration mismatch notification. EC-Master identifies the unexpected device and reports its vendor ID and product code. The unknown SubDevice stays in INIT state — no data is exchanged with it.

To proactively prevent unknown devices from disrupting communication, EC-Master provides APIs for Border Close — closing unused ports on the last configured SubDevices to reject any newly connected devices.

ID 209: PDI Watchdog — Firmware Crash Detection

If a SubDevice's firmware crashes and stops accessing its Process Data Interface, the EtherCAT Slave Controller (ESC) hardware detects this via the PDI Watchdog timer. EC-Master reads this status and notifies the application. Recovery requires cycling the SubDevice through INIT and back to OP.

Category 3: Intermittent Errors — The Subtle Ones

ID 300: Working Counter (WKC) Errors

Every cyclic EtherCAT command carries a Working Counter that gets incremented by each SubDevice that successfully processes it. If the actual WKC doesn't match the expected value, at least one SubDevice didn't process the command correctly.

EC-Master compares WKC values on every cycle and reports mismatches via EC_NOTIFY_CYCCMD_WKC_ERROR, including the command type, logical address, and expected vs. actual WKC values.

ID 301: Frame Loss

The EC-Training Disturber can selectively drop frames, simulating EMI interference or faulty cables. EC-Master tracks every sent frame and flags any that don't return within the expected timeframe.

EC-Master continuously reads the SubDevice Error Registers (registers 0x0300 ff.) to identify where in the network errors are occurring. The emGetSlaveStatistics() API exposes these counters, and EC-Engineer's Extended Diagnosis tab displays them per-SubDevice, per-port — showing Invalid Frame/CRC errors, RX errors, Lost Link counts, and Forwarded RX errors.

Diagnosis Tools and Best Practices

EC-Master Diagnosis Features API for Error Handling

The EC-Master stack provides a comprehensive notification system. Key notifications to handle in your application include:

• EC_NOTIFY_SB_MISMATCH — Bus scan found a topology mismatch
• EC_NOTIFY_SLAVE_ERROR_STATUS_INFO — A SubDevice has entered an error state
• EC_NOTIFY_CYCCMD_WKC_ERROR — Working Counter mismatch in cyclic data
• EC_NOTIFY_FRAME_RESPONSE_ERROR — A sent frame was not returned
• EC_NOTIFY_STATUS_SLAVE_ERROR — At least one SubDevice is in error status

For comprehensive documentation on error handling and the notification API, visit the EC-Master Class B documentation and the acontis Developer Center.

EC-Engineer Diagnosis Features

EC-Engineer provides several specialized analyzers for troubleshooting:

• Network Mismatch Analyzer: Compares configured vs. connected SubDevices side by side.
• Line Crossed Analyzer: Identifies SubDevices with swapped IN/OUT cabling.
• Rescue Scan: Probes the network device-by-device when normal communication has failed completely.
• Extended Diagnosis: Displays per-port error counters from ESC registers for pinpointing communication quality issues.
• Hardware Diagnostics: Real-time monitoring of frame counters (TX, RX, Lost), topology status, and link state.

Learn more about EC-Engineer diagnosis features in this blog.

Recommendations for Robust Error Handling

• Always register notification callbacks for the key error notifications listed above.
• Implement automatic recovery logic for transient errors — but require operator confirmation before restarting SubDevices after serious faults like power loss or firmware crashes.
• Use Border Close on production systems to prevent unauthorized devices from disrupting the network.
• Monitor error counters continuously via emGetSlaveStatistics() to detect degrading cable quality before it causes outages.
• Test your error handling using the test cases described in this article. The acontis EC-Training Disturber or similar tools allow you to simulate real fault conditions in a controlled environment.

Conclusion

EtherCAT's deterministic nature means that errors are well-defined and detectable — but only if the MainDevice software handles them properly. The acontis EC-Master stack provides comprehensive error detection, from bus scan mismatches during startup to per-port CRC error counters during operation. Combined with EC-Engineer's visual diagnosis tools, engineers can quickly identify and resolve network issues.

Whether you're commissioning a new machine, troubleshooting a field issue, or building resilient error handling into your application, understanding these error categories and their diagnostic signatures is essential knowledge for any EtherCAT developer.

Request the detailed test case specification “EC-Master Network diagnosis and error detection test cases”.