Hi Niels, I know there was a reason why the offset didn't get applied to the extended registers, however I can no longer find out why I thought that it shouldn't have applied.
I would be in favor of adding the offset to the extended register to make them the same as the others. Ben On Sun, Jan 8, 2023 at 11:07 PM Łukasz Dywicki <l...@code-house.org> wrote: > Based on my own experience with modbus devices - you might also face > situation where manufacturer starts addressing with own offset by not > following official guidance. A fairly common practice I observed is use > of addresses ie. 0xxxx, 1xxxx, 4xxxx for coil/input/holding which are > being called "entity numbers". [1] > Out of tens of modbus devices I interfaced with I had a matching > combination of manufacturer docs, library approach and actual device > addresses once or twice. Speaking here about heat pumps, inverters, > electric meters and PLCs, all are subject of same trouble. > > Maybe implementing whole driver is not needed as you can try to use > optimizer which lives between your program code and driver and can > re-arrange fields/tags before they reach device? > > Best, > Łukasz > > [1] https://en.wikipedia.org/wiki/Modbus#Entity_numbers_and_addresses > > On 8.01.2023 12:27, Niels Basjes wrote: > > 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 > >> > > > > >
