RS-485 & Modbus. How Industrial Hardware Has Been Talking Since 1979

Go to any factory floor, open any electrical panel, look at any industrial energy meter, VFD, PLC, or flow controller from the last 30 years. there's a very high chance you'll find a terminal block with two wires labelled A and B (or + and −, or D+ and D−, depending on who made it). That's RS-485.

RS-485 is not a protocol. It's an electrical standard. It tells you what voltages to use, what impedances the drivers and receivers must have, how many devices you can put on one cable. What's actually being sent over those wires is almost always Modbus RTU: a protocol from 1979 that has outlasted every attempt to replace it.

Why differential and why it lasts so long

Same principle as CAN: the receiver measures A−B, not A relative to ground. Noise that hits both wires equally cancels out. This is what allows RS-485 to run several hundred metres through a factory with variable-frequency drives generating kilovolts of switching transients nearby.

State      A       B      A − B
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Mark (1)  LOW    HIGH    < −0.2V
Space (0) HIGH   LOW     > +0.2V

Rendering diagram...

The 120Ω termination resistor at each end of the bus is the same story as CAN. absorbs reflections. The one thing RS-485 adds that CAN doesn't need: bias resistors. When nobody is transmitting, the A and B lines float. A floating differential pair can land anywhere, including in the undefined zone between −0.2V and +0.2V. Bias resistors (typically 560Ω–1kΩ) hold A high and B low during idle so the first byte of every transaction is received correctly.

VCC ─┤ 560Ω ├─ A  ─── device 1 ─── device 2 ─── 120Ω
GND ─┤ 560Ω ├─ B  ────────────────────────────────────

Half-duplex and the direction pin

Most RS-485 implementations are half-duplex. one twisted pair, one direction at a time. Each device has a driver-enable (DE) pin that must be pulled HIGH before transmitting and released immediately after the last bit. Hold it too long and you'll collide with the incoming response.

MCU TX ──→ RS-485 driver ──→ A/B lines
MCU RX ←── RS-485 receiver ←── A/B lines
MCU GPIO ──→ DE pin  (HIGH = transmit, LOW = receive)

Getting the DE timing wrong is a common source of corrupted responses, especially at 115200 baud or above where the bit time is under 10µs. Most UARTs have a way to automatically toggle a GPIO to control DE. worth using if yours supports it.

Modbus RTU. a world of registers

Modbus organises the devices's data as tables of 16-bit registers. The master polls slaves by address and function code. That's basically the whole model.

A typical read request:

Rendering diagram...

The frame format is simple: device address, function code, data payload, 16-bit CRC (CRC-16/IBM, LSB first). No discovery, no handshaking, no negotiation. Just ask and receive.

Common function codes:

Cabling matters more than it seems

Daisy-chain the devices. don't use a star topology. Stubs on a star cause reflections that corrupt data at speed. If a device is mounted far from the run, use the shortest stub possible (under 30cm ideally).

Termination goes at both physical ends of the cable, nowhere else. I've seen panels where someone added termination resistors at every junction "for safety" and then wondered why nothing above 19200 baud worked reliably.

Modbus RTU is not glamorous. There's no discovery, no plug-and-play, no metadata. You need the device's register map from the manual, and sometimes that manual is a 20-year-old PDF with inconsistent register numbering. But the protocol itself is extremely robust. if the physical layer is right, Modbus just works indefinitely with zero maintenance.