endianness for 32 bit data


MODBUS is Big endian, ok " MODBUS uses a ‘big-Endian’ representation for addresses and data items. This means that when a numerical quantity larger than a single byte is transmitted, the most significant byte is sent first. "
For me a 32bit value is without any ambiguity a "numerical quantity larger than a single byte "
For me a 32bit value must be registered in big endian in a MODBUS table.

I discuss with a friend about litle to big endian conversion on an ARM microcontroller and he asserts me that we can (for him we must even) change the endianness only by 16bit register.

For exemple if i have to pass the value 287454020 (0x11223344 ). In my ARM memory this is recorded in little endian (0x44 then 0x33 then 0x22 then 0x11)
For me MODBUS must transmit 0x11 then 0x22 then 0x33 then 0x44 (a nice 32 bit value in big endian), I always saw that.
For me friend MODBUS can (for him we must even) transmit 0x33 then 0x44 (the first register with the reverse endianess ) and then 0x11 then 0x22 (the second register with the reverse endianess)

This mixture of endianess seems very ugly to me. For me a modbus device doesn't have to worry about the endianess of the other device's cpu and not inverting the registers is a 32 bit representation error.
"a numerical quantity larger than a single byte is transmitted, the most significant byte is sent first. " is so clear.

Where's the real in there ?
did i miss something in the standard ?
Do you know a slave who uses this barbaric notation for a 32bit (that I look at his definition of the modbus table) ?

thank you very much in advance
Executive summary:
Endianess can be and is different for data formats than it is for the bit order in serial transmission

Section 4.2 in the "MODBUS Application Protocol Specification V1.1b" is source of your quote "Modbus uses a big-Endian representation for addresses and data items." Here's a screen shot of the rest of the section:

Modbus is Big-Endian in serial transmission.JPG

The key to interpreting these statements are the words related to 'transmission' and 'sending', meaning that this statement relates to the order in which bits are sent down the serial line, which end of a byte goes first.

>did i miss something in the standard ?
Yes, you did. The statement above relates only to the order of bits sent down the transmission line, it does not relate to the formatting of the data put into the server/slave registers. The formatting of the data is entirely up to the implementer/vendor. That's been true since day one.

The facts of life are that there are four IEEE754 formats for 32 bit data and a device can be Modbus and use any one of those four formats. It's up to the master/client to interpret the bits properly, because interpretation of the bits is part of application layer in the OSI model, it's not what Modbus is concerned with. Modbus is responsible for transferring the bits from the specified registers - not interpreting them. Interpreting is the job of the Master/client software firmware.

If you're involved with a master and its functionality, providing the logic to swap bytes around will cover a lot of bases in Modbus, because there tens of thousands of devices and they each have their own implementation. And the implementations are all over the map.

My experience with slaves is that most vendors provide just one floating point format and leave it up to the master/client to bang bits to get the right interpretation format. Some offer a choice two formats. I just ran into one where the default was Big Endian but one could pick any of the other three with the device's config software.

Here's one vendor summary of the four formats and the claim that Modicon and Wonderware use one of the formats. I would expect that Wonderware, being a major HMI product, has the ability to interpret any of the four FP formats, but I Ihaven't checked it out and it's not my table.

Honeywell floating point formats.jpg
Thank you very much for your answer

It's a very strange possibility
FP B is pertinently described "Big endian Format" (the true one) and FP BB "xxxx with byte swapped" (so, the not true big endian). Why was it alowed to make "half" bigendian "half" litle endian.
And 20 years that I use modbus devices I had never encountered anything other than FP B (°_°) luck or bad luck

=> So, I just have to complexify my code to manage all these cases...

Just a last question : you talk about the IEEE754 (floating point numbers)
what about standards for 32 or 64 bit signed or unsigned integers?

Thanks again
I'd say you're lucky if you've only encountered one FP format over a number of years working with Modbus.

For integer info, I'll refer you to Wikipedia's page on integers because I'm not a programmer, just a Modbus implementer.


Note F at the bottom of the page:
The ISO C standard allows implementations to reserve the value with sign bit 1 and all other bits 0 (for sign–magnitude and two's complement representation) or with all bits 1 (for ones' complement) for use as a "trap" value, used to indicate (for example) an overflow.

So there's a standard for you.

I have to admit that I've always assumed negative integers were a 2's complement format but I can't remember ever checking the bit pattern because I haven't needed to of a known negative value formatted as a signed integer.

The slave vendors usually state register formats as a signed or unsigned integer value with whatever assumed multiplier is used (*10, *100). Usually.

One vendor had a product that could not resolve better than 16 bits, but for reasons unknown used a 32 bit long integer, always packing the high order word with zeros. It worked OK to read both registers, but interpret only the low order word as a 16 bit integer. (whatever the variable was it was positive only, no negative range).