The byte order setting in an HMI project reorders how the screen combines a register's two bytes: 1234 shows as 53764 after the toggle. The RTU frame on the wire keeps the same high-byte-first payload. Put any swap your custom target needs in its own register decoding, and prove it with two captured values whose bytes differ.
You flip the byte order setting in the panel project, download it, and the number on the screen jumps: 1234 becomes 53764. The custom controller on the other end of the RS-485 pair still receives the same two bytes it always received. That is intended behavior, not a fault. The byte order setting is a display control. It decides which of a register's two bytes the screen treats as the high byte. The frame the panel puts on the wire follows the Modbus specification's order no matter what the setting says. So the fix for a custom target that assembles bytes in the opposite order belongs in the target's register decoding, and one capture test with two known values proves the whole chain. This page covers what the setting moves, what stays fixed on the wire, the arithmetic behind the two numbers, and where the swap belongs.
What the byte order setting changes
Every Modbus register is 16 bits, 2 bytes on the wire. The specification sends the more significant byte first and the less significant byte second. Combining those two bytes into a number can happen two ways:
- high byte first: value = high x 256 + low
- low byte first: value = low x 256 + high
The byte order setting in the panel programming software selects which combination the screen uses to render the value. It travels with the project: once you download, the project's choice governs the panel's display. It touches nothing on the bus. The request and response frames are assembled to the specification's high-byte-first order regardless of the setting, which is why the same screen can flip from 1234 to 53764 while a serial capture of the same transaction reads byte for byte identical both times.
Worked example: 1234 becomes 53764
Write the test value 1234 into holding register 40001, the first holding register in the 4xxxx naming convention; why a 4xxxx register is not Modbus function code 04 separates that name from the function code in the frame.
1234 decimal is 0x04D2 in hexadecimal. The high byte is 0x04 and the low byte is 0xD2.
- With the project set to high byte first, the screen computes 4 x 256 + 210 = 1024 + 210 = 1234. The screen reads 1234.
- Switch the project setting to low byte first and download. The same two bytes now render as 210 x 256 + 4 = 53760 + 4 = 53764.
Capture the transaction both times and the payload bytes for the register stay 04 D2 in each run. Display flips, wire stands still: that is the signature of a display-order control.
Pick test values whose two bytes differ. A value with identical bytes cannot show the difference:
| Value written | Wire bytes | Screen, high byte first | Screen, low byte first |
|---|---|---|---|
| 1234 | 04 D2 | 1234 | 53764 |
| 100 | 00 64 | 100 | 25600 |
| 2570 | 0A 0A | 2570 | 2570, useless as a test |
The 100 row works the same way: 100 is 0x0064, reversed to 0x6400, and 100 x 256 = 25600. Run two such values and you have ruled out a coincidence in the byte pattern.
How to verify with one capture
- Bind a numeric display object on the panel screen to the register, and write a known value into it from the simulator or controller side. Record what the screen shows.
- Toggle the byte order setting in the project, download, and record the screen again. Two different numbers from one written value tell you which rendering the panel uses in each state.
- Capture the actual frame. Tap the RS-485 pair with a serial protocol analyzer, or have your target's receive routine print the raw hex bytes as they arrive.
- Compare the payload bytes between the two runs, with the setting flipped between them. Identical payload bytes close the question: the setting is screen-side and the wire is settled.
- Repeat with the second test value, such as 100 after 1234, so a quirk in one byte pattern cannot pass for a result.
Test the write and read directions separately. A conversion applied to the panel-to-target direction only reappears as a mismatch the first time the target sends a value back. If the payload bytes themselves differ between runs, or the frame looks wrong in any other way, check the slave address, the function code and the CRC before touching byte handling; Modbus RTU master no reply and address errors: fix both covers those frame-level checks. The CRC has its own fixed byte order on the wire, and a guide to reversed CRC bytes in Modbus RTU frames shows how that failure looks different from a payload-order mismatch.
Where the swap belongs
The specification puts the high byte first on the wire, always. If your custom controller combines the pair as low x 256 + high, its integer comes out reversed: it reads 04 D2 as 53764 while the screen correctly shows 1234. Fix the target, at the point where it assembles the two bytes:
- change the assembly to value = high x 256 + low, or
- keep one named swap step at the register boundary and call it for every register the two devices share.
One convention per project, written down, with one device named as the owner of any conversion. Changing the panel setting and the target decoding at the same time hides the original mismatch and can build a double swap into the path, where a written value looks right and the first readback lands wrong. The register boundary is where every custom link settles this: putting an HMI panel on a custom Modbus RTU slave shows the same boundary from the slave side, and connecting an HMI panel to a microcontroller over Modbus RTU sets up the link you are capturing.
Recommendation: Treat the byte order setting as a screen control and treat the wire as fixed to high byte first. When a custom Modbus RTU target disagrees with the screen by exactly one byte swap, capture one request, read the two payload bytes, and place the conversion in the target's register decoding. Verify with two values whose bytes differ, such as 1234 and 100, and test the write and read directions separately. Leave the panel setting wherever it renders your values correctly, and record which device owns the swap.
Questions
Does byte order also matter for 32-bit values that span two registers?
Yes, twice over. Each Modbus register is 16 bits, so a 32-bit value occupies two registers, and you must agree on the byte order inside each register and on which register carries the high word. Test with a value whose two halves differ; matching only the byte order still leaves the two words in each other's places.
Which bytes in a captured frame are the value bytes?
An RTU frame runs slave address, function code, data, then a two-byte CRC. In a single-register write request, the two value bytes are the last two data bytes immediately before the CRC. Read those two bytes on the capture, compare them run to run, and leave the address, function code and CRC bytes out of any byte-order fix.
Why does the panel offer a byte order choice if the wire order is fixed?
The specification fixes the wire order, but combining the two received bytes into the number on screen happens inside the panel, and that step is what the setting controls. It is a rendering choice, which is why the frame stays identical while the displayed value flips between 1234 and 53764.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.