Register scan returns inconsistent results about modbusmechanic HOT 9 CLOSED

This is a new and experimental feature so your testing and feedback are helpful. That said, is this a RTU device attached to a TCP bridge? I noticed when scanning RTU devices that the scan can get "ahead" of the device's responses. What I see in the scan results when this happens is the register values are shifted anywhere from 20 to 30 lower from what the scan reads. For instance register 1020 is actually 1000. I haven't been able to replicate this (yet) on TCP though. Do you know if the register order might still be correct?

from modbusmechanic.

from modbusmechanic.

from modbusmechanic.

I think I see what is happening. The TCP scanner is also getting ahead of the device's ability to respond. Transaction numbers are not tagged, which is confusing the scanner. This should be fixed in bfcf0c0 which tags transaction IDs on TCP frames.

The screenshots did not come through, but if you start the scan at register 840 instead of 0 do you get consistent results for that first register or first few registers?

from modbusmechanic.

from modbusmechanic.

I realized the other thing that might be going on is a buffer issue. Since this library blocks on a read, if the device doesn't respond fast enough there could be a FIFO situation happening on the buffer where the previous responses are accumulating but never read out. In 73416f1 I have added a user configurable timeout and set the default to 100ms, up from the current hard coded value of 50ms. The timeout should be higher than the devices ping. These changes will be available in the next release and between the two should resolve the issue.

from modbusmechanic.

from modbusmechanic.

Binaries for version 2.8 have just been posted. If the registers are still out of order after playing around with the timeout let me know.

from modbusmechanic.

This will be closed in the next day or so unless the problem still can be recreated in tests.

from modbusmechanic.