Bit ordering API Change from 3.9.2 vs 3.11 #2713
-
|
Hey everyone, was looking to see if anyone else had some ideas about what I might be missing in terms of the API change going from 3.9.2 to 3.11.0. Had a discussion with the developer, and was confirmed that 3.11.0 did fix something in the bit ordering that was wrong compared to 3.10.0. However, it was also confirmed that there was still an API change going from 3.9.2 to 3.11.0. In my testing I was unable to verify this change and was looking to see anyone can confirm what this change is. The docs suggest its related to bit ordering but I can not reproduce any bit ordering change going from 3.9.2 to 3.11.0. However, it's reasonable that I'm missing something, I just don't know what it is. This was my best attempt at highlighting any differences: from pymodbus import __version__ as pymodbus_version
from pymodbus.client import ModbusTcpClient
from pymodbus import pymodbus_apply_logging_config
pymodbus_apply_logging_config("DEBUG")
def test_discrete_inputs():
print(f"PyModbus version: {pymodbus_version}")
print('-'*100)
client = ModbusTcpClient(host="127.0.0.1", port=509)
client.connect()
if tuple(map(int, pymodbus_version.split('.'))) <= (3, 9, 2):
result = client.read_discrete_inputs(address=0, count=32, slave=1)
else:
result = client.read_discrete_inputs(address=0, count=32, device_id=1)
print('-'*100)
print(f"Discrete inputs: {result.bits}")
print(f"Set bits: {[i for i, b in enumerate(result.bits) if b]}")
print('-'*100)
big_endian_bits = client.convert_from_registers(result.bits, word_order='big', data_type=client.DATATYPE.BITS)
print(f"Big endian: {big_endian_bits}")
print(f"Set bits: {[i for i, b in enumerate(big_endian_bits) if b]}")
print('-'*100)
little_endian_bits = client.convert_from_registers(result.bits, word_order='little', data_type=client.DATATYPE.BITS)
print(f"Little endian: {little_endian_bits}")
print(f"Set bits: {[i for i, b in enumerate(little_endian_bits) if b]}")
client.close()
if __name__ == "__main__":
test_discrete_inputs()Note: this is all tested on a little endian cpu, which the developer also highlighted as a possible point of difference in the API change. I'm sure many of you also use discrete inputs in production and understanding any API changes especially when related to ordering as this can cause a silent failure. In the sense that you may be just misinterpreting the results for quite some time without ever knowing it. Anyone have some more ideas to test to root out what the exact difference is? |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 6 replies
-
|
This is extensively explained in #2706. you write: "was looking to see if anyone else had some ideas about what I might be missing in terms of the API change going from 3.9.2 to 3.11.0" The suggestion stands, if you want more details than the documentation offers, then you need to compare the source code...From what I understand your code works, which is the important thing (in my mind). But looking forward to see if anyone can define the differences more precisely. |
Beta Was this translation helpful? Give feedback.
-
|
I agree this has been extensively discussed in #2706. The code happening to work in my mind is the reason I'm just looking to learn more from the community. Since if there are bit ordering changes in the API, this suggests my code should not work. If it does I don't want this to be mistaken and discover my error in the future in production. However, the only reason for opening this discussion was to see if others could assist in identifying the API change, specifically related to bit ordering changes that are noted in "API changes 3.11.0". Since that goal hasn't been met yet, if it's okay with you I will unmark your response as the answer so that others don't mistakenly think there is nothing more to discuss here. |
Beta Was this translation helpful? Give feedback.
-
|
It appears to me that you are each talking past each other. (1) The (2) All the other API changes from 3.9 -> 3.10 were not reverted in 3.11. Thus there remain changes 3.9 -> 3.11. For instance |
Beta Was this translation helpful? Give feedback.
-
|
Ah I see, if bit ordering was reverted entirely then that completely answers my question. Was very uncertain about that before based on some of the feedback. But the results do seem to agree with what you are saying. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
"bit ordering" was NOT reverted...."byte ordering" was reverted. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry I chose the wrong words, that is not what I meant. I used "bit order" just as a reference to the entire order as @alexrudd2 commented. I meant that ordering as a whole in 3.11 is the same as 3.9.2. If it is entirely the same as 3.9.2 then this would be good. Your followup that the exact same order as 3.9.2 is not guaranteed is somewhat concerning only because that still leaves the same question open. What is the difference, only strictly in terms of all possible ordering from 3.9.2 to 3.11.0. Maybe someone else will have some guidance. Or maybe if it is not guaranteed but likely to be the same this will be good enough I suppose. |
Beta Was this translation helpful? Give feedback.
-
|
as I wrote it is new code, so there might be differences in corner cases, I simply have not tested that....I am aware that there was different register conversions errors, which are all handled by the new implementation. I am sure you can understand, that with a new implementation it is hard to guarantee that there are no differences in the part you are interested in. Instead of focusing on differences, it would make a lot more sense in my mind, to make sure your code words...and if you want more guarantees look at the test harness to see the extensive testing done. |
Beta Was this translation helpful? Give feedback.
-
|
Is it fair to say that "The intention was for no change to byte ordering 3.9 -> 3.11.0, and if there is a change file a new bug."? |
Beta Was this translation helpful? Give feedback.
-
|
Correct, apart from a small nod....v3.10 introduced new pack/unpack methods which handles all conversions to/from registers. The new pack/unpack methods was NOT reverted in 3.11.0, the only reversal was the byte ordering...which is the reason I will not guarantee that v3.9.2 and v3.11.0 always delivers the same bit strings. It looks as if they do, but we all know that corner cases can be tricky. |
Beta Was this translation helpful? Give feedback.
-
|
As an aside, I have been wanting an excuse to use Hypothesis property-based testing. I learned about it at a local Python user's group but have not had time to play with it. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds interesting, and I am sure our test harness could benefit from it. |
Beta Was this translation helpful? Give feedback.
Correct, apart from a small nod....v3.10 introduced new pack/unpack methods which handles all conversions to/from registers.
The new pack/unpack methods was NOT reverted in 3.11.0, the only reversal was the byte ordering...which is the reason I will not guarantee that v3.9.2 and v3.11.0 always delivers the same bit strings. It looks as if they do, but we all know that corner cases can be tricky.