Changing RegisterOrder doesn't affect the value

[Jordise2002]

In the edit item(s) panel in the advanced section changing the register order doesn't affect the value. I am testing using a UDec64 item on the HoldingRegisters of a Modbus TCP connection. Changing those parameters on the device didn't change anything either.

The .pjc file is appended bellow:

<?xml version="1.0" encoding="UTF-8"?>
<project version="0.4.6" editnum="4">
    <name>ModbusSlave</name>
    <author>ralcaraz</author>
    <comment>ModbusSlave - /home/ralcaraz/Project - 2026-01-14_10-58-38</comment>
    <ports>
        <port>
            <stopBits>1</stopBits>
            <dataBits>8</dataBits>
            <timeoutFirstByte>1000</timeoutFirstByte>
            <serialPortName></serialPortName>
            <flowControl>No</flowControl>
            <isBroadcastEnabled>true</isBroadcastEnabled>
            <baudRate>9600</baudRate>
            <name>ModbusSlave</name>
            <timeoutInterByte>50</timeoutInterByte>
            <host>192.168.2.20</host>
            <parity>No</parity>
            <maxconn>10</maxconn>
            <type>TCP</type>
            <port>5002</port>
            <timeout>3000</timeout>
        </port>
    </ports>
    <devices>
        <device>
            <byteArrayFormat>Hex</byteArrayFormat>
            <byteArraySeparator>\[default]</byteArraySeparator>
            <byteOrder>LessSignifiedFirst</byteOrder>
            <maxReadCoils>2040</maxReadCoils>
            <maxReadDiscreteInputs>2040</maxReadDiscreteInputs>
            <maxReadHoldingRegisters>127</maxReadHoldingRegisters>
            <maxReadInputRegisters>127</maxReadInputRegisters>
            <maxWriteMultipleCoils>2040</maxWriteMultipleCoils>
            <maxWriteMultipleRegisters>127</maxWriteMultipleRegisters>
            <name>Escritura Holding Múltiples Completos Contiguos</name>
            <portName>ModbusSlave</portName>
            <registerOrder>R0R1R2R3</registerOrder>
            <stringEncoding>UTF-8</stringEncoding>
            <stringLengthType>ZerroEnded</stringLengthType>
            <unit>1</unit>
        </device>
    </devices>
    <dataviews>
        <dataview name="Dataview" period="500">
            <addressNotation>Default</addressNotation>
            <useDefaultColumns>1</useDefaultColumns>
            <columns>Device;Address;Format;Comment;Value</columns>
            <item>
                <device>Escritura Holding Múltiples Completos Contiguos</device>
                <address>400301</address>
                <byteArrayFormat>Hex</byteArrayFormat>
                <byteArraySeparator>[default]</byteArraySeparator>
                <byteOrder>MostSignifiedFirst</byteOrder>
                <comment>W_A_HOLD_C1</comment>
                <format>UDec64</format>
                <period>500</period>
                <registerOrder>R3R2R1R0</registerOrder>
                <stringEncoding>DefaultStringEncoding</stringEncoding>
                <stringLengthType>ZerroEnded</stringLengthType>
                <value>0</value>
                <variableLength>20</variableLength>
            </item>
            <item>
                <device>Escritura Holding Múltiples Completos Contiguos</device>
                <address>400305</address>
                <byteArrayFormat>Hex</byteArrayFormat>
                <byteArraySeparator>[default]</byteArraySeparator>
                <byteOrder>MostSignifiedFirst</byteOrder>
                <comment>W_A_HOLD_C2</comment>
                <format>Dec32</format>
                <period>500</period>
                <registerOrder>R0R1R2R3</registerOrder>
                <stringEncoding>DefaultStringEncoding</stringEncoding>
                <stringLengthType>ZerroEnded</stringLengthType>
                <value>0</value>
                <variableLength>20</variableLength>
            </item>
            <item>
                <device>Escritura Holding Múltiples Completos Contiguos</device>
                <address>400307</address>
                <byteArrayFormat>Hex</byteArrayFormat>
                <byteArraySeparator>[default]</byteArraySeparator>
                <byteOrder>LessSignifiedFirst</byteOrder>
                <comment>W_A_HOLD_C3</comment>
                <format>Double</format>
                <period>500</period>
                <registerOrder>R3R2R1R0</registerOrder>
                <stringEncoding>DefaultStringEncoding</stringEncoding>
                <stringLengthType>ZerroEnded</stringLengthType>
                <value>0</value>
                <variableLength>20</variableLength>
            </item>
            <item>
                <device>Escritura Holding Múltiples Completos Contiguos</device>
                <address>400311</address>
                <byteArrayFormat>Hex</byteArrayFormat>
                <byteArraySeparator>[default]</byteArraySeparator>
                <byteOrder>LessSignifiedFirst</byteOrder>
                <comment>W_D_HOLD_C4</comment>
                <format>Bool</format>
                <period>500</period>
                <registerOrder>R0R1R2R3</registerOrder>
                <stringEncoding>DefaultStringEncoding</stringEncoding>
                <stringLengthType>ZerroEnded</stringLengthType>
                <value>0</value>
                <variableLength>20</variableLength>
            </item>
            <item>
                <device>Escritura Holding Múltiples Completos Contiguos</device>
                <address>400312</address>
                <byteArrayFormat>Hex</byteArrayFormat>
                <byteArraySeparator>[default]</byteArraySeparator>
                <byteOrder>LessSignifiedFirst</byteOrder>
                <comment>W_D_HOLD_C5</comment>
                <format>Dec16</format>
                <period>500</period>
                <registerOrder>R3R2R1R0</registerOrder>
                <stringEncoding>DefaultStringEncoding</stringEncoding>
                <stringLengthType>ZerroEnded</stringLengthType>
                <value>0</value>
                <variableLength>20</variableLength>
            </item>
        </dataview>
    </dataviews>
    <windows>0c0000006461743a44617461766965770a000000000000000000000075060000de020000</windows>
</project>

Thanks for your work

[serhmarch]

Hello.

I can not identify the same issue, currently all is working fine:

I have 4 sequential registers [400001:400004] with values 0000 1111 2222 3333 (Hex format), then 4 Hex64 values with different registers order, then 4 UDec64 with the same order.

I recommend to use the latest version 0.4.8 (as I see you use 0.4.6)

[Jordise2002]

Doing further testing I found the issue to be non-consistent. Some times I found that with the same project it worked and suddenly it stopped working after doing some modifications I can't exactly pin down.

[chenfd99]

I also ran into some issues. After investigation, I believe the core problem you're facing is endianness. In modbustools (version 0.5), the RegisterOrder parameter seems to only affect the display order of data in the UI, not the actual on‑wire byte order. If your tests don't match, you may try adjusting the endianness settings in your reading tool. All test data below are from modbustools 0.5.

1. Data Storage and Display Order

Add an item in mbserver's dataview with address 400001, format Hex64, storing data 0x1122334455667788. The configuration snippet:

<?xml version="1.0" encoding="UTF-8"?>
<items>
    <item>
        <device>Device1</device>
        <address>400001</address>
        <byteArrayFormat>Hex</byteArrayFormat>
        <byteArraySeparator>[default]</byteArraySeparator>
        <comment></comment>
        <format>Hex64</format>
        <registerOrder>DefaultRegisterOrder</registerOrder>
        <stringEncoding>DefaultStringEncoding</stringEncoding>
        <stringLengthType>ZeroEnded</stringLengthType>
        <swapBytes>DefaultSwapData</swapBytes>
        <variableLength>20</variableLength>
    </item>
</items>

Under the default display order, the dataview tool distributes the 64‑bit data into four 16‑bit registers with high‑order bytes stored at high addresses:

Register Address	+0	+1	+2	+3	...
400001	0x7788	0x5566	0x3344	0x1122	0x0000
Display Order (RegisterOrder)	R3	R2	R1	R0

That is, the most significant byte (0x77) is stored in the high byte of the highest‑addressed register (R3).

2. RegisterOrder Seems to Only Affect Display Order

Changing the RegisterOrder setting changes the displayed 64‑bit hex value in the GUI, but the actual stored byte order in registers does not change. The following table shows the displayed results for different RegisterOrder settings:

RegisterOrder	Displayed HEX64
R0R1R2R3	1122 3344 5566 7788
R3R2R1R0	7788 5566 3344 1122
R1R0R3R2	3344 1122 7788 5566
R2R3R0R1	5566 7788 1122 3344

Thus, RegisterOrder seems to control only the visual presentation of the data and does not affect the on‑wire byte order.

3. Actual Read Test (mbclient)

Send a read‑holding‑registers request with mbclient:

[Tx]: 01 03 00 00 00 04 44 09
[Rx]: 01 03 08 77 88 55 66 33 44 11 22 1C 08

The corresponding server (mbserver) side:

[Rx]: 01 03 00 00 00 04 44 09
[Tx]: 01 03 08 77 88 55 66 33 44 11 22 1C 08

Analysis: lower memory address bytes are sent first, higher memory address bytes last. This order corresponds to Little Endian Byte Swap (CDAB) – i.e., R3 (0x7788) first, then R2 (0x5566), then R1 (0x3344), then R0 (0x1122).

Important finding: No matter how you change the RegisterOrder setting for the Device in dataview, the transmitted byte order remains the same: 77 88 55 66 33 44 11 22. This further confirms that RegisterOrder seems to be only for display.

4. Single‑Register Reads Work Fine

Reading a single register involves no multi‑register ordering, so it always works. Example:

[Rx]: 01 03 00 03 00 01 74 0A 
[Tx]: 01 03 02 11 22 34 0D 

The returned data 0x1122 matches the request without ambiguity.

5. Root Cause

Many Modbus software/tools default to Big Endian (ABCD) when handling multi‑register data – i.e., R0 first, then R1, then R2, then R3. However, modbustools actually uses CDAB order on the wire. This mismatch causes the “sometimes works, sometimes fails” symptom when communicating with devices that expect a different endianness.

6. My Scenario and a Couple of Suggestions

My scenario: the target device uses Big Endian (ABCD). I have its manual, but the device hasn't arrived yet. I planned to use mbserver as a slave simulator and write a program to read data from it for early development. However, I discovered that mbserver actually uses CDAB (Little Endian Byte Swap), so multi‑register reads do not match (single‑register reads are fine).

Note that mbserver and mbclient communicate correctly with each other because they use the same endianness. Problems arise when using mbserver as a slave and another gateway or Modbus device (with a different endianness) tries to read from it.

Based on the above, I would like to offer two suggestions for your consideration:

• If RegisterOrder is only a display setting (unrelated to communication), would it be possible to consider adding a user‑configurable endianness option in the tool, allowing users to set the actual on‑wire byte order (e.g., ABCD, CDAB, etc.) for better compatibility with other devices?
• On the other hand, if RegisterOrder is intended to control the Modbus wire endianness, then the current behavior might be a bug, because changing it does not affect the actual transmitted byte order.

This is my understanding. Please correct me if I'm wrong.

[serhmarch]

Hello.

In modbustools (version 0.5), the RegisterOrder parameter seems to only affect the display order of data in the UI,
not the actual on‑wire byte order.

Yes. DataView tool existing purpose is to display inner memory with different formats: integers, floats, string etc.
And RegisterOrder is one of the parameters you can use to change this representation.

RegisterOrder Seems to Only Affect Display Order

RegisterOrder parameter is related to Modbus packet transfer order and it might be a bit confusing.
R3 - most signified register (MSR) of 64-bit word, R0 - less signified (LSR).
So setting R0R1R2R3 means that less signified register (LSR) was transfered first,
R3R2R1R0 - most signified register (MSR) was transfered first.

Let's take a look on the current packet:

01 03 08 77 88 55 66 33 44 11 22 1C 08

If you select display parameter R3R2R1R0, that means MSR (R3) transfered first (77 88),
than transfered R2 (55 66), LSR R0 (11 22) transfered last.
Thats why R3R2R1R0 = 0x7788556633441122.

If you select display parameter R0R1R2R3, that means LSR (R0) transfered first (77 88),
than transfered R1 (55 66), MSR R3 (11 22) transfered last.
Thats why R0R1R2R3 = 0x1122334455667788.

And one more thing.

Modbus protocol clearly defines byte transfer order within 16-bit register: MSB first, LSB next.
But it tells nothing about data size bigger than 16-bit, thats why RegisterOrder setting exists.
However, the user can still change the byte order in a 16-bit register for display: SwapBytes=Yes

[chenfd99]

@serhmarch Thank you for your detailed explanation. You pointed out: "R3 is the most significant register (MSR) of a 64-bit word, R0 is the least significant register (LSR)". I had mistakenly assumed the opposite (thinking R0 was the high 16 bits and R3 the low 16 bits), because I thought R0R1R2R3 in RegisterOrder followed the same left‑to‑right reading order as we normally read numbers (leftmost digit most significant, rightmost least significant). That led to my confusion about RegisterOrder not working.

Now I fully understand – this RegisterOrder is perfectly fine as is.

On a final note: this tool is the strongest Modbus tool I have ever used, bar none. Thank you for your great work!

[gzmorell]

Hi, I can replicate the original problem, that is, changing the register order does not affect to the value displayed. But it only appears in Linux not in Windows. I have tried it in Archlinux updated, both compiling from source and using the compiled version provided in the repo with the same result. The weird thing is that the problem is not shown compiling in debug mode or if I add a message displaying the value of the register order in the inline function swapRegisters64 in mbcore.h. I am checking this with a double value. I have no idea what is causing the problem. Swapyes/Swapno always change the value in all cases.
The original value is "432.304" with R3R2R1R0 and Swapno. In Archlinux with no changes in the code and release compilation the value is 2.94505e-109 with Swapno, and no matter the register orde I set, which meets the R0R1R2R3 order. If I chose Swapyes the value displayed is 1.33057e+184, no matter the register order, which corresponds again to R0R1R2R3. When in debug mode, everything works as usual. I have checked the incoming message log, and it is always the same in all cases.

[gzmorell]

I think is a compiler optimization with these changes in mbcore.h it seems to work:

#include <cstring>
....
inline void swapRegisters64(void *buff, const RegisterOrder order)
{
    auto *p = reinterpret_cast<std::uint16_t*>(buff);
    auto swap = [&](int i, int j) {
        std::uint16_t tmp;
        std::memcpy(&tmp, &p[i], sizeof tmp);
        std::memcpy(&p[i], &p[j], sizeof p[i]);
        std::memcpy(&p[j], &tmp, sizeof tmp);
    };
    switch (order) {
    case R3R2R1R0: swap(0,3); swap(1,2); break;
    case R2R3R0R1: swap(0,2); swap(1,3); break;
    case R1R0R3R2: swap(0,1); swap(2,3); break;
    default: break;
    }
}

[gzmorell]

The compiler optimization seems to be related to the conversion to a 64 bit variable prior to do the swapping. This change in mbcore.cpp also solves the problem, but it must be done for every case you call swapRegisters64:

case Double:
            {
                void* bf = const_cast<void*>(buff);
                swapRegisters64(bf, registerOrder);
                double v = *reinterpret_cast<const double*>(buff);
                value = QVariant(v);
            }
            break;

[serhmarch]

Hello @gzmorell .

Thank you for the deep diving into the problem. There was a complex issue with compiler optimization and some typos like:

    case UDec64:
        *reinterpret_cast<quint64*>(v) = static_cast<quint64>(value.toULongLong());
        swapRegisters64(&v, registerOrder);
        sz = sizeof(quint64);
        break;

where swapRegisters64(&v, registerOrder); must be replaced with swapRegisters64(v, registerOrder); (&v - address of pointer, not a variable).

You can switch to v0.5dev branch and build from sources to check the issue (+ some new features available, check changelog.md).

And @Jordise2002 , you can do the same if you want to define is it the case or not.

[gzmorell]

Hello @serhmarch .
Thanks a lot for your program.
With the changes in v0.5dev the issue is gone.
I have seen that you have developed the optional use of WriteSingleCoil and WriteSingleRegister, again thanks a lot, that's something I was looking for, it works like a charm. Thanks