Part I · Chapter 3

The Request–Response Cycle

Every Modbus exchange is a small, predictable ritual: a question with a known shape, and an answer that is either the data you wanted, a clear refusal, or nothing at all.

The shape of a request

Every request carries three things:

1. Which server: the unit address (also called unit ID, or slave address in older documents).
2. What to do: the function code, a small number that means "read holding registers," "write a single coil," and so on.
3. The data the operation needs: usually a starting address and a quantity, plus any values to write.

In plain language, the running example for this course says: "Server 1, perform function 3 (read holding registers), starting at address 0, for a quantity of 4." The server doesn't need to know what the registers mean. It hands back whatever is in those four slots.

The function code plus its data is the PDU (protocol data unit): the heart of the message, unchanged whichever transport carries it. The unit address and error check are wrapping added by the transport, which Part II examines byte by byte.

The shape of a normal response

When all goes well, the response echoes the function code and then supplies the result. A read returns a byte count followed by the data. A write usually echoes the address and value that were written, as confirmation the command took effect.

The echo is more useful than it looks: the client can confirm the server performed the operation it asked for, and a write's echo is positive proof the exact value was accepted.

When the server says no: exceptions

Sometimes a server understands a request perfectly but can't honor it: the address doesn't exist, the value is out of range, or the function isn't implemented. It doesn't stay silent and doesn't pretend to succeed. It sends an exception response.

An exception is marked so it can't be mistaken for success. The server sets the high bit of the function code, which adds 0x80: a failed 0x03 comes back as 0x83, a failed 0x05 as 0x85. One exception code byte follows, naming the problem.

Illegal Data Address (02) is the one beginners meet most, and it's almost always the addressing trap from Chapter 2 in disguise: a 4xxxx reference number that wasn't converted to its zero-based address.

The third outcome: silence

The outcome that puzzles newcomers most is no reply at all. Silence is not a refusal; it means the request never reached a working server, or the answer never made it back. The cause might be a miswired or unplugged cable, a unit address with no device behind it, mismatched serial settings, or a device that's switched off. The server never received an intelligible request, so it has nothing to say.

Timeouts, retries, and one question at a time

Because silence is possible, a client can't wait forever. Every client uses a timeout: after sending a request it waits a set interval (often a fraction of a second to a couple of seconds), then declares the request failed. Many clients retry a few times before reporting the device unreachable, since an occasional lost message on a noisy line is normal.

On a serial bus, the timeout also enforces good manners. The client sends one request, waits for the response or the timeout, and only then sends the next. It never has two questions outstanding on the same bus, because one shared pair of wires can't carry two answers without collision. That discipline makes serial Modbus easy to reason about, and it's also why reading many devices takes time.

Modbus TCP relaxes this slightly: a TCP client may have several requests in flight and uses a small identifier in each message to match answers to questions (Chapter 7). Within any single exchange the logic is the same: ask, then wait for the answer, the exception, or the timeout.

Broadcasting to everyone

On a serial network, unit address 0 is reserved for broadcast. A write sent to unit 0 is meant for every server at once, for example to set the same parameter in all devices. Since no single device owns the reply, a broadcast draws no response. The client gives up its usual proof that the command took effect, so broadcast is used sparingly and only for writes.

The polling loop

A client rarely sends one request and stops. It polls: it works through a list of things it needs to know (these registers from device 1, those coils from device 2, that measurement from device 3), handles each reply, and then starts again from the top, refreshing its picture of the system several times a second or several times a minute.

Polling is simple and predictable: at any moment the client knows exactly which exchange is happening. But data is only as fresh as the loop is fast, and a slow or unreachable device can hold up the whole cycle while the client waits out its timeout. Designing a good loop (what to read, how often, and how to keep one stalled device from starving the rest) is real work, and Part IV returns to it.