Deprecate BinaryPayloadDecoder / BinaryPayloadBuilder.

[janiversen]

No description provided.

[andreapignotti]

The new functions proposed as alternative do not include the ByteOrder and WordOrder! How can I translate the old BinaryPayloadDecoder/BinaryPayloadBuilder login with the new functions?

[janiversen]

Byte order and word order are handled internally.

[andreapignotti]

Can I ask you how the library handle this?
I have to read/write from/to different devices that can use Litte or Big Endian for byteorder and wordorder (this is device specific)

[janiversen]

Of course you can, take a look at the source code.

You read/write to/from the modbus standard NOT how each device CPU is configured, that is the beauty of the modbus (and most other) protocols.

[matteo-zanoni]

@janiversen you are actually not correct... As stated here the Modbus Protocol does not set any explicit roules in regards to endiannes:

This lack of standardization for values larger than 16 bits has resulted in a situation where Modbus implementers have to make an arbitrary choice as to which address of the register pair contains the most significant word of 32-bit values such as IEEE-754 single-precision floats and signed or unsigned 32-bit integers. Most programs for communicating with Modbus slaves can be configured for either register word order.

Losing the ability to choose it dynamically would be quite bad.

Looking at the source code the registers unpacking using the newly suggested convert_from_registers function does struct.unpack hardcoding a fixed ">" at the beginning of the string. This means forcing the registers to be big endian:

https://github.com/pymodbus-dev/pymodbus/blob/f5ede3eb08dab4e2079e19bf96e4778d4dfa91dd/pymodbus/client/mixin.py#L724C1-L724C69

Also when creating the byte list from the registers the endiannes is fixed to "big":

https://github.com/pymodbus-dev/pymodbus/blob/f5ede3eb08dab4e2079e19bf96e4778d4dfa91dd/pymodbus/client/mixin.py#L709C1-L709C56

[janiversen]

It does, it defines big endian for address, count and registers, the modbus protocol do not (sadly) know about 32 bit integers etc.

The new functions are made to support the "de facto" standard used in many but not all modbus devices.

But no need to discuss, nobody are forced to use the convert functions supplied, it's an option.

And remark there are no loss of functionality since python offers these conversions (which are actually used in the implementation as you nicely point out), struct.pack/unpack is part of the standard library.

[farzadpanahi]

@janiversen I think I understand your point basically saying pymodbus does not need to be in the business of converting bytes and such which totally makes sense.

but if that is the intention why even have this half-baked method convert_from_registers, that makes assumptions about endians?

If the idea is to keep pymodbus clean and out of this, isn't it better to remove those methods all together and do not provide the half-baked utility/helper functionality which I think can cause more problems in future for novice users?

unix people had it this way -> Write programs that do one thing and do it well.

[janiversen]

it's because I and a large number of users need exactly that.

If you do no not want to use it, fine by me, it's an option not a demand. with my life long experience this is a proper solution for most professional devices.

Please remember byte order is actually defined by the standard as big endian (otherwise there would have been a lot of problems with fields like address/count and all bit requests). Word order is a de facto standard defined by the largest manufacturers like siemens and schneider (which uses big endian), so yes there are companies not following the de facto standard....but these companies also often deviate from the standard in other ways.