# Modbus and RS485 for robot cells: a practical guide

> Wire RS485 correctly, understand registers and function codes, poll a drive from Python, and read Modbus exception codes in a robot cell.

Canonical: https://roboticsengineering.in/modbus-rs485-robotics-guide/ | Published: 2026-10-28 | Updated: 2026-10-28 | Author: Jignesh Panchal

**Half the devices in an Indian robot cell speak Modbus over RS485 before they speak anything modern.** VFDs, energy meters, temperature controllers, barcode readers and older PLCs all expose the same register model.

This guide covers the wiring that makes RS485 reliable, the register types and function codes you need, a working Python poller, and the exception codes that turn a failed read into a useful diagnosis.

## Why Modbus still wins in robot cells

Modbus is old, slow and simple, and those are advantages when you must integrate equipment from five vendors. The protocol is public, the messages are short, and almost every industrial device implements it. A conveyor VFD from one brand, a weighing indicator from another and a Modbus energy meter can all sit on one pair of wires, with the robot controller polling them.

- Two wires, multi-drop, up to 247 addresses on one bus.
- A register model that maps directly to device parameters.
- Works over RS485 for long runs and over TCP for modern networks.
- Every PLC, HMI and gateway supports it, so spare parts are not a problem.

## The electrical layer is where projects fail

RS485 is a differential pair, usually labelled A and B, sometimes D+ and D-. Labels are inconsistent between vendors, and swapping them is the single most common commissioning error. If a device does not answer, swap the pair before changing anything else.

| Parameter | Typical setting | Effect |
| --- | --- | --- |
| Baud rate | 9600, 19200, 38400, 115200 | Must match exactly on every node |
| Data bits | 8 | Almost universal |
| Parity | None, even or odd | Must match; even parity is common on drives |
| Stop bits | 1 or 2 | Two is common with no parity |
| Termination | 120 ohm at both ends | Needed above a few metres or high baud |
| Bias resistors | One set on the master | Keeps the idle state defined |

At 9600 baud a few hundred metres of cable is realistic. At 115200 the practical limit drops to tens of metres and termination stops being optional. Robots add a second problem: VFD output cables radiate switching noise, so route the RS485 pair away from motor cables, use shielded twisted pair with the shield bonded at one end, and prefer isolated converters.

- Daisy-chain the devices; a star topology with long spurs causes reflections.
- Use one 120 ohm resistor at each physical end of the chain, not on every device.
- Connect the signal ground or the shield reference between nodes; a floating pair drifts outside the common-mode range.
- Use an isolated USB converter on a laptop, especially when the laptop is also connected to a robot controller.
- Label every device with its Modbus address, baud, parity and stop bits before it goes into the panel.

## The register model in plain terms

Modbus exposes four tables. Each holds 16 bit values, addressed from zero or one depending on the vendor’s documentation, which is another classic source of off-by-one errors.

| Table | Access | Typical use |
| --- | --- | --- |
| Coils | Read and write bits | Start, stop, reset, enable commands |
| Discrete inputs | Read bits | Limit switches, drive ready, fault contacts |
| Input registers | Read only | Measured speed, current, temperature |
| Holding registers | Read and write | Setpoints, parameters, configuration |

Everything is 16 bit, so a 32 bit value occupies two registers and the word order is vendor-specific. A frequency of 50.00 Hz might appear as 5000 with a documented scale factor of 100. Read the device manual’s register table before writing code; guessing the scaling is how a drive gets commanded to 5000 Hz.

| Code | Function | Use in a robot cell |
| --- | --- | --- |
| 01 | Read coils | Check run and fault bits |
| 02 | Read discrete inputs | Read sensor states |
| 03 | Read holding registers | Read parameters and setpoints |
| 04 | Read input registers | Read live measurements |
| 05 | Write single coil | Issue a start or stop command |
| 06 | Write single register | Set a speed reference |
| 15 | Write multiple coils | Send a command word |
| 16 | Write multiple registers | Send several setpoints at once |

## A working poller in Python

pymodbus is the quickest way to test a device before writing PLC code. The example below reads four holding registers from a drive at address 1, then writes a speed setpoint.

```
from pymodbus.client import ModbusSerialClient

client = ModbusSerialClient(
    port="/dev/ttyUSB0",
    baudrate=19200,
    parity="E",
    stopbits=1,
    bytesize=8,
    timeout=1,
)

if not client.connect():
    raise SystemExit("no port")

rr = client.read_holding_registers(address=0, count=4, slave=1)
if rr.isError():
    print("read failed", rr)
else:
    print([hex(v) for v in rr.registers])

client.write_register(address=10, value=1500, slave=1)  # 15.00 Hz
client.close()
```

Run this against real hardware before designing the cell sequence. It confirms the port, the baud, the parity, the address and the register map in one step, and every one of those five things fails in a different way. A timeout means wiring, baud or address. An exception response means the register does not exist or is not writable.

```
# read a 32 bit value from two registers
rr = client.read_holding_registers(address=100, count=2, slave=1)
hi, lo = rr.registers
value = (hi << 16) | lo
```

## Polling design for a live robot cell

Modbus is request-response, so a careless poller stalls the machine. Two rules keep it responsive: read in blocks and never poll faster than the device can answer.

- Read contiguous registers in one request instead of one request per value.
- Poll status at 5 to 10 Hz, not at control loop rate.
- Set timeouts to two or three character times plus processing, and treat a timeout as a fault after a small retry count.
- Keep the poll list in configuration, not in code, so commissioning does not need a rebuild.
- Log every exception response with the function code and the register address.

| Exception code | Meaning | What to check |
| --- | --- | --- |
| 01 | Illegal function | Device does not support that function code |
| 02 | Illegal data address | Register number wrong or off by one |
| 03 | Illegal data value | Setpoint outside the allowed range |
| 04 | Slave device failure | Device fault; read its status register |
| 06 | Slave device busy | Polling too fast or a long internal task |
| 11 | Gateway target failed | Downstream device offline |

## A conveyor and robot handshake

The most common integration in an Indian cell is a robot picking from an indexing conveyor. The robot must not reach while the belt moves, and the belt must not index while the robot is in the cell. Modbus gives you the signals; the sequence has to be designed.

- Robot sets a “part present acknowledged” coil after a photo-eye triggers.
- Conveyor drive stops on the index sensor and reports “at position” in a status register.
- Robot reads “at position” and the safety zone clear bit before entering.
- Robot sets “pick complete”, and only then does the conveyor resume.
- Both sides time out after a defined period and raise a fault rather than waiting forever.

Write the sequence as a state machine on both sides, with explicit timeouts. A handshake that relies on one side being faster is not a handshake, it is a race that works until the day it does not.

## Buying RS485 hardware in India

- Buy an isolated USB-RS485 converter; non-isolated units are cheaper and die with the laptop when a drive faults.
- Keep a screw-terminal breakout and a short cable for bench commissioning.
- Use shielded twisted pair for runs inside a panel with VFDs.
- Prefer devices with documented register maps over ones with a proprietary configuration tool and no manual.
- Buy spares of the converter, not the drives; the converter is the part that gets plugged into the wrong port.

Related: [industrial Ethernet for robot cells](https://roboticsengineering.in/industrial-ethernet-robots-ethercat-profinet/), [PLC versus robot controller](https://roboticsengineering.in/plc-vs-robot-controller/), [PLC programming for beginners](https://roboticsengineering.in/plc-programming-beginners-india/), [CAN bus for robots](https://roboticsengineering.in/can-bus-robotics-guide/), [machine tending robots](https://roboticsengineering.in/machine-tending-robots-india/).

**Is Modbus RTU or Modbus TCP better for a robot cell?**

RTU over RS485 is cheaper and simpler for a handful of devices on one cable. TCP is easier to route through switches and does not need termination, but adds network configuration and latency considerations. Many cells use RTU locally and a gateway to TCP for the cell network.

**Why does my Modbus device time out?**

Check the port, baud rate, parity, stop bits, slave address and wiring order, in that sequence. A swapped A and B pair produces silence, and a parity mismatch produces silence with occasional garbage frames.

**What does the 40001 register number mean?**

It is a documentation convention for the first holding register. In code, addresses usually start at zero for that same register. Confirm the convention in the device manual before writing values.

**Should RS485 be terminated?**

At both ends of the chain, with 120 ohm resistors, once the cable is long or the baud rate is high. Short bench cables often work without termination, which is why failures appear after installation.

**Can I put the robot controller on the same RS485 bus as the VFD?**

Only if the robot controller has a Modbus master or slave interface and the bus timing is respected. Often a small gateway or PLC is a cleaner master than the robot controller.

Modbus RTU is still the cheapest way to read an older machine, and the [IIoT monitoring guide](https://roboticsengineering.in/iiot-machine-monitoring-india/) shows where it fits in a retrofit.

## Sources and further reading

- [Modbus Organization specifications](https://modbus.org/specs.php) — application protocol and serial line guidelines.
- [pymodbus documentation](https://pymodbus.readthedocs.io/) — client APIs for RTU and TCP.
- [Linux serial driver documentation](https://www.kernel.org/doc/html/latest/driver-api/serial/index.html) — port configuration reference.