Ok, the "off by one" problem is ancient. Looking around the internet I read that in the past when register 123 was needed you would have to request for 122 over modbus.
I find the transition from the logical number to the technical number a responsibility of the application, not of this library. Take for example the SunSpec (modbus standard for solar systems) specification it states: *6.1.1 **Modbus Address Location* *All Modbus device maps MUST be in the holding register address space.* *The beginning of the device Modbus map MUST be located at one of three Modbus addresses* *in the Modbus holding register address space: 0, 40000 (0x9C40) or 50000 (0xC350). These* *Modbus addresses are the full 16-bit, 0-based addresses in the Modbus protocol messages.* *The first two Modbus registers at the start address MUST have the following well-known* *constant values as a marker: 0x5375, 0x6E53 (hexadecimal values of the ASCII string SunS).* On my solar inverter if I request 2 registers at 40000 I get the mentioned 0x5375, 0x6E53. Yet with plc4j/modbus I must specify address 40001 because the library shifts it by one. It took me the better part of today to figure that one out. Niels On Sat, Jan 7, 2023 at 6:13 PM Niclas Hedhman <nic...@hedhman.org> wrote: > > I am not sure what you are asking; But Modbus documentation addresses > are (in my experience) always offset by 1, which I think goes back to > the 1970s when we weren't yet sure whether numbers started at 0 or at 1, > and number ranges were a scarce resource so we wouldn't sacrifice one > for consistency... Those were the days. > > Niclas > > On 2023-01-07 17:27, Niels Basjes wrote: > > Hi, > > > > I ran into the effect that all modbus addresses I specify are shifted > > down > > by 1. > > This turns out to be code in most of the ModbusTag implementations (not > > all) which have a PROTOCOL_ADDRESS_OFFSET to shift it by. > > > > Why was this done? > > If I'm writing software to read modbus addresses and I follow the > > manufacturer specified information it will run into unexpected effects > > (like I have today). > > > > Also: Now getAddressString() yields something different then what I > > used > > to build the tag with. > -- Best regards / Met vriendelijke groeten, Niels Basjes
