modbus register address vs. register number; absolute address vs. offset
About a decade ago, I've written a simple Modbus library for Linux. Apologies for the self-promotion. @Ron Beyer: at the time, I never heard of extended addressing - at the level od Modbus requests, the base and count are always unsigned 16bit types, and : the low-level addresses riding inside the Modbus request frames are always zero-based, starting literally from zero. At the framing level of Modbus addressing, the &quot;object type&quot; is encoded in the Modbus function: discrete inputs, coils, input registers, holding registers. And, the address space in that low-level frame always starts at 0. Thus, theoretically, if you only ever speak the low-level addresses, you can have 64k discrete inputs, and 64k coils, and 64k input registers, and 64k holding registers - at the low level, they are parallel address spaces. You can have a coil #2 and an input register #2 and they are two different objects, no ambiguity in their addressing/access.
Then there's the &quot;upper layer of addressing&quot; (anyone know the official name?), where you have e.g. 10001 to be the first discrete input, and 40001 the first holding register. I.e. this &quot;uniform upper layer address space&quot; has the Modbus object types identified by base offsets - and, the counting system is one-based.
If you need to convert between the upper-layer and lower-layer addresses, you need to subtract that nominal type-specific base offset and handle &quot;off by one&quot; (like Pascal to C array element counting/indexing).
As Ron Beyer has said, reality can be a mess.
Some vendors speak the raw framing-level zero-based register addresses, other vendors speak the upper-layer &quot;uniform&quot; addresses. Typically, I would expect vendors of &quot;distributed I/O endpoint gadgets with Modbus support&quot; to speak the raw register addresses. Versus: documentation to PLC programming, OPC servers or SCADA might speak the upper, more abstract &quot;uniform address space&quot;. But especially with cheap SE Asian Modbus-capable slave gadgets, the documentation is often unclear about what layer it speaks (still chances are that anything above 10000 means the &quot;upper&quot; layer) and I've even seen broken implementations that had the &quot;off by one&quot; wrong for the layer they were speaking. And, you often do not know whether to ask for input vs. holding registers, or discrete inputs vs. coils, when reading = sometimes either works and the address spaces in fact overlap... If unsure, proceed by cautious trial and error.
Actually... the vendor's documentation on any sensors, actuators, drives etc. with Modbus capability tends to focus on its &quot;business domain&quot; = mechanical dimensions, power supply range, physical performance properties, ramps/curves, physical unit scales and encoding, environmental conditions, handling safety precautions, a vocabulary index, a legal disclaimer, a list of ordering codes, a global list of local service contacts... and the darn map of Modbus regiters, which is the first thing you need as an integrator (even at a pre-sales stage), being the only thing you cannot possibly figure out based on common sense, that tends to be buried somewhere real deep :-) and poorly annotated/explained. The best guarded secret.
Just kidding. It's actually getting better through the years.
EDIT: I've just noticed your notes about 1-based addresses above 64k, and a gateway device that converts between two fieldbusses.
I have met gateways by the HMS Corp of Sweden that can speak several protocols, including Modbus. These boxes tend to have their internal proprietary memory space and organization, and the native fieldbus-specific objects or address spaces get mapped into the internal uniform memory space. Understandably, that mapping is more or less freely configurable, and the resulting internal datapoint map is definitely custom or proprietary - there's not much point in asking for a standard in such hybrid devices.