EtherCAT Software Components für Humanoids: Reliable, Fast Communication Requires the Right Network Architecture

Introduction: Humanoid Robots as an EtherCAT Application

Humanoid robots are among the most demanding applications for EtherCAT. Within a compact mechanical structure, they integrate dozens of synchronized servo axes, real-time sensors, and compute-intensive AI processing. One requirement matters above all: reliability. In the arms and legs, cables bend and twist with every movement—in the worst case, a cable break can cause the robot to fall. A junction in the torso solves this problem elegantly: with junction redundancy, each limb can be closed locally into a ring, and the additional cable only runs back to the junction. This combines cable redundancy with low weight.

Depending on the design, the torso, arms, legs, hands, and grippers alone require 40 to 80 drives. Not every drive requires its own EtherCAT SubDevice, since one SubDevice often controls multiple axes. Even so, a humanoid typically has around 30 to 50 SubDevices, plus additional devices for sensors and actuators such as IMUs, force/torque sensors, and joint encoders.

In this article, we use a practical test setup to demonstrate how three acontis software components work together on an NVIDIA Jetson AGX Thor Developer Kit: the EtherCAT MainDevice software EC-Master, the network simulation software EC-Simulator, and the browser-based configuration and diagnostics tool EC-EngineerWeb. The focus is on junction redundancy: in five practical tests, we show how EC-Master handles a cable break in a leg, how EC-EngineerWeb makes it visible, and how such faults can be tested in advance with EC-Simulator—without any hardware.

The Platform: NVIDIA Jetson AGX Thor

Our test setup uses the NVIDIA Jetson AGX Thor Developer Kit as its control platform. NVIDIA designed Jetson AGX Thor specifically for physical AI and humanoid robotics: the platform runs AI models for perception, planning, and language directly on the robot. NVIDIA’s humanoid architecture distinguishes between AI layers for perception, planning, and reasoning and a real-time control layer that requires low, predictable latency. EC-Master serves exactly this layer by providing deterministic communication between the control software and all of the robot’s drives and sensors.

acontis has already shown how these two worlds fit together on the same hardware in the article Thor meets EtherCAT – acontis EC-Master on NVIDIA Jetson AGX Thor. The starting point is the Linux distribution included in NVIDIA JetPack: the included real-time kernel is installed, one CPU core is reserved exclusively for EC-Master, and all cores run at maximum clock frequency. In the highest-performance configuration, the acontis real-time Ethernet driver also replaces the standard Linux driver and accesses the Ethernet controller directly through the atemsys kernel module.

Software Components Overview

In our test setup, three acontis tools cover the entire development cycle, from simulation and operation to diagnostics:

Test Setup

Since we do not currently have 40 or more drives available at acontis, we represent the network of a humanoid with a combination of drives and I/O modules. The test network consists of:

• a Beckhoff CU1128 junction, which appears in the network as three SubDevices;
• nine SubDevices each for the left and right arms;
• 11 SubDevices each for the left and right legs.

The first SubDevice on each arm and leg is a drive with Distributed Clocks enabled. The remaining SubDevices are analog and digital I/O modules. In total, the network comprises 43 SubDevices, with approximately 694 bytes of input data and 694 bytes of output data; the cyclic frame has a total length of 1434 bytes. EC-Master runs on the NVIDIA Jetson AGX Thor Developer Kit, which acts as the MainDevice.

Synchronous Drives with Distributed Clocks

Smooth motion requires all drives to operate in exact synchronization. The controller sends setpoints in a cycle of 1 ms or less, using CSP, CSV, or CST mode depending on the drive. Distributed Clocks (DC) provide the foundation: EC-Master aligns the clocks of all SubDevices to a common system time and compensates for signal propagation delays. As a result, all drives apply their setpoints at exactly the same moment—without any special hardware on the MainDevice.

Network Topology: Star Configuration with a Junction

EtherCAT supports almost any topology—line, daisy chain, star, tree, and drop lines—as well as any combination of these. Network performance is largely independent of the selected topology. Because EtherCAT does not require infrastructure components such as switches or hubs, it saves installation space, weight, and wiring in a humanoid robot.

A star topology is a natural fit for a conventional humanoid with two arms and two legs, since the controller is usually located centrally in the torso. A junction, also located in the torso and often serving as the first SubDevice, distributes the network to the arms and legs. A junction is not a switch: it forwards frames to its ports without buffering, preserving EtherCAT’s logical-ring principle. Our test setup uses the Beckhoff CU1128 junction.

Junction Redundancy for Arms and Legs

A cable break is particularly serious in the arms and legs, where the cables are constantly moving. The legs are especially critical: a cable break there can abruptly stop one or more drives. If the humanoid is walking at the time, it may fall, depending on its speed and design. After all, walking is essentially a controlled fall—once control is lost, a fall is hard to prevent.

Junction redundancy provides a way to protect the legs. Each drop line is closed locally into a ring: an additional cable runs from the last SubDevice back to the junction. In our test setup, the left leg connects to port X2 and the right leg to port X6; the redundant cables return to ports X3 and X7. EC-Master also supports these local rings in combination with Distributed Clocks—if a ring is interrupted, the robot remains operational.

With junction redundancy for both legs, seven of the eight ports of the CU1128 junction are in use (topology 2). If both arms are to be protected as well, the remaining port, X8, is not sufficient; an additional junction is then required. EC-Master also supports this configuration with additional local rings.

Junction Redundancy for Part of the Legs Only

A complete limb does not always need a redundant connection. It is also possible to add another junction within the local ring and connect further SubDevices to it through a drop line (branch). In this example, the first five SubDevices of each leg form a local ring together with the CU1128 junction. The fifth SubDevice also acts as a junction: the remaining six SubDevices are connected to it through a drop line without redundancy (topology 3). A cable break within the ring has no effect, whereas a break in the drop line disconnects the SubDevices beyond it from the network. This makes it possible to limit redundancy to a specific part of the legs. The following tests use topologies 1 and 2 only.

Testing whether a redundancy design works during a fault can be difficult and risky on a physical robot. EC-Simulator addresses this challenge by reproducing the entire network virtually and introducing targeted cable breaks, SubDevice failures, and other fault conditions—including scenarios that are difficult to reproduce on physical hardware.

Software Architecture

All software components run directly on Jetson AGX Thor. The EtherCAT application EcMasterDemoDc, which uses EC-Master, is pinned to CPU core 2. EC-EngineerWeb runs separately on CPU core 5, so it does not interfere with the real-time cycle. EC-EngineerWeb connects to the running EC-Master through the Remote Access System (RAS): the RAS server runs alongside EcMasterDemoDc on CPU 2, while the RAS client is part of EC-EngineerWeb on CPU 5. No additional software needs to be installed on the laptop; a web browser with the board’s IP address and port 5000 is all it takes.

In SWA1, EC-Master communicates with the physical test network through the acontis emllDwXgmac driver and one Ethernet port of the Jetson AGX Thor, referred to as the MainPort.

In SWA2, EC-Simulator replaces the Ethernet driver. EC-Master passes each frame to the simulator driver emllSimulator, which forwards it to the simulated SubDevices and returns it. No Ethernet interfaces or cables are required. The simulated SubDevices progress through the EtherCAT state machine to OP and support Distributed Clocks—from EC-Master’s perspective, there is no discernible difference from the physical network. For diagnostics, EC-Master and EC-Simulator each provide their own RAS server, on port 6000 and port 6001; EC-EngineerWeb can connect to both.

Tests

Tests 1 to 3 run with SWA1 on the physical network; tests 4 and 5 run with SWA2 in EC-Simulator.

Test 1: Physical Network with Standard Wiring

Here, the network runs in topology 1 without redundancy. EcMasterDemoDc starts the network with Distributed Clocks enabled and brings all SubDevices into the OP state. EC-EngineerWeb then goes online.

EcMasterDemoDc -v 3 -a 2 -b 1000 -f "Humanoid.xml" -sp 6000 -dwxgmac 1 1 jetson-agx-thor

In Diagnosis mode, the Topology View in EC-EngineerWeb displays the entire network graphically: the MainDevice (M1), the junction with its three SubDevices, and the lines for the arms and legs. On the right, the General tab shows the state of the selected SubDevice: the current and requested state of the EtherCAT state machine (Op in this case), buttons for changing the state, and the software and hardware diagnostics with the error status of each port.

Test 2: Physical Network with Junction Redundancy Wiring

Here, the network is wired according to topology 2: in addition to the connections on X2 and X6, both legs form local rings with the junction through X3 and X7. The -junctionred parameter enables junction redundancy in EcMasterDemoDc.

EcMasterDemoDc -v 3 -a 2 -b 1000 -f "Humanoid.xml" -sp 6000 -junctionred -dwxgmac 1 1 jetson-agx-thor

In Classic View, EC-EngineerWeb lists all SubDevices in a tree structure—from the MainDevice through the CU1128 junction down to the individual SubDevices of the arms and legs. On the right, the Variables tab shows the process data of the selected SubDevice with data type, offset in the process image, and current value. EC-EngineerWeb plots the history of a channel as a chart.

Test 3: What Happens When a Cable Breaks?

On the physical network with topology 2, we interrupt the connection between SubDevice 1033 and SubDevice 1034 in the right leg to simulate a cable break. EC-Master detects the topology change. One or two frames may be lost; otherwise, all SubDevices remain reachable and in the OP state, and the process data continues to flow: EC-Master now reaches the SubDevices beyond the interruption through the redundant cable on port X7 of the junction.

EC-Master records the following messages in its log file:

Junction redundancy change (Line break = 1) - Slave Right-Leg-Device2: - EtherCAT address=1034 at port 0
Bus scan successful - 43 slaves found
Topology Change Performed No Error (0x0)

The first message reports the detected line break at port 0 of Right-Leg-Device2 (EtherCAT address 1034), i.e., at its input from the preceding SubDevice 1033. The subsequent bus scan still finds all 43 SubDevices, and EC-Master completes the topology change without errors.

The cable break is also immediately visible in EC-EngineerWeb: a warning symbol with an exclamation mark in the tree marks Right-Leg-Drive1 and Right-Leg-Device2—the two SubDevices directly at the interruption, where an error was detected on their ports. All SubDevices remain green and therefore reachable, and the chart shows that the process data of Right-Leg-Device2 continues to flow.

Test 4: Simulated Network with Junction Redundancy Wiring

Here, topology 2 runs in EC-Simulator (SWA2). EC-Master and EC-Simulator use the same configuration file.

EcMasterDemoDc -f "Humanoid.xml" -b 1000 -sp 6000 -v 3 -a 2 -junctionred -simulator 1 1 Humanoid.xml --sp 6001

In EC-EngineerWeb, the simulated network appears in the tree under the EC-Simulator node. The Variables tab shows the inputs of the simulated SubDevices—and these can be set directly: in this example, input channel CH3 of the simulated Right-Leg-Device2 is forced to a value of 4, and the chart shows the step from 0 to 4. EC-Master reads this value just like a real input. This makes it possible to test how the application responds to specific sensor values without a real signal being present.

Test 5: Simulating Faults with EC-Simulator and EC-EngineerWeb

A robot must also handle faults reliably: a SubDevice loses its supply voltage, a connector comes loose, a cable breaks. Reproducing these conditions on the physical setup is time-consuming, risky, and difficult to repeat exactly. EC-EngineerWeb therefore provides a function for triggering fault scenarios in EC-Simulator in a controlled, reproducible way—for example, a SubDevice power loss or a cable disconnection. This makes it possible to examine precisely how EC-Master and the application respond to each individual fault without putting the hardware at risk.

With this test, we verify the redundancy concept of topology 2 in EC-Simulator (SWA2). The command line is the same as in test 4:

EcMasterDemoDc -f "Humanoid.xml" -b 1000 -sp 6000 -v 3 -a 2 -junctionred -simulator 1 1 Humanoid.xml --sp 6001

Faults are triggered on the Simulator tab of the respective SubDevice in EC-EngineerWeb.

• SubDevice: Power off and Power on simulate a power loss of the SubDevice. Using Requested State and Error Code, Set Sim State puts the simulated SubDevice into a different state, optionally with an error code. The SubDevice can also send a CoE emergency message with a freely selectable code and data.
• Simulate cable break: For each port, the dialog shows which neighboring SubDevice it is connected to. Disconnect breaks this connection, and Connect restores it—a cable break at the push of a button.
• Simulate intermittent errors: For sporadic faults, such as those caused by bad connectors or EMC interference, an unstable connection with an adjustable down time can be simulated per port, or bad frames can be generated—either permanently or randomly with a specified probability.

On the Simulator tab in EC-EngineerWeb, we use Disconnect under “Simulate cable break” to deliberately interrupt the network—at the same location as in test 3: on Right-Leg-Device2, we disconnect port 0, i.e., the connection to Right-Leg-Drive1 (1033). The dialog then shows port 0 as “Not Connected.” Thanks to junction redundancy, EC-Master can still reach all SubDevices, and the network remains in the OP state.

Functional Safety with FSoE

When humanoid robots operate near people, functional safety becomes a key consideration. Safety over EtherCAT (FSoE) is widely used for this purpose: under the black-channel principle, safety-related data is transmitted in the same EtherCAT frame as the standard data, eliminating the need for separate safety wiring. The topology therefore makes no difference to FSoE—it works with all of the topologies shown, with and without junction redundancy, and can be used with EC-Master without restrictions. acontis has already implemented FSoE solutions with partners on the NVIDIA IGX Thor platform.

Conclusion: Reliable by Design, Tested Before It Falls

A humanoid robot cannot tolerate a communication failure: walking is a controlled fall, and losing the connection to a leg can turn it into a real one. Our test setup shows how to prevent exactly this with standard components. With junction redundancy on the Beckhoff CU1128, EC-Master handled a physical cable break in the right leg with only one or two lost frames—all 43 SubDevices remained in OP with Distributed Clocks active, and no second Ethernet port was required. EC-Master, its diagnostics, and the robot’s AI applications all run on a single Jetson AGX Thor.

The same setup also supports the development workflow. With EC-Simulator, engineers can test their MainDevice application against a simulated network—including cable breaks, power loss, and intermittent errors—before the complete robot is available. The same application then runs on physical hardware using EC-Master’s Ethernet drivers, while EC-EngineerWeb provides diagnostics in both environments. This lets teams start integration testing earlier, reproduce faults consistently, and depend less on complete physical prototypes.

Sources

• acontis: EtherCAT and Real-Time Software for Humanoid Robotics Applications
• acontis: acontis + NVIDIA – AI-Powered EtherCAT for the Next Generation of Robotics
• acontis blog: Thor meets EtherCAT – acontis EC-Master on NVIDIA Jetson AGX Thor
• acontis blog: Ready for humanoid development? Diagnosis with EC-EngineerWeb on the NVIDIA Jetson AGX Orin
• acontis: EC-Master Junction Redundancy
• NVIDIA Technical Blog: Introducing NVIDIA Jetson Thor, the Ultimate Platform for Physical AI