Modbus RTU¶

Industrial state appears through polling, register maps, and silence gaps.

A Concrete Artifact¶

# synthetic observed master request: read three holding-register-like values
11 03 00 6b 00 03 76 87

# synthetic observed slave response
11 03 06 02 2b 00 00 00 64 c8 ba

Synthetic offline sample for explanation; not a real operational trace or live-system instruction.

Inspection Trap¶

A Modbus frame can reveal a clean request and response while hiding the thing most readers want: engineering meaning. The trap is to treat a register offset and function code as pressure, state, setpoint, or device truth without the register map and polling context.

This page inspects synthetic observed request/response bytes as passive evidence. Modbus RTU is interrogative observation: the master asks, the response is observed, and the observer must keep register-map authority separate from bytes. It teaches address, function, data, CRC, silent-interval framing, register-map authority, and the visibility limits of master-driven polling.

Worked Decode¶

1. Address 0x11 selects the slave in this synthetic transaction.
2. Function 0x03 is treated as a read-holding-register-style observed request in the teaching model.
3. Start address 0x006b and quantity 0x0003 ask for three register values.
4. CRC bytes 76 87 protect the observed request frame shape. They do not identify the meaning of the registers.
5. The observed response repeats address and function, gives byte count 0x06, then returns three 16-bit values: 0x022b, 0x0000, and 0x0064.
6. A register map may define those as pressure, state, setpoint, firmware value, or something else. Without the map, they are holding-register-like values only.
7. Register 0x006B on the wire is not necessarily "register 400108" in a manual. Documentation bases, display conventions, and zero-vs-one indexing differ.

What The Evidence Supports¶

• The artifacts support observed address, function-code, start-address, quantity, byte-count, register-value, and CRC evidence.
• The request/response pair supports transaction-shape reasoning for a synthetic function 0x03 read.
• CRC protects the frame shape while holding-register-like values remain map-dependent.
• A sequence of observations can support poll cadence, response latency, exception, missing-reply, and freshness hypotheses.

What The Evidence Does Not Support¶

• The artifacts do not name engineering units, device state, register semantics, or the full hidden state of the device.
• They do not teach live polling, writing, serial-port setup, gateway configuration, or device manipulation.
• They do not settle documentation base-address conventions or vendor register-table meaning.

Field Layout / Anatomy¶

Visual Model¶

Timing And Authority¶

Modbus RTU authority is master-driven polling. The master decides what is visible by choosing slave, function, register range, and cadence. Semantic authority comes from device register maps and function-code definitions. Polling cadence shapes visibility: a value can be stale because it was not polled, not because it stopped changing.

In RTU, timing is part of the frame boundary. The bytes alone show address, function, data, and CRC; the silent interval tells the parser where one frame ends and the next begins. A capture that loses gap timing can still contain the right bytes while obscuring transaction boundaries.

Bytes rarely explain themselves. Name the source that defines meaning before naming engineering values: standard metadata, label table, DBC, PGN/SPN definition, object dictionary, register map, DID catalog, LDF, ARXML, channel metadata, or vendor profile.

Failure And Ambiguity¶

• Register-address bases differ between documentation and wire offsets, creating off-by-one mistakes.
• Function code 0x03 tells register class, not engineering meaning.
• CRC protects the frame shape, not the physical truth of a returned value.
• Exception responses can be misread as ordinary data if the function-code high bit is ignored.
• A passive observer sees only what was asked; unpolled state remains invisible.
• Serial timing gaps, half-duplex direction control, and gateway buffering can distort transaction boundaries.

Python Model¶

The current package exposes concrete observed-frame inspection examples:

"""Runnable Modbus RTU frame inspection example for the schoolbus binder."""

from schoolbus.protocols.modbus import ModbusRtuFrame

request = ModbusRtuFrame.from_hex("11 03 00 6b 00 03 76 87")
response = ModbusRtuFrame.from_hex("11 03 06 02 2b 00 00 00 64 c8 ba")

print(request.show_fields())
print(request.as_read_holding_registers_request().show_fields())
print(response.as_read_holding_registers_response().show_fields())
print(response.explain())

The model parses captured RTU bytes, shows CRC evidence, and provides read-register shape helpers for observed function 0x03 traffic. It does not open serial ports, poll devices, or turn register offsets into engineering units without register-map authority.

The first workbook sample pack includes passive synthetic Modbus RTU fixtures under samples/first-workbook/ for observed request, response, and bad-CRC frame inspection.

Source Notes¶

Source confidence: High for transaction shape, register-authority framing, and source notes. Device-specific semantics remain map-dependent.

The observed request and response are synthetic. The page avoids write workflows, device manipulation, vendor register tables, exception-code exhaustiveness, serial-line electrical compliance, and gateway configuration guidance.

References¶

Public Sources¶

• Modbus Organization
• MODBUS Application Protocol Specification V1.1b3 — canonical-standard.
• Modbus specifications — official-public.
• Tooling references
• libmodbus — Modbus RTU/TCP.
• pymodbus — Modbus client/server.
• pyserial — Serial port IO.

Project posture is aggregated in the protocol support policy, source policy, and project charter.