Modbus RTU

How a transaction works

The master sends a request containing a slave address, a function code, a starting register, a quantity, and a CRC. The addressed slave, and only that slave, responds with the same address, the same function code, the data, and its own CRC. Every other device on the bus stays silent. Nothing happens without the master initiating it.

That single-conversation model is why a device that answers slowly slows the whole bus, and why one device that transmits when it should not can make an entire segment appear broken.

Function codes you will actually use

The addressing problem

This causes more wasted hours than every other Modbus issue combined. Two conventions describe the same register and documentation rarely says which is in use.

Traditional data model addressing

Holding registers are numbered from 40001. A device manual saying "flow rate is at 40010" is using this convention.

Protocol addressing

The number actually placed on the wire, starting at 0. Register 40010 in the traditional model is protocol address 9.

Traditional 40001  ->  protocol address 0
Traditional 40010  ->  protocol address 9
Traditional 4xxxx  ->  protocol address (xxxx - 1)

Off by exactly one register  -> you configured 40010 as address 10
Reading 40001 as address 40001 -> illegal data address exception

If a value is close but consistently belongs to the neighboring
point in the device map, you are off by one.

Data types and byte order

Modbus defines 16-bit registers and nothing larger. A 32-bit float or a 32-bit integer is carried in two consecutive registers, and the standard does not specify the order in which those registers appear. Vendors differ, and some devices are configurable.

A practical test: read a value you know, such as a flow rate the device displays locally. If it reads as a huge number, a near-zero number, or nonsense, try swapping the word order first. The correct combination becomes obvious immediately.

The physical layer

RS-485 is a differential pair, and most intermittent Modbus problems are physical rather than protocol.

• Daisy chain the devices. RS-485 is a bus, not a star. Long stubs off a trunk cause reflections.
• Terminate both physical ends, typically 120 ohms. Terminate only the ends, not every device.
• Bias the idle line somewhere on the segment, usually at the master. Without bias, an idle line floats and receivers see noise as data.
• Use twisted shielded pair rated for RS-485, and ground the shield at one end.
• Connect the signal common. Many installations skip this and work until the ground potential difference grows.
• Verify polarity. A and B reversed at one device produces silence from that device only.
• Keep it away from drive output conductors. This is the leading cause of a bus that works until a pump starts.

Exception responses

An exception is good news compared with silence. It proves the device heard you, the wiring is correct, the address is right, and the framing is valid. Only the content of the request is wrong, which is a much smaller problem than a bus that does not answer at all.

Timing and polling

Frames are delimited by silence: a gap of at least 3.5 character times marks the end of a message, and a gap of more than 1.5 character times inside a message invalidates it. This is why a gateway or a USB serial converter that introduces latency can break RTU framing even though the bytes all arrive.

• Poll no faster than the device can answer. Many field devices need tens of milliseconds per response.
• Read contiguous blocks rather than individual registers. One read of twenty registers is far cheaper than twenty reads.
• Set the response timeout longer than the slowest device, then set retries deliberately rather than leaving a default.
• Count and trend communication errors per device. A device at a 2% error rate today is a failure next month.