What Niagara does with the Modbus address you type

The address on a Modbus proxy extension is a small component of its own. It carries two properties: an address format — one of hex, decimal or modbus — and the address itself, stored as a string. Nothing is decided until the driver reads both together.

The format a fresh address starts on is hex. So typing 40001 into a point whose format has not been changed asks for data address 0x40001, which is 262145. Validation does not stop it either: in hex mode the only check is that the parsed value is not negative. The point is accepted, the device answers with an exception or with something else entirely, and the argument on site is about the device.

Only the third one does the subtraction that vendor documentation assumes. In modbus format the driver strips the prefix in a fixed order: above 40000 it subtracts 40001, above 30000 it subtracts 30001, above 20000 it subtracts 20001, above 10000 it subtracts 10001, and otherwise it subtracts 1. That is the off-by-one, done for you — but only in that one format.

Hex and decimal both hand the number to the wire as it stands. They are the right choice when a vendor publishes true zero-based data addresses, which some do, and the wrong choice for any document written in the five-digit convention.

Each of those tests is a strict greater-than. So 40000 is not above 40000, drops to the next test, is above 30000, and comes out as data address 9999 — an input-register offset, from an address that reads like a holding register. The separate check that decides which register group an address belongs to wants above 40000 for holding and above 30000 but below 40000 for input, so 40000 belongs to neither group.

The same gap exists at 30000, 20000, 10000 and 0. In the five-digit convention none of those is a legal address — every group starts at x0001 — so this is only reachable from a typo or from a generated point list that is one out. It is worth knowing because nothing reports it. There is no fault and no warning; the point simply reads a different register.

The data type is a separate decision from the address, and it settles two things at once: how many consecutive registers the point reads, and how the bits are interpreted.

A point left on the default reads one register, unsigned. A flow or outside-air temperature published as tenths of a degree then reads 65506 at −3.0 °C rather than −30, and the trend looks like a sensor that fails in cold weather. Anything that can go negative needs the signed type chosen explicitly.

The register count also matters for how the point is grouped. A four-register double starting one register before the end of a contiguous block quietly reaches into whatever follows it.

For two-register values the driver offers exactly three arrangements — 1032, which is the default, 3210 and 0123. The fourth possible arrangement, 2301, is not on the list. A device that publishes its 32-bit values that way cannot be read correctly by setting a property: the practical answer is to read the two registers as separate 16-bit points and combine them in logic, or to have the device's own word order changed where its configuration allows it.

Values of four registers get eight arrangements rather than three, defaulting to 76543210. Meters that publish 64-bit energy totals are the common case, and the default is the one most of them use.

When a value is wrong, these are three independent choices and changing them at random turns a five-minute fix into an afternoon. Work through them in order:

• Address format first. It decides what the string you typed even means, and it is a property of each address rather than of the device.
• Then the data type. A value that is plausible but negative-looking, or that is roughly right but jumps to 65535, is a sign or width problem.
• Then the byte order. A value that is nonsense by orders of magnitude, on a point that reads two or four registers, is word order.

The companion note on Modbus register addressing covers the conventions themselves and why a vendor document and a register map disagree, and poll scheduling and busy time covers what happens once the points are right and there are a lot of them. Where a map has to be read properly before any of this, protocol integration is that work, and station engineering is the station around it.