How to use convert_from_registers instead with different data types?

[d-el]

How to use convert_from_registers instead of BinaryPayloadDecoder with multiple different data types?
Old code:

result = self.client.read_holding_registers(0x0200, count=21,  slave=1)
decoder = payload.BinaryPayloadDecoder.fromRegisters(result.registers, byteorder=constants.Endian.BIG, wordorder=constants.Endian.LITTLE)
voltage = decoder.decode_32bit_int()
current = decoder.decode_32bit_int()
temperature = decoder.decode_16bit_int()
...

[janiversen]

Please see the examples.

[d-el]

In example used deprecated BinaryPayloadDecoder.

[janiversen]

That is only one example (which is still there because the payload is still there), there are others.

[patfrench]

Hi

I have a device that has a large amount of registers, I can't read and decode each register one by one.
I'm reading 15 registers but inside there are float32, uint32 and uint64 and I'm wondering how to decode?
My intuition tells me:

u16 = client.convert_from_registers(rr.registers[offset:offset+1] ...
offset += 1
# un uint32
u32 = client.convert_from_registers(rr.registers[offset:offset+2] ....
offset += 2
# un float32
f32 = client.convert_from_registers(rr.registers[offset:offset+2] ....

Thank you

[bambosd]

Hello, i have also some code using the old style with endian big / little etc...
what would be the method to update the code with the new client.convert_from_registers ?
specifically, i had all the 4 different possible types of float , byte endian big and little, word endian big and little.
How to do that with the new function ?

[janiversen]

4 types is impossible with standard modbus ! because the frames being sent/received are pr definition big endian, your cpu is either big or little, leaving only 2 types.

If you look at the signatures of convert to/from it tells you what to do.

[bambosd]

4 types is impossible with standard modbus ! because the frames being sent/received are pr definition big endian, your cpu is either big or little, leaving only 2 types.

If you look at the signatures of convert to/from it tells you what to do.

ok, yes, you have a point. but specifically for float32 , some modbus devices are reversing bytes because of their primary protocol. for example 104 Protocol Gateways. (IEC 60870-5-104). so from the old library we had endianess of bytes and endianess of words, by setting BIG and LITTLE. all cases was 4. I'm not saying that all the types are used, i'm just saying that strange devices can do this unusual encoding. to read this device i used byte swap and word swap at the same time, (DCBA).

also swapped words is used on many devices. maybe is better to keep the functionality somehow.

[janiversen]

Pymodbus support the modbus standard and that is big endian for bytes, and not defined for words....which is why pymodbus offers big/little for words but not for bytes.

Swapping bytes is actually a functionality built into python so no need for Pymodbus to include it.

[jacobq]

@bambosd Like @janiversen was saying, there is no ambiguity about how Modbus encodes 16-bit registers (the bits/bytes within a word). However, I have certainly encountered devices where the Modbus interface directly mapped over some other memory such that high/low bytes within a register needed to be swapped to correctly interpret. In that case, I think the solution is to provide your own decoding function (taking advantage of existing functionality, such as array.byteswap)

The table generated by Google's "AI Overview" for this topic appears to be actually fairly helpful:

Format Name	Register 1 (Lower Address)	Register 2 (Higher Address)	Byte Order on Wire	Common Hardware Examples
Big-Endian / Motorola	High Word (A B)	Low Word (C D)	A -> B -> C -> D	Schneider Modicon PLCs
Little-Endian Word Swap / Intel	Low Word (C D)	High Word (A B)	C -> D -> A -> B	Most SCADA systems, Opto 22, Horner APG
Mid-Big-Endian / Byte Swap	High Word Swapped (B A)	Low Word Swapped (D C)	B -> A -> D -> C	Rare instrumentation devices
True Little-Endian	Full Byte Reversal	Full Byte Reversal	D -> C -> B -> A	Custom or non-standard serial engines

[Sarishc]

Yes—decode the block once, then slice it according to each field's register width. convert_from_registers accepts one datatype per call, so mixed layouts need separate slices.

Your old byteorder=BIG, wordorder=LITTLE maps to word_order="little" in the current converter (bytes within each 16-bit register are handled big-endian).

rr = client.read_holding_registers(
    address=0x0200,
    count=15,
    device_id=1,  # use slave=1 on older PyModbus versions
)
if rr.isError():
    raise RuntimeError(f"Modbus read failed: {rr}")

regs = rr.registers
offset = 0

def take(data_type):
    global offset
    width = data_type.value[1]  # registers: 1 for 16-bit, 2 for 32-bit, 4 for 64-bit
    value = client.convert_from_registers(
        regs[offset : offset + width],
        data_type=data_type,
        word_order="little",
    )
    offset += width
    return value

voltage = take(client.DATATYPE.INT32)
current = take(client.DATATYPE.INT32)
temperature = take(client.DATATYPE.INT16)

# Example of the mixed layout from the follow-up:
u16 = take(client.DATATYPE.UINT16)
u32 = take(client.DATATYPE.UINT32)
f32 = take(client.DATATYPE.FLOAT32)
u64 = take(client.DATATYPE.UINT64)

So the intuition in the follow-up is correct. The important details are:

• advance by the number of 16-bit registers, not bytes;
• a 32-bit value consumes 2 registers and a 64-bit value consumes 4;
• keep the offsets from the device's register map—insert/skips for reserved registers if the map has gaps;
• if several adjacent values have the same datatype, you may pass the whole corresponding slice once; the converter returns a list when it decodes more than one value.

I checked this against the current implementation and examples: DATATYPE.value[1] is the register width used by convert_from_registers.

[janiversen]

If the purpose is to make clear and understandable code, it can be done a lot easier:

´´´
voltage = [client.from_registers(rr.registers[x, x+2], data_type=client.DATATYPE.INT32,word_order="little") for x in (1,3,5)]
´´´

where 1,3,5 are the relevant register offsets.

Calling client.from_registers one time with all registers or multiple times each with one register set actually use the same amount of CPU.