Hi

I am writing a modbus RTU application in which I am using Holding register (03) command primarily. This application is a Modbus RTU slave and sends data point values to the master.

Few of my data points are signed 32 bit numbers. I am wondering how to assign registers for these 32bit data points? Since each modbus register can be used store a 16 bit number, in the case of 32 bit number should I use two registers?

For Example: 32Bitdata - mapped to 40001 and 40002 something like this? I would appreciate if any one could comment on this. Thanks in advance for the help

Kelly

 

Quite simply, yes.

 

Actually, Modbus RTU data is sent in 8-bit bytes, so yes you will need to have the Master request multiples of (2), so even if you had 64 bit data you would just request (4) Registers.

 

Kelly,

This is a subject that gets covered periodically on the Automation List.
Have a look at these previous threads:

"32-bits data with MODBUS protocol"

http://www.control.com/1026172191/index_html

"If I have a float value (32 bit,) how I must place it in the message frame?"

http://www.control.com/1026185854/index_html

"data encoding for 32-bit data values:"

http://www.control.com/1026161289/index_html


Regards,

Greg Goodman

 

Kelly,

My impression is that the most common way to represent 32-bit data is little endian. i.e., the register 40001 contains two lower order bytes, the register 40002 contais the two high order bytes. Note that the order of bytes inside each of the registers is big endian (which is the standard modbus byte order).

For example, if your 32-bit number is 0x12345678, then it would be stored like this:

40001 - bytes 0 = 34, bytes 1 = 12
40002 - bytes 0 = 78, bytes 1 = 56

I often use Appendix B of the following documents as a reference:
http://www.eecs.umich.edu/~modbus/documents/Open_ModbusTCP_Standard.doc

Eugene Zharkov
http://www.vista-control.com

 

Yup, I second this - odd as it seems to have LittleEndian words and BigEndian bytes in the words, that seems to be how Modicon 984 handled the floating points.

A master/client SHOULD be configurable to accept both orders for words, but a slave/server could pick this design.

- Lynn

 

I guess I understood correctly your proposal:

1) "big-endian" for words order ;
2) "little-endian" for bytes order inside a word.

For me it seems strange, and not compliant with Modbus rules. Modbus specification indicates bytes orer inside register, and it is "big-endian".

Then I suggest to be simple, (rational, wise, etc... !) and to use big-endian rule everywhere.

It means, if you have a 32-bits value such : 0x12345678, you should encode it as:
0x1234 ==> register #i
0x5678 ==> register #i+1.

Note: the document you are refering to is obsolete. Only "Modbus organization" is relevant to decide which standard must be observed.

 

Thanks guys for all the information. This is very helpful!

Thank you all again!

Kelly

 

First of all, I should corrent myself. If meant to say that if "the 32-bit number is 0x12345678, then it would be stored like
this:
40001 - byte 0 = 0x56, byte 1 = 0x78
40002 - byte 0 = 0x12, byte 1 = 0x34"

i.e.:
1) "little-endian" for words order;
2) "big-endian" for bytes order inside a word.

I certainly did not want to make my message sound like a "proposal". It is more like an obvervation of the behaviour of different types of hardware that I dealt with. I have seen many devices that fall into the "little-endian for words" category", and so far only one that uses "big-endian for everything". The latter was enron-style device. I guess here I should add that "the poll is not scientific" (as they say on CNN).

Regarding "Modbus organization", do they really specify which standard must be observed ? I could not find anything on modbus.org, and therefore have no other choice but to like the "obsolete" specification that I referred to .

Eugene Zharkov
Vista Control Systems, Inc.

 

I agree. To be consistent with the spec, it should be Hi byte to Lo byte. But since data formatting is up to "YOU", then do whatever you feel is necessary. I offer ALL forms of byte order in my products, with big endian being the default.

The other rationalization is that the lower address should have the lower word. So 400002:400001 = 0x12345678 instead of 400001:400002 = 0x12345678.

 

MODBUS has (or at least had) a primary purpose - to exchange data between a MODICON PLC and the outside world. MODICON PLC's originally handled only 16 bit data (non-negative integers). When 32-bit data was added to the PLC, it was split between two consecutive registers (e.g., 40001:40002) with the big "end" in the first (lower reference number) register. Consequently, when one transports two such registers in MODBUS, one gets the
presentation described above. In other words, MODBUS does not transport 32-bit numbers - it transports only 16-bit entities (registers) - and it is up to the user to interpret the application-level 32-bit value of a consecuitve pair of.

Meir

 

<pre>decimal
Position(address) 7 6 5 4 3 2 1 0
weight 10^7 10^6 10^5 10^4 10^3 10^2 10^1 10^0
weight 10'000'000 1'000'000 100'000 10'000 1'000 100 10 1


Binary (bit)
position (address) 7 6 5 4 3 2 1 0
wheight 2^7 2^6 2^5 2^4 2^3 2^2 2^1 2^0
wheight 128 64 32 16 8 4 2 1


LITTLE address for the ENDIAN digit
Int16 (little endian order for byte inside int16)
position (address) 1 0
weight 256^1 256^0
weight 256 1


Long32 little endian order for int16 inside long32)
position (address) 1 0
weight 65'536^1 65'536^0
weight 65'536 1


Full little endian order for long32
position (address) 3 2 1 0
weight 256^3 256^2 256^1 256^0
weight 16'777'216 65'536 256 1


 
BIG address for the ENDIAN digit
Int16 (big endian order for byte inside int16)
position (address) 1 0
wheight 256^0 256^1
wheight 1 256


Long32 (big endian order for int16 inside long32)
position (address) 1 0
weight 65'536^0 65'536^1
weight 1 65'536


Full big endian order for long32
position (address) 3 2 1 0
wheight 256^0 256^1 256^2 256^3
wheight 1 256 65'536 16'777'216


Mixed
A example: big endian (for byte in int) and little endian (for int in long)
position (address) 3 2 1 0
weight 256^2 256^3 256^0 256^1
weight 65'536 16'777'216 1 256</pre>
Conclusions:

A number in our mind is transferred to paper (or in the air with our voice or computer with keyboard), starting chronologically from the most significant digit (communication protocol between our minds and support of artificial memory). On paper, the index position zero (the rightmost but only for us who write from left to right for instance) or the address zero is marking the least significant digit. I think also on the memory card hardware should be the least significant digit has the address (or index position) lowest. It is normal that the index that takes into account the chronological order of arrival of bytes in the communication (whichever the number of grouped bytes) is inverted relative to the index that takes into account the weight (position) of the digit. An example is the expression of a component of a wave that propagates bringing information: exp[i (wt - kx)] : time and position have opposite sign!

I think it's just confusing the type mixed big-little endian.
So: "Full" Big Endian for communications and "Full" Little Endian for Storing (and consequently computing): this is the choice humans have done long before Alan Turing.