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 nice - how are the writes handled for something like this when code 22 is not available? xor with the value read? 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. Is this how it is supposed to be? Could there be a note on the Access Config about that? I think the numbering system we use for those addresses came from here: Īlso when changing the one-based* setting, I found that groov needs to be restarted for it to take effect. That’s a good idea: it’d be nice to disambiguate things. 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. Actually, with fast polling I’m even able to get the failed to read errors with one slave plus clicking on the switch item in the UI. I think it cost us more time than it saved us. Adding synchronized (transaction) here and there seems to fix this but the original failed to read problem persists. Yeah, kind of regretting even using the library we used instead of just writing the implementation ourselves. 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.
0 kommentar(er)
