Modbus RTU: the spec numbers that matter, and what actually breaks on the floor

Almost every Modbus RTU problem I have been called out on turned out to live in one of two places: the physical layer, or the timing. Not once the protocol itself. A segment runs clean for years, then one device drops off the poll, or the whole line stalls for a second and comes back on its own, and nothing in the program changed.

Modbus RTU is not much help when that happens. There is no link light that tells you the bias resistors are sitting in the wrong place. So here are the numbers that actually decide whether a segment works, taken from the Modbus Organization's own specification, along with the failures I keep running into.

 A Modbus RTU segment daisy-chained along a shielded twisted pair. The conductor people leave off is not in the pair at all.

What Modbus RTU is, in one pass

One master, sequential polling, one device on the wire at a time. That part everybody knows. It is the details underneath that come back later.

Addressing. Address 0 is the broadcast address for writes. Individual slaves get 1 through 247. Addresses 248 to 255 are reserved, so do not get creative with them.

Four data tables, split by width and by direction: discrete inputs are single-bit read-only, coils are single-bit read/write, input registers are 16-bit read-only, holding registers are 16-bit read/write. That comes from the MODBUS Application Protocol Specification V1.1b3.

Character format. Each RTU character is 11 bits on the wire: one start bit, eight data bits sent least significant bit first, one parity bit, one stop bit. Per the MODBUS over serial line specification and implementation guide V1.02, the default parity mode must be even. Run with no parity and you use two stop bits instead of one.

Baud rate. A compliant device has to support 9600 and 19200, and 19200 is the required default. Everything else, from 1200 up through 115200, is optional.

Frame size. 256 bytes maximum for the whole frame, with the data field running from 0 to 252 bytes.

Now the part that burns people, and it falls straight out of that parity paragraph. The spec default is even parity. Plenty of real equipment ships set to 8-N-1 instead. Rockwell configures compact-class PowerFlex drives that way on a Modbus link. Master on the spec default, drive on 8-N-1, and the character framing does not line up. You get silence or garbage, and nothing tells you why.

A Modbus RTU segment takes three wires, not two

Everyone wires the twisted pair. The conductor that gets left off is the common. The serial line spec is not vague about it: a third conductor must interconnect all the devices on the bus. It also says that common should tie to protective ground, preferably at one point only.

Leave it out and the segment usually works anyway. Right up until two devices end up on separate power supplies with a couple of volts of offset between their grounds. Now the receivers have no shared reference, and you get intermittent garbage that follows no pattern you can chase.

Termination and bias, with the real values

This is where I find the most wrong numbers in panels that are already running, usually copied off a screen years ago and never questioned since.

What	Value from the serial line spec
Line termination	150 ohms, 0.5 W, across D0 and D1 at each end of the trunk
Termination with polarization	120 ohms, 0.25 W, in series with a 1 nF capacitor rated 10 V minimum. The spec calls this the better choice
Bias resistors	450 to 650 ohms. The 650 ohm value allows a higher device count
Bias location	One place on the bus only, normally at the master
Trunk length	1000 m at 9600 baud with AWG26 or wider
Derivation (stub) length	Never over 20 m. With a multi-port tap of n derivations, 40 m divided by n each
Devices per segment	32 without a repeater

 

Two of those catch people. The bias resistors are hundreds of ohms, not thousands. I have opened panels with 10k sitting in that spot. It biases nothing useful and the pair floats between transmissions. Second, bias goes in one location. Fit it at every device and you load the bus down until the drivers cannot pull the pair far enough apart to be read.

Termination goes at the two ends of the trunk and nowhere else, never on a stub. And on a two-meter run inside a single cabinet I have had better results pulling the terminators out than putting them in. The reflection you are terminating for does not exist at that length. The load does.

Termination at both ends of the trunk, bias at a single location, and the common grounded at one point.

The timing rule that decides whether a frame counts at all

Modbus RTU has no start character and no end character. Framing is silence, which makes timing a functional part of the protocol rather than a tuning preference.

The rule: more than 1.5 character times of silence between two characters and the receiving device declares the frame incomplete and discards it. Between one complete frame and the next, the gap has to run at least 3.5 character times.

Above 19200 bps the spec stops working in character times and hands you fixed numbers: 750 microseconds for the inter-character timeout, 1.750 milliseconds for the inter-frame delay.

What that means in a panel is that anything inserting a gap mid-frame kills the frame silently. A USB serial converter with aggressive buffering will do it. So will a gateway that wanders off to service another port mid-transmission, or a soft serial implementation running on a master that is busy with something else. The device on the far end is behaving correctly when it throws those frames away, which is exactly why nothing logs an error worth reading.

When a master starts missing responses, the first setting I change is the turnaround delay, the pause between receiving a reply and firing off the next request. A lot of drivers default it to zero. Ten milliseconds costs nothing on a poll loop. It also clears up a fair number of "that one device is flaky" complaints, because some slaves need a moment for their transmitter to let go of the line.

CRC byte order, the one that eats a day

The checksum is a CRC-16. Register preset to 0xFFFF, polynomial 0xA001, shift right and XOR across each byte.

Then the part that costs people an afternoon: the low-order byte of the CRC goes on the wire first, followed by the high-order byte. Every other 16-bit value in a Modbus RTU message is sent most significant byte first. The CRC is backwards from all of it.

With a stock driver you will never meet this. If you are hand-rolling the CRC, and people do, on an embedded target, inside a custom master, or assembling the frame byte by byte out of ladder into a serial module, this is where it goes wrong. The polynomial is right, the loop is right, the two bytes are swapped, and every frame you send gets discarded with no error code at all, because a bad CRC is not an exception. It is a frame that never happened.

Check the byte order before you check anything else in that code. Most of the time it is the whole problem.

When the device answers, but with an exception

An exception is easy to spot on a trace once you know the rule: the exception function code is the request function code plus 0x80. Ask for holding registers with 03 and get 83 back. The byte after it tells you why.

Code	Name	What it usually means in practice
01	Illegal function	The device does not implement that function code
02	Illegal data address	The register is not there. Usually an offset mistake
03	Illegal data value	The value, or the quantity requested, is out of range
04	Server device failure	Unrecoverable error inside the device
05	Acknowledge	Long command accepted, poll again later
06	Server device busy	Device is tied up with a long program command
08	Memory parity error	Parity error detected in the device memory
0A	Gateway path unavailable	Gateway could not allocate a communication path
0B	Gateway target device failed to respond	Gateway got nothing back from the target device

 

Code 02 is the one you will actually see, and it is almost always the Modicon numbering offset. A device documents a holding register as 40108. Holding register addressing starts at 40001, so the value that belongs in the frame is 107. Not 108, and definitely not 40108.

The other limit worth knowing is request size. The application protocol spec caps a single read at 125 registers for function codes 03 and 04, and at 2000 bits for 01 and 02. On the write side it is 123 registers for function code 10 and 1968 coils for 0F.

But the spec ceiling is not the ceiling you will hit. Plenty of devices carry their own lower limits that no datasheet mentions. I have had gear answer a four-register read cleanly and give nothing at all, not even an exception, on five. So if a read works at one length and times out at another, stop looking at the wiring and start changing the request length. That behavior is not a physical fault, and no amount of re-terminating will fix it.

Modbus RTU next to Modbus TCP

	Modbus RTU	Modbus TCP
Physical layer	RS-485 or RS-232: twisted pair plus a common conductor	Ethernet
Topology	Daisy chain along a trunk, short stubs only	Star, through switches
Error checking	CRC-16 carried in the frame	Handled by Ethernet, no CRC in the Modbus frame
Framing	Silence: 1.5 and 3.5 character times	MBAP header with an explicit length field
Port	Not applicable	TCP 502
Device count	32 per segment without a repeater, addresses 1 to 247	Limited by the network. Unit ID is still 1 to 247 behind a gateway
Requests in flight	One at a time, strictly sequential	Multiple connections at once

 

Modbus TCP is the easier network to build and far easier to diagnose. It is also not what is already installed in the machine you were sent to fix, and that is the whole reason it is still worth knowing properly.

Modbus RTU on Allen-Bradley hardware

Rockwell does not treat Modbus as a first-class network the way it treats EtherNet/IP. The support is there in more places than people expect. The limits are what you want to know before you plan around it.

PowerFlex 520-series drives speak Modbus RTU over the RJ45 DSI port. Node address is the usual 1 to 247. Rockwell configures these for RTU 8-N-1 on a Modbus link and documents 19200 baud as the fastest rate available on that connection. Publication 520-UM001 covers reads with function code 03 and writes with 06. That points at a drive you poll for status and command with single-register writes, rather than one you push a block of registers into.

Two practical notes out of Rockwell's own guidance for these drives. A changed data rate or node address does nothing until the drive gets a power cycle. And termination on the DSI network is a specific part: the AK-U0-RJ45-TB2P two-position RJ45 terminal block, with a 120 ohm resistor in it. Belden 3105A is the recommended cable, shield grounded at one end only.

A PowerFlex 525. On a Modbus link it answers reads with function code 03 and takes commands with single-register writes on 06.

MicroLogix 1400 controllers handle Modbus as either master or slave, per publication 1766-RM001, and the 1766-L32BWA carries a combined RS-232/RS-485 port, so getting onto the pair does not cost you a converter.

ControlLogix and CompactLogix have no native serial Modbus. That is where a Point I/O serial module earns its keep. The ILX34-MBS485 sits in a 1734 Point I/O rack and takes care of the RS-485 side. Going by the catalog listing it runs from 110 up to 38.4 kbps, with capacity for roughly 1000 words. That matches how these get used in practice: one drive network, or a bank of meters. Not a plant backbone.

An ILX34-MBS485 puts an RS-485 Modbus RTU port on a 1734 Point I/O rack, which ControlLogix and CompactLogix do not have on their own.

When the answer is to stop extending the serial network and bridge it instead, a protocol gateway does that job. A PLX31-EIP-MBS puts the serial devices behind an EtherNet/IP connection so the controller reads tags rather than issuing serial reads. A PLX51-PBM does the same trick from the Profibus DP side.

A PLX31-EIP-MBS gateway hands the serial devices to the controller as tags instead of serial reads.

Frequently asked questions

What is Modbus RTU used for?

Polling data out of field devices on a serial line and writing setpoints back into them: drives, power meters, flow meters, temperature controllers, protection relays. It is old and it is simple. Almost everything industrial speaks it, which is why it still turns up on brand new equipment.

Why do Modbus RTU devices stop responding at random?

In my experience, in roughly this order: a missing or badly grounded common conductor, bias resistors in the wrong place or the wrong value, a mid-frame gap from a converter or a busy master breaking the 1.5 character time rule, and a turnaround delay of zero on the master. Real hardware failure of an RS-485 transceiver does happen, but it is well down the list. When one line of the pair sits at the wrong level with the bus idle, that is when I start suspecting a blown driver.

How many devices can go on one Modbus RTU segment?

32 without a repeater. Some devices document support for more than that, but 32 is the number the serial line spec guarantees on any RS-485 Modbus system. Addressing tops out at 247 regardless, and reaching that takes repeaters.

Do I need termination resistors on a short Modbus RTU run?

On a couple of meters inside one enclosure, usually not, and the extra load can cost you more than the reflection ever would. Out on a real trunk run, put a terminator at each end and leave the stubs alone.

What is the difference between Modbus RTU and Modbus TCP?

RTU is the serial version: RS-485, a CRC inside the frame, framing by silence, one request at a time. Modbus TCP wraps the same register model in Ethernet on port 502 and drops the CRC, because Ethernet already checks the frame. The register map and the function codes are identical between them, which is what makes a gateway between the two straightforward.

In stock, tested, and backed by a 2-year warranty

Most of the Modbus RTU networks I get called out to look at are running on hardware that has not been built in a decade, and the fix is usually one drive, one serial module, or one gateway rather than a redesign. IQElectro keeps tested Allen-Bradley and ProSoft communication hardware in stock, each piece with a 2-year warranty. Send the part number off the label and you get a quote with compatibility checked first.