address offset
Closed this issue · 8 comments
There seems to be an offset of 2 in the address, at least with the 32bit data with Modbus TCP (I can only test the Modbus on a machine that only uses 32bit data: long int, or float32).
The get the correct data I must increase the address by 2, as it can be seen on screenshot:
Tested on version 1.7.0 for windows.
Because I know the values to expect at each address, as we design the machine: values of ~411 are expected on addresses 16078, 16080, 16082, not the ones before or after.
Besides, with other programs (QModMaster and Radzio! Modbus Master Simulator ) this coincides.
Sorry for delay @sanny32,
It is a bit difficult, and possibly senseless, to show you my hex values from server address (microcontroller): that's because we are using a Raspberry Pi as a gateway, and the software on the Raspberry is not easily available to me:
Windows-PC ---(ModBus TCP)---> Raspberry-Pi ---(ModBus RTU)---> Microcontroller
I can't assure that the gateway is not adding any address offset, but again, this do not happen with other programs.
Reading on the internet I have seen that address offset is not such a uncommon problem, and many programs offer a way the configure this offset (at least for configuring the 0 or 1 based addressing). Maybe it would be possible to implement this, to allow greater compatibility.
Yes, the base address in Open Modscan is 1, not 0. If your device has base address 0 you can think, that the program has address offset.
Yes, the base address in Open Modscan is 1, not 0. If your device has base address 0 you can think, that the program has address offset.
Can you add an option for the Modbus start address (1 or 0)?
Some Modbus device datasheets use 0, while others use 1. For example, Modbus address 1 corresponds to 40001 (option 1), and Modbus address 0 corresponds to 40001 (option 0, automatically adds 1 to this address).
Hello @dangkhoa1612. This may be possible to do in one of the future releases.
Implemented at version 1.8.0