Modbus RTU commissioning is not complete when one register returns one plausible number. A defensible handover proves the physical bus, serial settings, unit identity, function and address, data representation, timing, quality behavior and the meaning of every published point.
This guide is a practical acceptance method. The exact device manuals and project requirements remain authoritative.
Record the contract before wiring
For every device, record the exact model and firmware, station address, baud rate, parity, data bits and stop bits. For every required point, record the Modbus data object, function code, protocol offset, documented reference notation, register count, signedness, byte and word order, scale, unit, access and expected range.
Do not store only a familiar-looking number such as 40001. Modbus protocol messages carry a zero-based offset and a function; vendor documents use several one-based or reference-number conventions. The register address translator keeps the object type and each convention visible.
Commission the RS-485 layer separately
The Modbus serial-line guide describes a trunk with devices connected along it, termination at the ends when required, one polarization location when required, and a common conductor in its two-wire and four-wire interface drawings. Device instructions decide whether termination or polarization is built in, switchable or unnecessary.
Check:
- the selected two-wire or four-wire mode and terminal naming on every device;
- one continuous trunk rather than uncontrolled star branches;
- stub lengths, repeaters and isolation boundaries;
- end-of-trunk termination, not simply “two resistors somewhere”;
- one deliberate polarization source where the network needs it;
- common, shield, grounding and surge treatment against the project design; and
- conductor identity and polarity at both ends.
Use the RS-485 termination and bias reference as a contradiction check, not as resistor sizing or signal-integrity approval.
Prove one device at a time
Start with a short, known-good segment and one slave. Confirm serial settings and read a simple documented value. Add devices progressively and retain a station list. Duplicate unit IDs can appear intermittent because two devices may answer the same request.
An exception response is evidence, not a generic communications failure. It distinguishes an addressed device rejecting a function or address from silence caused by wiring, timing, serial settings or device state. The function and exception reference preserves that distinction.
Decode values with a worked vector
A pair of 16-bit registers does not inherently define a 32-bit float. The device map must establish type, register order and byte order. Before bulk mapping, capture the raw register words for a stable value and reproduce the expected result manually. Retain that vector with the configuration so a firmware or map change can be detected.
Use the Modbus data decoder to make alternative word orders visible. Plausibility is not proof: several incorrect orders can produce small finite numbers.
Set timing from the slowest documented path
Frame timing depends on baud rate and character format. Device response time, inter-request delay, retry policy and the number and size of requests determine the full polling cycle. Over-polling can create more timeouts and less useful data.
Calculate a lower-bound serial schedule with the RTU timing tool, then test the real devices. Record p95 or worst observed response time during representative operation, not only an idle bench response.
Treat quality as data
The consuming application needs to distinguish a newly read value from a cached, timed-out, exception, out-of-range or stale value. Define:
- the source timestamp or acquisition timestamp;
- maximum acceptable age;
- retry and offline thresholds;
- whether the last value remains visible and how it is marked;
- reset and rollover treatment for counters; and
- what downstream rules do when quality is not good.
A control command needs more: request identity, authorization, acknowledgement, timeout, equipment feedback and a safe loss-of-communications state. A successful write response does not prove physical actuation.
Acceptance evidence
Retain a point-map revision, device/firmware inventory, topology sketch, serial settings, raw request/response vectors, decoded worked examples, timing observations, failure tests and the final Edge point names and units. Re-test when firmware, register maps, topology, serial settings or the polling engine changes.
For an end-to-end design, continue to the meter integration guide for a BMS or SCADA system, then open System Builder with the device list and required points.
Working out what this needs on your own site? Answer a few questions