Why Industrial Protocols?
Consumer interfaces like USB and Wi-Fi are designed for IT environments — where occasional packet loss or variable latency is acceptable. Industrial and robotic control systems demand something different: deterministic latency, noise immunity, long cable runs, and fault tolerance.
Industrial fieldbus protocols were developed from the 1980s onward to address these needs. Today's robotic systems commonly encounter MODBUS, CAN bus, EtherCAT, Profibus, DeviceNet, and EtherNet/IP on the factory floor and increasingly in service robots. Understanding at least MODBUS and CAN is essential for any robotics engineer working with real hardware.
MODBUS
MODBUS is a serial communication protocol published by Modicon in 1979. It remains one of the most widely used protocols in industrial automation due to its simplicity, openness, and vendor-neutral design.
Physical layers:
- MODBUS RTU / ASCII over RS-232 (point-to-point, ≤15 m) or RS-485 (multi-drop, up to 32 nodes, ≤1200 m at 9600 baud)
- MODBUS TCP — MODBUS messages encapsulated in TCP/IP packets over standard Ethernet
Data model: devices expose four tables of registers:
| Register Type | Access | Address Range | Typical Use |
|---|---|---|---|
| Coils (0x) | R/W | 00001–09999 | Digital outputs (relays, valves) |
| Discrete Inputs (1x) | R only | 10001–19999 | Digital inputs (limit switches) |
| Input Registers (3x) | R only | 30001–39999 | Analog inputs (temperature, pressure) |
| Holding Registers (4x) | R/W | 40001–49999 | Setpoints, configuration, speed |
Master–slave model: one MODBUS master polls slaves by address (1–247). Slaves never initiate communication. Function codes define the operation: FC01 (read coils), FC03 (read holding registers), FC06 (write single register), FC16 (write multiple registers).
MODBUS Key Facts
- 01
MODBUS RTU frames include a CRC-16 checksum for error detection
- 02
RS-485 differential signalling provides high noise immunity in industrial environments
- 03
MODBUS TCP port 502 is the standard; no CRC needed (TCP provides its own error checking)
- 04
Open source libraries: libmodbus (C), pymodbus (Python), node-red-contrib-modbus
- 05
Limitations: master-slave only (no peer-to-peer), slow poll rates, no built-in security in RTU mode
CAN Bus
Controller Area Network (CAN) was developed by Bosch in 1983 and standardised as ISO 11898. Originally designed for automotive wiring harnesses to replace point-to-point wiring, CAN has become the dominant protocol in:
- Automotive ECUs, ABS, power steering, airbags
- Industrial robots (servo drives, safety PLCs)
- Medical devices (surgical robots, imaging systems)
- Aerospace (UAV telemetry, avionics)
Physical layer: a twisted-pair differential bus (CAN_H and CAN_L). Dominant bit = CAN_H − CAN_L ≈ 2 V; recessive bit ≈ 0 V differential. Standard speeds: 125 kbps, 250 kbps, 500 kbps, 1 Mbps. CAN FD extends to 8 Mbps in the data phase. Maximum cable length ≈ 40 m at 1 Mbps (up to 1000 m at 50 kbps).
Multi-master with CSMA/CR: any node can transmit when the bus is idle. Simultaneous transmissions are resolved by bitwise arbitration — the message with the lower ID (higher priority) wins without data corruption. This is a key advantage over protocols requiring a master to poll each node.
Message format: an 11-bit (standard) or 29-bit (extended) message ID identifies the content, not the sender. Any node interested in a message ID subscribes to it, similar to ROS 2 topics. Maximum payload is 8 bytes (CAN 2.0) or 64 bytes (CAN FD).
MODBUS vs CAN Bus
MODBUS
- Master–slave only; master must poll each device
- RS-485: up to 32 nodes, 1200 m; TCP: standard Ethernet
- Widely supported; almost every industrial device has MODBUS
- Simple register model — easy to integrate PLCs and HMIs
- No built-in prioritisation of messages
- Standard speeds: 9600 – 115200 baud (RTU)
CAN Bus
- Multi-master with hardware arbitration — no polling overhead
- Up to 40 m at 1 Mbps; 1000 m at 50 kbps; max 127 nodes
- Built-in priority: lower message ID = higher priority
- Excellent error detection: CRC, bit stuffing, ACK check
- Requires CAN transceiver ICs (e.g., MCP2551, TJA1050)
- CAN FD extends payload to 64 bytes at up to 8 Mbps
Other Industrial Communication Protocols
| Protocol | Physical Layer | Topology | Speed | Common Use |
|---|---|---|---|---|
| EtherCAT | Ethernet (100 Mbps) | Line / ring | 100 Mbps | High-speed servo drives, robot joints |
| Profibus DP | RS-485 | Multi-drop bus | 12 Mbps | PLC-to-sensor/actuator (process industry) |
| DeviceNet | CAN physical layer | Trunk-and-drop | 500 kbps | Factory automation (ODVA standard) |
| EtherNet/IP | Ethernet + TCP/UDP | Star / tree | 100 Mbps+ | Allen-Bradley PLCs, SCARA robots |
| IO-Link | 3-wire point-to-point | Point-to-point | 230 kbps | Smart sensor parameterisation |
| OPC-UA | TCP/IP (software layer) | Client-server | Network speed | Industry 4.0 data integration |
Wireless Communication in Robotics
Wireless protocols enable untethered robots, remote monitoring, and swarm coordination:
Wi-Fi (IEEE 802.11): standard for ROS 2 robots on local networks. 2.4 GHz offers longer range; 5/6 GHz offers higher throughput and lower congestion. Latency ~1–10 ms. Suitable for video streaming and high-bandwidth telemetry.
Bluetooth / BLE: Bluetooth Classic (2.4 GHz, ~3 Mbps) for audio/serial; BLE 5.x for low-power sensor nodes, wearables, and short-range telemetry. Range ~10–100 m.
Zigbee / Thread (IEEE 802.15.4): low-power mesh networking at 250 kbps. Suitable for distributed sensor networks and smart factory IoT nodes.
LoRa / LoRaWAN: very long range (2–15 km), very low data rate (0.3–50 kbps), low power. Used for GPS tracking of field robots and agricultural monitoring.
5G: emerging for industrial automation — ultra-low latency (<1 ms URLLC), network slicing, and massive IoT device density. Key enabler for cloud-controlled robots.