Based on your Modbus Poll screenshot, I’m pretty sure you should have one-based addressing checked, but Modbus is always fiddly.
Groov will put a 40 in front of your address when you save it - that is just a dumb way to let you know it is a holding register.
Yeah. I don’t disagree, but I was overruled way back when.
First off - I’m not sure the groov can write to the individual bits in an address or you need to figure out what the complete 16 bit string is. So perhaps ‘stop’ is a ‘1’ at bit 0 in the 16 bit string (0000000000000001), ‘Menu+’ is a ‘1’ at bit 7 in the 16 bit string (0000000010000000).
If you want to do bit addressing, configure your tag as a Boolean, not an Integer, and point it at a Holding Register, like this:
Try checking the one based setting, restarting groov and trying again as Jonathan has mentioned. Other than that, I’m out of ideas - do you have the ability to grab the packet and response with wireshark?
MODBUS implementations are like the wild west - but hey, the spec is only 50 pages, so at least it has that going for it! I’ll forgive that some of it is written in Comic Sans.
Must of been a PLC guy that couldn’t be bothered to read the protocol spec:
It would be nice if groov (and every other MODBUS implementation) showed “Start Element” when dealing with one-based entries, and “Start PDU Address” for zero-based as this is what the specification calls them.
Also when changing the one-based* setting, I found that groov needs to be restarted for it to take effect. Is this how it is supposed to be? Could there be a note on the Access Config about that?
*base-one only has a single digit/mark and is used for tallying, but this is MODBUS where there are few rules that are followed…
MODBUS implementations are like the wild west - but hey, the spec is only 50 pages, so at least it has that going for it! I’ll forgive that some of it is written in Comic Sans.
Yeah, kind of regretting even using the library we used instead of just writing the implementation ourselves. I think it cost us more time than it saved us.
It would be nice if groov (and every other MODBUS implementation) showed “Start Element” when dealing with one-based entries, and “Start PDU Address” for zero-based as this is what the specification calls them.
That’s a good idea: it’d be nice to disambiguate things.
Also when changing the one-based* setting, I found that groov needs to be restarted for it to take effect. Is this how it is supposed to be? Could there be a note on the Access Config about that?
That’s not intended, and I’m in the midst of doing a bunch of scanner changes anyway, so I’ll make sure it doesn’t happen in the next feature release.
Yeah, that is nice - how are the writes handled for something like this when code 22 is not available? xor with the value read?
Yup. We make sure to do the read and write back as atomically as possible: groov itself won’t issue any writes between those two operations, but we obviously can’t control anything else.
Yeah, that is wrong. There are slaves out there that may only support 9999 or less, but that shouldn’t drive the design of a modern master or TCP implementation. It’s laughable that the site with a copyright date of 2017 calls it “Standard Modbus” and then ignores the current specification.
If the docs for a slave device are adding 40000 to the PDU address of a holding register, then that is bad documentation that leads to more confusion. So we have little idea what 40001 means until we test it because docs that do this usually don’t tell you how to convert their fairy tale number to a PDU address. So we guess, is it 0, 1 , 40000 or 40001? Complete madness.
For ntsib’s generator, is the PDU address 8193 or 8192? (I suspect it is 8193) For the client, do you use 8192, 8193, 8194, 48192, 48193, 48194? Simply Modbus.
Okay, done ranting. Should we talk about endianess now?
If the docs for a slave device are adding 40000 to the PDU address of a holding register, then that is bad documentation that leads to more confusion. So we have little idea what 40001 means until we test it because docs that do this usually don’t tell you how to convert their fairy tale number to a PDU address. So we guess, is it 0, 1 , 40000 or 40001? Complete madness.
For ntsib’s generator, is the PDU address 8193 or 8192? (I suspect it is 8193) For the client, do you use 8192, 8193, 8194, 48192, 48193, 48194? Simply Modbus.
And the protocol doesn’t care. You give it a table and a 16-bit index and you’re done. ¯_(ツ)_/¯
Endianness is fixed at big, right? It’s register order for larger-than-16-bit values that test on my nerves.
Spec is big for 16-bit registers. Ideally 32 bit values would also be big endian like every other network protocol, but this is not always the case. As you know it’s common to have 16 bits in big endian and the two 16 bits swapped little endian - which is useful to no one - big endian and little endian systems both have to do byte swaps. I would prefer if it were all big endian, but they don’t call me for advice.
that couldn’t be bothered to read the protocol spec: