Closed dnshshkr closed 2 weeks ago
Pull requests are welcome.
please remember to add tests that proves the functionality.
A simpler solution could be to change the unpack instruction for float64.
A quick test indicates that your solution might be wrong for int32, and possibly also for strings.
Yes you are correct. I tested with strings and the result is reversed. I might need to add some special instruction for float32.
struct.unpack should do this correctly (if using the correct unpack instruction).
We test float32, but I am not sure if we test float64...I will look later.
please have a look at test_client.py, line 557++.
We do test all datatypes, so please start to see if that test is wrong (which I do not believe).
According to this https://docs.python.org/3/library/struct.html we do convert correctly ("d" for float64 and "f" for float32)
I have just added a test, that shows that the conversion is correct.
Please do not forget that on the wire the modbus protocol uses "big endian", so if you are testing with a "little endian" CPU you see different hex sequence.
If you still have a problem, then please use our debug log call, and show the log, that will show exactly what we receive.
Versions
Pymodbus Specific
Description
This is my code with the library
In
/pymodbus/client/mixin.py
underconvert_from_registers()
Code
PLC floating point numbers use either double words (DWORD) or quad words (QWORD) and they are interpreted in reversed manner eg a case for DWORD:
DM0 = 0x5678
,DM1 = 0x1234
. If we interpret these 2 DMs as a HEX 32 bit number, then it should be0x12345678
and the same goes for a floating number be it 32bit or 64bit. So, it is necessary to rearrange the registers in the code above in a reversed manner. I did some change to your code and it seemed to return the correct floating number that I put in my PLC. Below is the corrected code: