Hi, Understood. Keep the offset it is. But why does the ModbusTagExtendedRegister not have this shift? Is that a bug?
Also there are a few other problems I found in this area, one is that the getAddressString will yield a different address (which is also unparsable). I'll see if I can fix those. Niels On Sat, Jan 7, 2023 at 8:35 PM Christofer Dutz <christofer.d...@c-ware.de> wrote: > Hi all, > > yeah … just wanted to say … this stupid offset is by spec that way. > I would say, that in this case we have two different specs with a common > base. > Perhaps if we had “variants” of drivers, we could make different > assumptions. > > If you get a Modbus TCP connection things are the way, they currently are. > If you get a Modbus TCP connection with “SunSpec” variant, then you don’t > have the offsets. > > Cause … if we undid the “+1” shift, then other would start complaining > because their specked registers are in different locations. > > I have also heard that for EIP for full support of the PLC features, we’ll > have to have Allen Bradley, Schneider Electric variants next to the default > ones. > I was told most of the major vendors do all the complex types and browsing > differently :-( > > Chris > > From: Niels Basjes <ni...@basjes.nl> > Date: Saturday, 7. January 2023 at 18:31 > To: dev@plc4x.apache.org <dev@plc4x.apache.org> > Subject: Re: Modbus addresses offset by 1? > 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 > -- Best regards / Met vriendelijke groeten, Niels Basjes
