Modbus
Modbus provides request/response operations over a simple data model. Its usefulness depends on a precise device register map: which address to read, which function to use, how to decode the result, and what the value means.
Start with documented, approved read access in a controlled environment. Keep addressing, transport framing, byte order, polling behavior, and network access as separate checks. A valid response can still be the wrong measurement, and a successful read does not justify a write to industrial equipment.
TL;DR
- Modbus is a simple request/response protocol over a register data model; its usefulness depends on a precise register map.
- For each value, know the address, function code, decoding (type, byte and word order, scale), and meaning.
- Reference numbers in device manuals (such as 40001) often differ from protocol offsets, so document the conversion.
- Treat addressing, framing, byte order, polling rate, and network access as separate checks.
- Start with approved read-only access; a successful read never justifies writing to industrial equipment.
Quick Example
This offline Python example constructs a Read Holding Registers request PDU and decodes four fictional response-data bytes. The fixture declares a particular float representation and word order. It does not connect to a device or implement a complete transport frame.
Test positive, negative, and zero values, swapped-word inputs, and malformed lengths the same way. The first interpretation yields 25.0; swapping the words changes the interpretation despite using the same four bytes.
No serial port, socket, MBAP header, RTU CRC, response matching, exception response, polling loop, device map, or network isolation was tested. The example's count of two and offset of zero are fictional. They are not a device-discovery recipe or permission to query operational equipment.
Core Concepts
The data table and operation identify the request
The Modbus application specification defines single-bit coils and discrete inputs, plus 16-bit input and holding registers. Function codes select operations: 0x03 reads holding registers, while 0x04 reads input registers. Protocol addresses are zero-based; a device manual's displayed reference notation needs an explicit mapping to the client's API. Modbus application specification, sections 4 and 6.
Record the device model and firmware alongside its register map. Include the table, documented reference, protocol offset, count, access mode, representation, unit, and scale. Do not fix an unexpected value by trying neighboring write addresses. Resolve the documented mapping in a controlled test first.
Serial and TCP carry the application differently
Modbus TCP uses an MBAP header around the application PDU. Its transaction identifier helps associate a response with a pending request, and length information defines message boundaries. Serial RTU has different framing requirements. A PDU alone is therefore neither a complete TCP request nor a complete RTU frame. Modbus TCP implementation guide, section 3.1.
Use a maintained implementation appropriate to the transport rather than extending this illustration into a production client. Test response association, partial input, timeout, reconnect, and gateway addressing with the actual library and device arrangement. The presence of TCP does not eliminate application-level timeout or data-interpretation work.
Byte order and measurement meaning are separate
The application specification sends the high byte first for a register-sized quantity. That rule does not supply the application's complete contract for a multi-register float, signed integer, scale, or sentinel. The fixture above chooses a high-word-first binary32 representation explicitly; the actual device documentation must supply the corresponding choice. Modbus data encoding.
Polling is an operating workload
Set the polling interval from the consumer's need and the equipment's supported behavior. Include gateway contention, other clients, retries, and how long a value remains usable. A short interval does not guarantee a fresh underlying observation if the device updates its own measurement more slowly.
Bound retries and outstanding work. After repeated failures, expose unavailable or stale state rather than continuing to present the last value as current. The protocol defines exception responses as distinct from normal responses; application handling should preserve that distinction instead of converting every failure to a zero measurement. Modbus exception responses.
Best Practices
Verify a mapping before expanding collection
Choose a known, non-sensitive test signal with the OT owner's approval. Compare multiple documented observations and account for units, scale, signedness, and word order. Retain the map revision and expected interpretation. One correctly decoded sample is a starting point, not proof that every register follows the same representation.
Expand collection only after reviewing load and failure behavior. Avoid broad network scanning, aggressive polling, or writes as exploratory tools on operational equipment. Those actions can have consequences that a byte-level example cannot model.
Make network access deliberate
Constrain which approved systems can reach the industrial endpoint and which paths cross between OT and other networks. Review gateway and firewall rules with the responsible OT/security owners, including remote access and change-window requirements. Read-only application intent alone does not enforce a read-only network boundary.
Do not assume ordinary Modbus TCP supplies authenticated, encrypted communication. The Modbus Organization documents a separate Modbus Security protocol using TLS and certificates. Verify actual device, client, and gateway support before making a security claim; the existence of that specification does not upgrade a plain connection automatically. Modbus specifications and Security overview.
Test failure without touching the plant
Use an approved simulator or isolated bench setup to exercise delayed, missing, malformed and exception responses. Check that retry behavior stays bounded and the consumer's displayed quality changes as intended. Capture enough diagnostic context to distinguish mapping errors from transport failures.
Keep write operations under a separate, reviewed requirement with explicit device, value, range and operational authority. A read integration should not acquire write privileges merely because the chosen library supports them. Reevaluate the approach if the device cannot support the required access restrictions or workload.
Common Mistakes
Confusing reference numbers with protocol offsets
Blaming every wrong value on endianness
Polling faster for responsiveness
Exposing an endpoint because you only read
FAQ
Are holding registers always writable in practice?
The protocol data model includes read/write holding registers, but a device's supported operations and individual map determine what is actually available. Verify the vendor documentation and enforce the application's approved access scope.
Why can the same bytes decode to different values?
The representation contract may differ: word order, numeric type, signedness, scale or units. The example deliberately changes one choice. Use multiple known observations and the device map rather than choosing whichever interpretation looks convenient.
Can I use this example as a Modbus client?
No. It illustrates PDU bytes and a declared float interpretation offline. A working client needs supported framing, transport, validation, response handling and operational controls, followed by tests with the intended implementation and approved equipment.