Robot Networking: EtherCAT, TSN & Fieldbus, The Ultimate Guide

Every robot is a collection of clocks trying to agree. The current loop in a servo drive fires at tens of kilohertz, the joint controller runs at 1 kHz, the motion planner replans a few times a second, and a fleet manager somewhere polls the whole cell every few seconds. The wires and radios that carry data between these clocks are the part of the machine nobody photographs and everybody debugs. When a robot judders, drops a safety input, or loses its place in a warehouse, the fault usually lives in the network that was supposed to deliver a number before a deadline and did not, rather than in the algorithm or the motor.

This guide covers the networking layers inside and around a robot, from the microsecond-scale bus that connects a controller to its drives out to the wireless links that tie a fleet of mobile robots to a warehouse management system. We will work through industrial Ethernet (EtherCAT and its processing-on-the-fly trick, PROFINET, EtherNet/IP), the embedded buses that still dominate motor and sensor links (CAN and CAN FD), Time-Sensitive Networking (TSN) and what the IEEE actually standardized, and the wireless story (Wi-Fi 6/6E, private 5G, UWB) for robots that cannot drag a cable. The through-line is determinism: latency, jitter, cycle time, and the topology choices that decide whether your control loop stays closed.

The take: Robot networking is a hierarchy of determinism, and the engineering is knowing which layer owes which guarantee. The hard current loop lives in the drive. A field-level industrial-Ethernet bus (EtherCAT is the default for robot arms) carries the 1 kHz joint loop with microsecond jitter and distributed-clock sync. CAN FD still connects cheap actuators and sensors. TSN is the convergence layer that lets one Ethernet fabric carry both hard-real-time control and best-effort video. Wireless never carries a hard loop; it carries goals, telemetry, and coordination. Match the protocol to the deadline it actually has to meet, and most timing mysteries disappear.

Companion reading: industrial automation: PLC, SCADA & fieldbus, real-time robot control, robot wiring, cables & connectors, ROS 2, and robot middleware & DDS.

Table of contents

1. Key takeaways
2. The networking stack inside a robot
3. Determinism, latency, and jitter
4. EtherCAT: processing on the fly
5. PROFINET and EtherNet/IP
6. CAN and CAN FD
7. Time-Sensitive Networking (TSN)
8. Topology and physical layer
9. Protocol comparison and cycle-time budgets
10. Functional safety over the network
11. Wireless for mobile robots and fleets
12. Designing a robot network: a worked example
13. Failure modes and debugging
14. Frequently asked questions

The networking stack inside a robot

It helps to picture a robot's data paths as concentric rings of shrinking deadlines. The outer rings tolerate seconds; the inner rings tolerate microseconds. Each ring has its own protocol family because no single technology is good at both extremes.

The enterprise ring (seconds). A warehouse management system (WMS), a manufacturing execution system (MES), or a fleet manager talks to the robot over plain TCP/IP: REST, MQTT, OPC UA, or a vendor API. Deadlines are human-scale. Order assignments, KPIs, over-the-air updates. Nothing here is real time.

The coordination ring (tens to hundreds of milliseconds). This is where ROS 2 and DDS live, where a mobile robot receives a goal pose and streams back odometry and a costmap, where a planner replans. Soft real time. A late message degrades behavior; it does not destabilize a loop. See the ROS 2 guide and the middleware and DDS guide for how QoS governs this ring.

The field/control ring (100 microseconds to a few milliseconds). The joint control loop. A robot controller sends position or velocity setpoints to every drive and reads back position, velocity, and torque, all within one fixed cycle. This is the domain of EtherCAT, PROFINET IRT, EtherNet/IP with CIP Motion, and CANopen. Jitter here shows up as vibration in the tool and error in the path.

The device ring (microseconds). Inside a servo drive, the current/commutation loop runs at 10-40 kHz. This loop is never carried over a shared network. It is closed in the drive's own silicon, reading the encoder over a dedicated digital interface (BiSS-C, EnDat, or a vendor serial link). The real-time control guide covers why this loop stays local.

The design principle that ties these together: each ring hands the next-inner ring a target and trusts it to meet a tighter deadline. The fleet manager hands a goal to ROS 2. ROS 2 hands setpoints to the field bus. The field bus hands a current reference to the drive. The drive closes the fast loop. A network architecture goes wrong when a ring is asked to carry a deadline that belongs one level down, which is the single most common mistake and the subject of a war story later.

Determinism, latency, and jitter

The vocabulary matters because vendors blur it. Three numbers describe a real-time link.

Cycle time is the period of the control update. A robot arm typically runs a 1 kHz field bus, so the cycle time is 1000 microseconds. Some high-performance machines push to 250 or 125 microseconds. The cycle time sets how fresh the setpoints and feedback are.

Latency is the time from a sample being taken to it being acted on. It includes the time to serialize a frame, propagate down the cable, pass through switches, and be processed at the far end. Store-and-forward Ethernet switches add latency because they receive a whole frame before forwarding it.

Jitter is the variation in that latency from cycle to cycle. If a frame is supposed to arrive every 1000 microseconds and actually arrives at 998, 1001, 1003, 997 microseconds, the jitter is the spread. Control loops care about jitter far more than absolute latency, because a constant delay can be modeled and compensated while a varying delay cannot. A control loop with 4 microseconds of jitter behaves; the same loop with 400 microseconds of jitter, roughly 40 percent of a 1 kHz cycle, injects noise into the plant.

The reason industrial Ethernet exists as a category is that standard switched Ethernet, left alone, has unbounded worst-case latency. When two frames arrive at a switch port at once, one waits. Under load, a best-effort switch can delay a frame by the time it takes to drain a full queue, which at 100 Mbit/s and a 1522-byte maximum frame is about 122 microseconds per queued frame. Queue a handful and you have blown a 1 kHz budget. Every deterministic-Ethernet technology is, at bottom, a different answer to the question of how to stop a control frame from waiting behind a bulk-data frame.

Rule of thumb: size a field bus so its cycle time is at least 5 to 10 times faster than the mechanical bandwidth you are controlling, and demand jitter under a few percent of the cycle. A joint closing 30-50 Hz of bandwidth wants a 1 kHz bus with single-digit-microsecond jitter. If the vendor quotes an average latency but not a worst case, assume they are hiding the tail.

There is a second determinism problem beyond delivery time: agreement on when. If every drive stamps its feedback with its own free-running clock, the controller cannot fuse the readings into a consistent snapshot of the robot's state. Distributed clock synchronization solves this. EtherCAT's Distributed Clocks and TSN's 802.1AS (a profile of IEEE 1588 PTP) both give every node a shared notion of time accurate to well under a microsecond, so all axes sample and actuate on the same tick. Synchronized actuation is what keeps a six-axis arm's tool tracking a straight line instead of drawing a wobble.

EtherCAT: processing on the fly

EtherCAT (Ethernet for Control Automation Technology), developed by Beckhoff and managed by the EtherCAT Technology Group since 2003, is the field bus you will meet most often on robot arms, and it is worth understanding mechanically because its trick is genuinely different from ordinary Ethernet.

In a normal switched network, the master sends a separate frame to each slave, each frame is received in full, processed, and a reply generated. For 100 axes that is 100 round trips, and the overhead of a minimum 84-byte Ethernet frame per tiny payload destroys efficiency. EtherCAT inverts this. The master sends one frame that is routed through every slave in sequence, and each slave reads the data addressed to it and writes its own data into the same frame as the frame is passing through, in hardware, without buffering the whole thing. Beckhoff's phrase for this is "processing on the fly."

The mechanism is a dedicated ASIC or FPGA in each slave (the EtherCAT Slave Controller, ESC) that introduces a fixed, tiny forwarding delay, on the order of a few hundred nanoseconds per node, while it extracts and inserts its data on the wire. The frame goes out from the master, threads through slave 1, slave 2, ... slave N, reaches the end of the segment, and the last device loops it back so it returns to the master through the same nodes on the return path. The physical wiring is a line or a tree; the logic is a ring. One frame, one lap, and the entire process image (all setpoints out, all feedback in) is exchanged.

The numbers are the selling point. EtherCAT can update 1000 distributed digital I/O in about 30 microseconds, or 100 servo axes with position, velocity, and status in around 100 microseconds. Because a single frame carries many nodes' data, bus utilization is high even with small per-node payloads. Cycle times of 1 kHz are routine and 4-8 kHz is achievable on tightly built machines.

Distributed Clocks (DC) is the second pillar. One reference slave holds the master clock, and the ESCs measure propagation delays between nodes at startup and continuously discipline their local clocks to it. The result is synchronized actuation across the whole bus with jitter typically well under 1 microsecond, often quoted around 20-100 nanoseconds. Every drive latches its command and samples its feedback on the same synchronized instant, which is exactly what coordinated multi-axis motion needs.

On the application side, motion runs over CoE (CANopen over EtherCAT), which reuses the CANopen device profile CiA 402 for drives. That is why a drive engineer moving from a CAN bus to EtherCAT sees the same object dictionary, the same modes of operation (cyclic synchronous position, velocity, torque), and the same PDO/SDO concepts. EtherCAT also carries FoE (file access), EoE (tunneled standard Ethernet for a web UI on a slave), and SoE (the SERCOS drive profile).

War story: a team building a seven-axis arm ran EtherCAT at 2 kHz on the bench flawlessly, then saw random following-error faults in the field. The cause was a single slave whose Distributed Clock support was misconfigured, so it actuated on its own drifting clock instead of the synchronized one. Nothing dropped, no frame was lost, the bus diagnostics were green. The axes were simply sampling at slightly different instants, and at 2 kHz the phase error was enough to trip the drive's following-error guard on fast moves. The fix was one checkbox in the ENI configuration. Distributed Clocks is mandatory for coordinated motion; it is the whole point of the bus.

PROFINET and EtherNet/IP

If EtherCAT owns the tight loop inside many robots, PROFINET and EtherNet/IP own the cell and the line: the PLC-centric world where a robot is one device among conveyors, drives, safety scanners, and vision systems. Both run over standard Ethernet, which is their strength (any switch, any NIC) and the reason they need extra mechanisms to become real time.

PROFINET, from the PROFIBUS and PROFINET International (PI) organization and closely tied to Siemens, comes in tiers:

• PROFINET RT (Real Time) sends cyclic process data in prioritized standard Ethernet frames (VLAN priority, EtherType 0x8892), bypassing the TCP/IP stack. Cycle times land around 1-10 milliseconds. Good for I/O, sensors, and non-motion control.
• PROFINET IRT (Isochronous Real Time) adds hardware-scheduled, time-slotted transmission through IRT-capable switches, reserving a bandwidth window for cyclic data so it is immune to other traffic. Cycle times down to about 250 microseconds with sub-microsecond jitter, which is enough for coordinated motion.

EtherNet/IP (the IP is Industrial Protocol), managed by ODVA and common in North America and with Rockwell/Allen-Bradley systems, runs the CIP (Common Industrial Protocol) object model over standard Ethernet. Cyclic I/O uses UDP-based implicit messaging; configuration and diagnostics use TCP-based explicit messaging. Base EtherNet/IP is soft real time with cycle times of a few milliseconds. For motion, CIP Motion and CIP Sync (built on IEEE 1588 PTP) add time synchronization and deterministic delivery, and ODVA has layered CIP over TSN to sharpen the guarantees on modern switch fabrics.

The practical distinction between these and EtherCAT: PROFINET and EtherNet/IP put a full protocol stack in every device and rely on switches, so each node is a heavier, more capable participant and the topology is a switched star or a ring. EtherCAT puts a minimal ASIC in every node and does the clever work in the frame itself. For a robot that is a subordinate device on a line, the robot controller usually speaks PROFINET or EtherNet/IP upward to the cell PLC while running EtherCAT or a vendor bus downward to its own drives. A KUKA or ABB arm on an automotive line is doing exactly this: EtherNet/IP or PROFINET to the line, an internal motion bus to the axes.

Protocol	Steward	Typical cycle	Motion tier	Common in
PROFINET RT	PI / Siemens	1-10 ms	(use IRT)	Cell I/O, drives, Europe
PROFINET IRT	PI / Siemens	250 us-1 ms	IRT (isochronous)	Coordinated motion, presses
EtherNet/IP	ODVA / Rockwell	1-10 ms	CIP Motion + CIP Sync	Lines, North America
EtherCAT	ETG / Beckhoff	62.5 us-1 ms	native + DC	Robot arms, CNC, servo axes

CAN and CAN FD

Ethernet did not push CAN out of robots. CAN (Controller Area Network), designed by Bosch in the 1980s for cars, is still the cheapest robust way to connect many small nodes: grippers, force/torque sensors, battery management systems, low-cost joint modules, and the general I/O of a mobile base. Its virtues are a two-wire differential bus, excellent noise immunity, built-in arbitration, and a controller in nearly every microcontroller made.

Classic CAN has two constraints that matter for robotics. First, bandwidth: the practical ceiling is 1 Mbit/s, and because arbitration requires the signal to settle across the whole bus within a bit time, higher rates force shorter buses (1 Mbit/s caps the bus at roughly 40 meters). Second, payload: a CAN frame carries at most 8 data bytes, so a 6-axis force/torque reading or a firmware update crawls across many frames.

CAN FD (Flexible Data-rate), standardized in ISO 11898-1:2015, addresses both without abandoning the wiring or the arbitration model. It does two things:

• Larger payload: up to 64 data bytes per frame instead of 8, so a full sensor packet fits in one frame.
• Dual bit rate: the arbitration phase stays slow (so the classic distributed arbitration still works across the bus), then the data phase switches to a higher rate, commonly 2, 5, or up to 8 Mbit/s, once a node has won the bus and is talking alone. This is the "flexible data-rate" in the name.

The effect is a several-times increase in effective throughput on the same physical bus with the same connectors. CAN FD does require FD-capable transceivers and controllers, and a mixed bus with a single classic-CAN-only node will fault, so migration is all-or-nothing per segment.

On top of the raw bus sits an application layer. CANopen (CiA 301 and the CiA 402 drive profile) is the dominant one in industrial and robotics contexts: an object dictionary, PDOs (process data, cyclic) and SDOs (service data, acyclic config), and standardized device profiles so a CANopen gripper from one vendor looks like a CANopen gripper from another. CANopen FD (CiA 1301) extends this to CAN FD. In vehicles and some mobile robots you also see J1939 (heavy-duty vehicles) and SAE-style higher layers.

Rule of thumb: reach for CAN FD when you have many low-to-medium-rate nodes, a cost-sensitive design, long-ish runs in an electrically noisy machine, and no single node needs a hard sub-100-microsecond loop. Reach for EtherCAT when you have high-performance coordinated servo axes that need microsecond sync. Many real robots run both: EtherCAT to the main arm drives, CAN FD to the gripper, the sensors, and the housekeeping.

Time-Sensitive Networking (TSN)

TSN is the industry's attempt to make one Ethernet fabric carry everything: hard-real-time motion, soft-real-time telemetry, and best-effort video and file transfer, all on the same switches, without the control traffic ever waiting behind a camera stream. It is a set of amendments to the base IEEE 802.1Q bridging standard, developed by the IEEE 802.1 Time-Sensitive Networking task group (the successor to Audio Video Bridging). Understanding TSN means understanding that it is a toolbox of amendments, and a given deployment picks the pieces it needs.

The load-bearing amendments:

• IEEE 802.1AS (gPTP): the time-synchronization profile, a tightened IEEE 1588 Precision Time Protocol. It gives every bridge and end station a common clock accurate to under a microsecond. Everything else in TSN that schedules by time depends on this.
• IEEE 802.1Qbv (Enhanced Scheduling / Time-Aware Shaper): the headline feature. Each switch egress port has gates on its priority queues, and a time-synchronized schedule (the Gate Control List) opens and closes them. During a reserved window, only the control queue's gate is open, so a scheduled control frame transmits with no interference. This is how you get a protected time slot for motion on shared Ethernet.
• IEEE 802.1Qbu + IEEE 802.3br (Frame Preemption): lets a high-priority frame interrupt a lower-priority frame mid-transmission, sending an express fragment now and finishing the preempted frame later. Without preemption, a control frame can still wait up to one maximum-size frame (about 122 microseconds at 100 Mbit/s) behind a bulk frame that already started; preemption cuts that residual blocking to the length of a single minimum-size fragment, a few microseconds at 100 Mbit/s and well under a microsecond at gigabit.
• IEEE 802.1Qbv/Qcc/Qav and friends handle scheduling configuration and the older credit-based shaper.
• IEEE 802.1CB (Frame Replication and Elimination for Reliability, FRER): sends duplicate frames over disjoint paths and eliminates the duplicate at the far end, so a single link or switch failure does not lose a control frame. This is seamless redundancy for the traffic that cannot afford a retransmit.
• IEEE 802.1Qci (Per-Stream Filtering and Policing): protects the network from a misbehaving or malicious talker by policing each stream against its reservation.

The point of all this: converged networking. Historically a robot cell ran a dedicated field bus for control and a separate network for cameras and IT. TSN lets both share infrastructure while the control traffic keeps a hard guarantee. The catch is configuration complexity. A TSN network needs a picture of every time-critical stream (its period, size, path, and deadline) so the Central Network Configuration can compute gate schedules. Getting that global schedule right, and keeping it right as the machine changes, is real engineering.

TSN is also converging with the field buses rather than replacing them wholesale. EtherCAT added an EtherCAT-over-TSN mode so EtherCAT segments can traverse a TSN backbone. PROFINET over TSN and CIP over TSN are defined. The likely 2026-and-beyond picture is a TSN backbone carrying multiple protocols' real-time streams plus IT traffic, with classic field-bus segments hanging off it near the machines.

Topology and physical layer

The protocol dictates the shape of the wiring, and the wiring is where field problems hide. The cables and connectors guide covers the physical side in depth; here is how topology maps to protocol.

EtherCAT: line and tree, logical ring. Devices daisy-chain: master to slave 1 to slave 2 and so on, using the two ports on each slave. Because the frame loops back through the last device, a break in the line stops everything downstream, so many machines wire a physical ring (last device back to a second master port) and enable cable-redundancy, so a single break heals by the frame reversing at the break. Branches use junction slaves. There are no switches in a pure EtherCAT segment; the slaves are the infrastructure.

PROFINET / EtherNet/IP: switched star and ring. These need managed switches. A star is simple but a single switch or uplink failure is a single point of failure, so line and ring topologies with MRP (Media Redundancy Protocol, PROFINET) or DLR (Device Level Ring, EtherNet/IP) are standard on the plant floor. A ring survives one break by reconfiguring in milliseconds. Device-integrated two-port switches let you daisy-chain nodes without external switches.

CAN / CAN FD: terminated linear bus. A single trunk with short stubs, and critically a 120-ohm termination resistor at each physical end (two total). Missing or wrong termination is the classic CAN failure: reflections corrupt frames and the bus throws error frames under load. Bus length trades against bit rate.

The physical media questions cut across all of them: shielded twisted pair for noise immunity near motors and drives, connector ratings (M12 D-coded or X-coded for industrial Ethernet, M8/M12 for CAN) that survive vibration and washdown, drag-chain-rated cable for anything that flexes millions of cycles inside a moving arm, and separation of signal from power to limit coupled noise. A robot arm's internal cabling is a fatigue-life problem as much as a signal-integrity one: the bus cable inside a wrist that rotates continuously is one of the most-replaced parts on an industrial arm.

Single Pair Ethernet (SPE, 10BASE-T1L / T1S) deserves a mention as the emerging bottom layer. It runs Ethernet over a single twisted pair for long reaches (10BASE-T1L to 1 km) or short multidrop segments (10BASE-T1S), with power over the same pair. The goal is to push IP and TSN all the way to simple sensors and actuators that used to justify a separate field bus, collapsing the layers.

Protocol comparison and cycle-time budgets

The table below puts the field-level options side by side. Cycle times are typical achievable ranges on well-built systems; real deployments often run slower than the minimum for margin.

Protocol	Physical layer	Min cycle (typical)	Sync jitter	Payload model	Redundancy	Sweet spot
EtherCAT	100 Mbit Ethernet (Fast Ethernet)	62.5 us-1 ms	< 1 us (DC, ~100 ns)	one frame, all nodes	cable redundancy (ring)	Servo axes, robot arms, CNC
PROFINET IRT	100 Mbit Ethernet + IRT switches	250 us-1 ms	< 1 us	per-device frames, scheduled	MRP	Coordinated motion, Siemens cells
PROFINET RT	Standard Ethernet	1-10 ms	ms-scale	per-device frames	MRP	Cell I/O, drives
EtherNet/IP + CIP Motion	Standard Ethernet + PTP	1-2 ms	< 1 us (CIP Sync)	UDP implicit + PTP	DLR	Motion in Rockwell lines
EtherNet/IP (base)	Standard Ethernet	1-10 ms	ms-scale	UDP implicit / TCP explicit	DLR	Line I/O, North America
CAN FD + CANopen FD	2-wire differential	1-10 ms	ms-scale	64-byte frames, arbitrated	dual bus (optional)	Grippers, sensors, low-cost axes
Classic CAN + CANopen	2-wire differential	5-20 ms	ms-scale	8-byte frames, arbitrated	dual bus (optional)	Legacy nodes, simple I/O
SERCOS III	100 Mbit Ethernet ring	31.25 us-1 ms	< 1 us	ring, collision-free	native ring	High-end machine tools, some robots
POWERLINK	Standard Ethernet, polled	100 us-1 ms	< 1 us	managing-node polling	ring options	Servo, open-source stacks

A worked cycle-time budget makes the numbers concrete. Suppose a 6-axis arm runs a 1 kHz (1000 microsecond) EtherCAT loop. The budget inside one cycle:

• Master builds the process image and queues the frame: a few microseconds.
• Frame transmits and threads all 6 drives plus 2 I/O nodes: at ~300 ns forwarding delay per node and a short frame, on the order of 5-10 microseconds one way, doubled for the return, so roughly 15-25 microseconds on the wire.
• Drives latch commands and sample feedback on the synchronized DC tick: aligned to the cycle, effectively zero added jitter.
• The remaining ~950 microseconds is slack: the controller's own computation of the next setpoints, plus margin.

The lesson is that the bus is a small fraction of a 1 kHz budget. The dominant cost is usually the controller's motion computation and the operating system's scheduling jitter on the control PC, which is why the control application runs on a real-time kernel with an isolated core, exactly as described in the real-time control guide. The network is fast; the thing that misses deadlines is the general-purpose OS underneath the master.

Functional safety over the network

An emergency stop, a safe torque off, a safely-limited speed: these have to work even when the network they ride on is having a bad day. The industrial world solved this with the black-channel principle. A dedicated safety protocol runs on top of the ordinary field bus, and it treats that bus as an untrusted "black channel" that may delay, drop, duplicate, or corrupt messages. The safety layer detects all of those failures itself, so the underlying network needs no safety certification. Only the safety endpoints and the safety protocol are certified.

The safety layer's toolkit, standardized under IEC 61784-3, includes a sequence number (catches lost or duplicated frames), a timeout/watchdog (catches delays, and a missing frame within the watchdog forces the safe state), a unique connection ID (catches misrouted frames), and a CRC independent of the transport's own CRC (catches corruption). If any check fails, the device drives its outputs to the safe state, typically de-energizing.

The three you will meet:

• FSoE (FailSafe over EtherCAT / Safety over EtherCAT): the safety layer for EtherCAT, standardized as IEC 61784-3-12. Carries safety data in the same cyclic frame as the motion data, up to SIL 3 (IEC 61508) and PLe (ISO 13849).
• PROFIsafe: the safety layer for PROFINET (and PROFIBUS), IEC 61784-3-3, ubiquitous in Siemens-based cells, up to SIL 3 / PLe.
• CIP Safety: the safety layer for EtherNet/IP (and other CIP networks), IEC 61784-3-2, common in Rockwell systems, up to SIL 3 / PLe.

The value is a single cable carrying both standard control and safety, instead of a parallel hardwired safety loop of relays and dual-channel wiring. A safety scanner, a light curtain, an e-stop, and a drive's Safe Torque Off can all be nodes on the same bus, with the safety protocol guaranteeing the reaction time and the fault detection. This connects directly to the broader safety story: functional-safety standards (IEC 61508, ISO 13849, and for robots ISO 10218 and ISO/TS 15066) require a demonstrable, bounded reaction time from a hazard to the safe state, and the network's contribution to that reaction time (worst-case detection plus watchdog) is part of the calculation.

Safety rule: the safety function's worst-case reaction time is a sum, and the network is one term. It includes the sensor's detection time, the safety protocol's watchdog and one or two cycle times, the logic's evaluation, and the actuator's stopping time. Budget it end to end and verify it; a safety protocol makes the network analyzable, and the analysis is yours to carry out.

Wireless for mobile robots and fleets

A mobile robot cannot drag a cable, so its outer rings go wireless. The firm rule that survives every deployment: no radio carries a hard control loop. Wi-Fi, 5G, and UWB carry goals, maps, telemetry, video, and position fixes. The 1 kHz loop that keeps the robot upright and tracking stays entirely onboard, closed over the robot's internal EtherCAT or CAN bus. A robot must remain safe and controllable through a total loss of radio, coasting to a safe stop on its own, because radio will be lost.

Wi-Fi (802.11). The workhorse for AMRs in warehouses. Wi-Fi 6 (802.11ax) and Wi-Fi 6E (adding the 6 GHz band) brought OFDMA, better scheduling, and target wake time, which improve behavior in dense multi-robot deployments where dozens of robots share a floor. The hard problem in a warehouse is roaming, and raw throughput rarely is. As a robot drives, it hands off between access points, and a slow handoff (the 802.11r/k/v fast-roaming amendments help, but many deployments configure them poorly) creates a multi-hundred-millisecond gap where the robot hears nothing from the fleet manager. Robots must ride through these gaps. Coverage design (AP placement, channel planning, avoiding the crowded 2.4 GHz band) is a large fraction of a successful AMR install.

Private 5G. Increasingly deployed in large or RF-hostile facilities where Wi-Fi roaming is painful. A private 5G network (using licensed, shared, or unlicensed spectrum such as CBRS in the US) gives seamless mobility across a big site, deterministic-ish scheduling, and better behavior at range and through obstructions than Wi-Fi. 5G's URLLC (Ultra-Reliable Low-Latency Communication) profile targets ~1 millisecond air-interface latency at high reliability, which is why 5G is discussed for tighter coordination, though it still does not close an onboard control loop. The trade is cost and complexity: a private 5G rollout is an infrastructure project, and robot 5G modems and integration are pricier than Wi-Fi. In 2026, Wi-Fi still dominates by unit count; private 5G grows in the demanding, large-site tier.

Ultra-Wideband (UWB). UWB is a positioning technology, and it belongs here because fleets need location. UWB (IEEE 802.15.4z) measures time-of-flight between anchors and tags to give 10-30 cm ranging accuracy indoors, where GNSS does not reach. It is used for indoor localization of robots and for safe human-robot proximity (a UWB tag on a worker lets a robot know a person is near before a scanner sees them). It complements onboard SLAM rather than replacing it.

Bluetooth Low Energy and 802.15.4/Zigbee/Thread show up for low-rate telemetry, commissioning, and sensor networks around the robots, and they stay off the robots' primary link.

Technology	Role	Latency (typical)	Range indoors	Watch out for
Wi-Fi 6/6E	AMR primary link, telemetry, video	5-50 ms	per-AP cells	Roaming gaps, 2.4 GHz congestion
Private 5G	Large-site mobility, video, tighter coord	5-30 ms (URLLC ~1 ms air)	site-wide	Cost, spectrum, integration
UWB (802.15.4z)	Indoor position, human proximity	ranging, ms-scale	10-30 cm accuracy	Anchor infrastructure, NLOS
BLE / 802.15.4	Sensors, commissioning	10s of ms	short	Low bandwidth

Designing a robot network: a worked example

Consider a realistic machine: a mobile manipulator, a wheeled AMR base carrying a 6-axis collaborative arm and a camera, working in a warehouse and coordinated by a fleet manager. Walk the rings from the inside out.

Inside the arm (device ring). Each joint has a servo drive that closes its current loop at ~16 kHz internally, reading a 23-bit absolute encoder over a vendor serial link (BiSS-C class). Nothing shared here.

Arm control (field ring). The arm's controller runs EtherCAT at 1 kHz to the six drives plus the safety I/O, with Distributed Clocks on so all axes actuate together, and FSoE carrying Safe Torque Off and the safe-speed function to the drives for collaborative operation. The gripper and the force/torque sensor hang off a CAN FD segment via CANopen, since they do not need microsecond sync.

Base control (field ring). The wheel drives run their own bus, often CANopen or a second EtherCAT segment, at 500 Hz to 1 kHz. The safety scanners (front and rear lidar-based) connect over a safety protocol to the base's safety controller, enforcing safe-speed and protective-stop zones.

Onboard coordination (coordination ring). A Linux compute box runs ROS 2. It talks EtherCAT/CAN downward to the arm and base controllers through hardware-interface layers (this is exactly the ros2_control boundary), and DDS sideways to the perception and planning nodes. The camera streams over onboard Ethernet, likely a small TSN or standard switch, sharing the wire with the control PC. TSN here keeps the control traffic and the video from interfering if they share a switch.

Fleet link (coordination/enterprise ring). Wi-Fi 6E (or private 5G on a large site) connects the robot to the fleet manager: goals in, telemetry and status out, maps synced, OTA updates pushed. UWB anchors around the facility, plus onboard SLAM, give position. If the Wi-Fi drops mid-aisle, the robot finishes its current motion, holds position or parks safely, and reconnects. The fleet link never carries anything with a sub-second deadline.

The architecture is legible once you see it as rings: EtherCAT and CAN FD at the field level, ROS 2/DDS for coordination, Wi-Fi/5G for the fleet, and a safety protocol threaded through the field level so the stop function is bounded and certified. Each layer meets its own deadline and hands a target to the next.

Failure modes and debugging

Networks fail in a small number of characteristic ways. Knowing the signatures saves days.

Silent QoS/priority starvation (coordination ring). On the ROS 2/DDS side, a control-adjacent topic can be starved by a high-rate camera topic, or messages silently vanish on a QoS mismatch. This is a software-layer problem covered in the middleware and DDS guide; the tell is that everything looks connected but data is stale or missing.

Distributed-clock drift (EtherCAT). Coordinated axes vibrate or throw following-error faults while every bus diagnostic reads healthy. The clock sync is wrong while the delivery is fine. Check that DC is enabled on every axis and that the reference clock is stable.

Missing termination or wrong bit rate (CAN). The bus throws error frames under load, nodes drop off intermittently, and it gets worse as you add nodes or lengthen the cable. Verify exactly two 120-ohm terminators (measure ~60 ohms across the bus with power off) and that every node agrees on the bit rate and, for CAN FD, the FD settings.

Store-and-forward queueing (standard Ethernet without TSN). A control frame occasionally arrives late when a bulk transfer runs. The average is fine, the tail is not. Either separate the traffic, add TSN scheduling and preemption, or move control off the shared switch.

Roaming gaps (Wi-Fi). A mobile robot stutters or loses fleet contact at predictable spots on its route, usually AP cell boundaries. Fix coverage and fast-roaming configuration; design the robot to ride through the gap regardless.

Topology single points of failure. A star network's uplink dies and takes a whole cell down; an EtherCAT line breaks and everything downstream goes dark. Rings (MRP, DLR, EtherCAT cable redundancy) exist for exactly this and are worth the extra cabling on anything that cannot tolerate a stop.

The tooling is protocol-specific: EtherCAT masters expose per-slave working-counter and lost-frame counters (a rising working-counter error points straight at a flaky node or connector); PROFINET and EtherNet/IP have diagnostic alarms and tools like Wireshark with industrial dissectors; CAN needs a bus analyzer that counts error frames and shows the error-passive/bus-off state; Wi-Fi needs a spectrum and roaming analysis. The general discipline is the same as everywhere in robotics: instrument the layer you suspect, capture the worst case rather than the average, and reproduce the failure before you change anything.

War story: a palletizing cell dropped into a protective stop a few times a shift with no pattern anyone could find, and the robot logs blamed a communication timeout to a safety scanner. The scanner, the robot, and a new vision PC all shared one unmanaged switch. The vision PC's periodic image upload to a server filled the switch's buffer just long enough that the safety protocol's watchdog, correctly, forced the safe state. Nothing was broken; the safety layer did its job on a black channel that briefly misbehaved. The fix was to give control and safety traffic a TSN-capable switch with a reserved window, or simply to separate the IT traffic onto its own network. The root cause was the shared best-effort switch, and the safety protocol behaved correctly throughout.

Frequently asked questions

Why not use standard Ethernet and TCP/IP for everything? Because standard switched Ethernet has an unbounded worst-case latency: a control frame can wait behind other traffic in a switch queue, and TCP adds retransmission delays that are fatal to a fixed-cycle loop. Field buses and TSN exist precisely to give a bounded delivery time. For the coordination and enterprise rings, where deadlines are tens of milliseconds or looser, plain TCP/IP is exactly right.

Is EtherCAT actually Ethernet? On the wire, yes: it uses standard 100 Mbit Ethernet physical layers, cables, and frames. In behavior, no: instead of switches routing separate frames to each device, one frame passes through every device, which reads and writes its data on the fly. That processing-on-the-fly design is why EtherCAT is far more efficient and deterministic than standard switched Ethernet for many small nodes.

EtherCAT vs PROFINET vs EtherNet/IP: which should I use? It usually follows your controller and your market. EtherCAT is the common choice inside robot arms and servo machines for its microsecond sync and efficiency. PROFINET dominates Siemens-based European lines; EtherNet/IP dominates Rockwell-based North American lines. A robot on a plant floor often speaks PROFINET or EtherNet/IP upward to the cell PLC and runs EtherCAT or a vendor bus downward to its own drives.

Is CAN obsolete now that we have industrial Ethernet? No. CAN and especially CAN FD remain the cheapest robust way to connect many small nodes (grippers, sensors, battery systems, low-cost axes) with excellent noise immunity and a controller in nearly every microcontroller. CAN FD's 64-byte frames and multi-Mbit data phase closed much of the bandwidth gap. Many robots run EtherCAT for the fast axes and CAN FD for everything else.

What problem does TSN actually solve? Convergence. TSN is a set of IEEE 802.1 amendments (time sync, time-aware scheduling, frame preemption, seamless redundancy) that make standard switched Ethernet deterministic, so hard-real-time control traffic and best-effort video or file transfer can share one switch fabric without the control traffic ever waiting. It lets you collapse the old split between a dedicated control network and a separate IT network.

How does safety data travel on the same network as normal control? Through the black-channel model. A certified safety protocol (FSoE on EtherCAT, PROFIsafe on PROFINET, CIP Safety on EtherNet/IP) runs on top of the ordinary bus and detects delays, drops, duplicates, and corruption itself using sequence numbers, watchdogs, connection IDs, and an independent CRC. The underlying network needs no safety certification, and the safety function reaches up to SIL 3 / PLe.

Can a wireless link carry a robot's control loop? No. Wi-Fi, 5G, and UWB carry goals, telemetry, video, and position fixes, all in the coordination and enterprise rings. The hard control loop stays onboard, closed over the robot's internal field bus. A well-designed mobile robot stays safe and controllable through a complete loss of radio, because radio loss is a normal event to plan for.

What is a good cycle time and jitter target for a robot arm's field bus? A 1 kHz (1000 microsecond) cycle with jitter in the low single-digit microseconds is a solid default for a typical industrial or collaborative arm, since the joint mechanical bandwidth is tens of hertz and you want the loop 5-10 times faster. High-performance machines push to 250 or 125 microseconds. The bus itself is usually a small fraction of the budget; the control PC's real-time scheduling is the harder constraint.

Do I need managed switches for PROFINET or EtherNet/IP? For anything beyond a trivial setup, yes. Real-time and redundancy features (PROFINET IRT scheduling, MRP rings, EtherNet/IP DLR rings, and any TSN capability) require managed, protocol-aware switches. Unmanaged switches can pass basic traffic but give you no determinism guarantees and no ring redundancy, and mixing IT traffic onto them is a common cause of intermittent control faults.

Where does Single Pair Ethernet fit? SPE (10BASE-T1L and 10BASE-T1S) runs Ethernet plus power over one twisted pair, reaching long distances or short multidrop segments to simple sensors and actuators. Its promise is to push IP and TSN all the way to the smallest devices, collapsing the layers that used to justify a separate low-level field bus. It is emerging in 2026 rather than dominant, but it is the direction the bottom of the stack is heading.