advertisement
from the none department...
32 bit values and Modbus
Application Questions and Problems topic
Posted by Paolo Rossi on 30 March, 2011 - 5:38 am
When a 32 bit integer value from a device must be read from two adjacent registers, is there a specification which says which register must be shifted?

Normally, if REGISTER1 has offset=1 and REGISTER2 has offset=2 I obtain the value in this way:

value = (REGISTER1 << 16) + REGISTER2

Is this the normal way of proceeding or there's not a rule and some manufacturer can apply the following rule as well?

value = (REGISTER2 << 16) + REGISTER1

thanks


Posted by Network Sprocket on 30 March, 2011 - 9:03 am
> is there a specification which says which register must be shifted?

Sadly, no. You have to read each manufacturer's data sheets carefully, or conduct experiments to see which register is more significant.

One little-endian, two little-endian, three...


Posted by Rob on 30 March, 2011 - 2:13 pm
There is no hard rule. MODBUS specifies 16 bit integers or booleans only, everything else is non standard and up to the manufacturer or programmer.


Posted by M Griffin on 30 March, 2011 - 2:27 pm
The Modbus spec does not cover 32 bit data and there is no standard for it. You should be flexible and able to accept the data either way.

This is actually quite a problem not just with PLCs, but with all sorts of computing applications such as using data from a mainframe computer on a PC. Different microprocessors use different byte and word ordering, and what's more some microprocessors can actually be configured to work different ways.

I will give you a generic example:

Lets assume we have 2 16 bit integers: [0,1]

If we convert those to a binary data "string" using what is called "network order" (which is what Modbus uses) we get (in hex): '00000001'.

If we convert that back to a 32 bit integer using "network order", we get: 1

Now if we did the conversion of the data using the opposite byte ordering format we get: 16777216.

Here's the problem however. The normal standard for network communications is called "big-endian" (this has been the accepted communications standard for decades). Intel microprocessors however use "little-endian". Motorola and Power CPUs are "big-endian". Arm processors are switchable. Communications data conversion libraries *should* handle this seamlessly. There is nothing though to stop someone from writing their own conversion routines which mixes both methods together in some sort of weird way.

Ideally, there would be one "right" way to do things and everyone would use it. However, you have to be prepared to work with what people are actually using. Often, the only way to be sure what a particular device is doing is to test it with some known data.


Posted by Lynn August Linse on 5 April, 2011 - 10:27 am
> When a 32 bit integer value from a device must be read from two adjacent
> registers, is there a specification which says which register must be shifted?

As everyone says:
1) if you are a client/master, then you need to handle either form

2) if you are a server/slave, it is best to be configurable, otherwise pick one and publish it.

Historically, Modicon PLC would put low-word first since they used Intel i386 chips in the first floating-point enabled PLCs (so little endian). When they applied byte-swapping under Modbus, the low-word remained first.

Many third party firms instead took the "Modbus is big-endian" mantra to heart and placed big-word first.

I am involved with SunSpec.org (SunSpec Alliance) which is defining Modbus register mapping for renewable energy. They spec these as big-word first only, which seems to be the norm in solar inverters and power meters.

Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2013 Nerds in Control, LLC. All rights reserved.

Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.


Fortune
... and furthermore ... I don't like your trousers.
Advertise here
Advertisement
our advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive