SDAA410 June 2026 AM2611 , AM2612 , AM2612-Q1 , AM2631 , AM2631-Q1 , AM2632 , AM2632-Q1 , AM2634 , AM2634-Q1 , AM263P2 , AM263P2-Q1 , AM263P4 , AM263P4-Q1
Industrial robotics applications increasingly require distributed intelligence, in which sensors, actuators, and control logic are distributed across multiple points along a structure. In multi-axis robot arms, for example, each joint may contain position encoders, torque sensors, motor controllers, and safety monitors that must communicate with a central motion controller. Similarly, modular production lines consist of independent processing stations that coordinate through real-time message exchange. Traditional network topologies use star configurations with centralized Ethernet switches, but this approach becomes impractical when nodes are physically distributed along linear or articulated structures. Running individual cables from each node back to a central switch increases cable weight, cost, and mechanical complexity, particularly problematic for robot arms where cables must traverse moving joints and rotating axes. Daisy-chain topologies address these constraints by connecting nodes in series, where each device has two Ethernet ports: one receiving from the upstream device and one transmitting to the downstream device. This reduces cabling to single links between adjacent nodes and eliminates the need for centralized switches. However, daisy-chain configurations introduce other fundamental challenges such as cumulative latency. Motion control packets may require bounded latency and extremely low jitters, while telemetry or diagnostic traffic can tolerate some delays.
Each packet must traverse multiple hops to reach its destination, and processing delays accumulate at every intermediate node. For a motion control system operating at a 1-millisecond cycle time (1 kHz control loop), even small per-hop delays can become significant when packets must traverse four or five devices. So, the fundamental challenge is simultaneously satisfying three conflicting design requirements:
Traditional fieldbus protocols (CAN, EtherCAT, PROFINET) offer determinism but suffer from limited bandwidth (1 Mbps for CAN), and proprietary stacks that create vendor lock-in. Existing communication solutions for robotics fall into the categories below. CAN suffers from both bandwidth constraints (1 Mbps) and high latency, typical round-trip times range from 2-10 milliseconds depending on bus load and node count, far exceeding the sub-millisecond requirements for dynamic balance control. EtherCAT improves performance with cycle times of 250-500 microseconds in master-slave configurations, but multi-hop forwarding through daisy-chained slaves adds 20-50 microseconds per node. The EtherCAT implementation on the AM26x MCUs is limited to 100M. PROFINET IRT achieves 1-2 millisecond cycle times but requires specialized hardware and licensing. More critically, these protocols rely on rigid topologies (transmitter-receiver, star) and proprietary stacks. The table below summarizes the existing solution vs the solution proposed as a part of this appnote.
| Protocol | Cost Effective | Bandwidth | Determinism |
|---|---|---|---|
| CAN | Yes | No | No |
| PROFINET | No | Yes | Yes |
| EtherCAT | No | Yes | Yes |
| Standard Ethernet | Yes | Yes | No |
| Proposed Ethernet + TSN solution | Yes | Yes | Yes |