A Clean Modbus Poll Can Still Show the Wrong Number: Commission the Register Map First

The socket opened, unit ID 1 answered, every poll came back in under 40 ms — and the compressor discharge pressure on the HMI read 6124 kPa on a machine that trips at 1200. Nothing was "down." The word order on a 32-bit float was reversed, and the driver dutifully returned a number that was internally consistent and completely wrong.

That is the failure mode nobody watches for. A broken Modbus link is easy: no response, a timeout, a red banner. A register map that polls clean but decodes wrong is the one that ends up in a trend, feeds an alarm limit, and gets believed. So treat the map as an interface you commission and sign off, not a spreadsheet you import.

Keep an evidence table for the values that matter

You are not going to bench-prove 800 tags. You don't need to. Prove the twenty or thirty that drive alarms, interlocks, and billing, and carry a small evidence table for each:

Field	Example	Why it's there
Device	Compressor PLC	Match the physical asset name, not the driver alias.
IP / unit ID	10.20.4.15 / 1	Unit ID still matters behind gateways — see below.
Register	40037	Record the vendor's convention verbatim, then translate it.
Function code	03 (holding)	Don't infer this from a 4xxxx address.
Data type	32-bit float, 2 words	Include sign and word count.
Word/byte order	CDAB	Verify against a known value, don't assume.
Scale	raw × 0.1 → kPa	Keep the equation visible in the record.
Test value	612.4 kPa @ 2026-06-10 14:20	From local display or PLC watch table.
Failure behavior	freezes at last value	Alarms and quality logic depend on this.

The table doubles as the punch list during tag creation and the first thing you open when something looks off in production eighteen months later.

Settle the addressing convention before you import anything

This is where the off-by-one lives. The MODBUS Application Protocol Specification (V1.1b3) addresses registers in the PDU as 0 to 65535 — so the very first holding register is protocol address 0. The traditional 40001 data-model reference maps to that same PDU address 0. Vendors document it every possible way: some print 40001, some print 40000, some print the raw offset 0, and a few gateways quietly subtract the base for you and a few don't.

So don't trust the datasheet — trigger a change and watch which address moves:

1. Pick one register with a value you can see on the device's local display.
2. Read it with the exact driver setting you plan to ship.
3. Read one register above and one below it.
4. Change the physical value and confirm which address tracks it.
5. Write the resolved convention into the import sheet, once, in words.

An off-by-one map produces plausible numbers, which is strictly worse than a clean comms failure — the failure gets caught in an hour, the plausible number gets caught in a incident review.

Prove word order, don't tune it until it looks right

Modbus is big-endian inside a register: the high byte comes first, and the spec is explicit about that. What the spec does not define is the order of the two 16-bit words in a 32-bit value. That gap is why you meet ABCD, CDAB, BADC, and DCBA in the wild, sometimes on two devices from the same vendor.

The wrong way to resolve it is to flip word-order settings until the number stops looking crazy — because a swapped-word float can land on a value that looks fine at that instant and diverges everywhere else. Force or observe a known value instead:

Data	Registers	What actually bites you
16-bit integer	1	Signed read as unsigned (a small negative becomes ~65000).
32-bit integer	2	Word order swapped.
32-bit float	2	Word order and byte order stacking into four combinations.
Packed status word	1	Bit 0 vs bit 1 numbering between two systems.
String	many	Byte pairing and trailing nulls.

No way to force a value? Cross-check against something independent — local HMI, a handheld meter, the drive keypad, a calibration source — and write down which one, so the evidence is repeatable and not "I eyeballed it."

Value, quality, and comms health are three different tags

A raw process value tells the operator nothing about whether to trust it. Modbus gives you no quality flag of its own, so you build one. At minimum, carry alongside every device:

• Poll success / device online.
• Timestamp of the last good poll.
• Consecutive timeout count.
• Gateway or driver diagnostic code.
• The device's own fault/status word.
• Local/remote or auto/manual state where it exists.

The hard rule that comes out of this: never let a failed read fire a process alarm. A "pressure low" that's really a dead poll is a different work order than a real low pressure, and if the operator can't tell them apart at 3am you've built a trap, not an alarm.

Commission status words one bit at a time

A single 16-bit status word can pack run, fault, warning, local mode, remote-enable, interlock, maintenance, and a comms watchdog. This is where hidden errors accumulate, because a bit map "looks done" long before any bit has actually been toggled and observed.

Bit	Name	True when	How I tested it
0	Running	Commanded and feedback present	Start from local panel in the test window
1	Faulted	Active drive fault	Vendor-simulated safe fault
4	Local mode	Local selector active	Turned selector with ops sign-off
7	Comms watchdog	Device sees client heartbeat	Stopped heartbeat in a controlled test

Confirm bit numbering in the driver before you trust the map: some import tools label bits 0–15, others 1–16, and some vendor docs number the most significant bit first. Bit 7 in the datasheet is not always bit 7 in your tag.

Scaling: don't paint precision the instrument doesn't have

Before the display or historian tags go live:

• Engineering unit matches the device doc and the HMI label.
• Raw range and scaled range are both written down.
• Negative values are allowed where they're physically real.
• Integer scaling isn't quietly truncating precision you need.
• Alarm limits are in engineering units, not raw counts.
• Historian deadband is set on the scaled value.
• Display decimals match instrument accuracy.

That last one matters more than it looks. A pressure transmitter good to ±0.25% shown at three decimals invents precision, and false precision makes a trend look more trustworthy than the sensor behind it. I set the display decimals from the instrument's accuracy class, then set the historian deadband above the noise floor — 2% on a chattery analog value beats 0.5% that fills the archive with sensor jitter nobody reads.

Poll rate is a design choice, not "as fast as possible"

Fast polling isn't free and isn't always better. Match the rate to what the value is for:

Signal	Reasonable approach
Operator display values	1–5 s is usually plenty.
Alarms / interlocks	Fast enough for the response spec — or use a protocol built for it if timing is safety-relevant.
Energy totals, counters	Slow polling is fine.
Large diagnostic blocks	On demand or a slow background rate.
Historian-only values	Match the real rate of process change.

Watch the device under load. A block that answers instantly in your test tool can time out once the SCADA server is polling forty devices at once — the register map was never the bottleneck, the poll schedule was.

The mistakes that recur

• Importing the vendor list without proving the address offset.
• Treating every 4xxxx as a holding register without checking the function code.
• Flipping word order until the number looks plausible, then not documenting what you settled on.
• Mixing raw and scaled tags on the same faceplate.
• Alarms that fire on comms loss.
• Ignoring gateway unit IDs "because it's Modbus TCP."
• One poll rate for everything.
• No screenshots, no captured test values.

Before you hand it over

• Critical registers have dated test evidence.
• Addressing convention is documented in words, not implied.
• Word and byte order are recorded per data type.
• Status bits are tested, or clearly flagged as untested.
• Comms health is visible to operators and maintenance.
• Alarm logic separates bad quality from real process conditions.
• Historian tags carry correct units, scaling, and deadband.
• The final map lives with the project files, not in one engineer's laptop spreadsheet.

A well-commissioned Modbus interface is dull to run — values update, diagnostics explain the failures, and no one is decoding a register map by hand during a production outage. Dull is the whole goal.