Transferring 32 bit Data Via MODBUS Protocol

V

Thread Starter

vutq

Hello All,

I have 2 questions need support:

1) Can we transfer/receive Real data (32 bit) thru MODBUS protocol?

2) Some SCADA/Metering Supervisor Computer transeive Real Data by separating it to 2 parts (High Byte Int (16bit) & Low byte Int (16bit)). How to know that system follow Little Endian or Big Endian?

Thanks,
Vu

<b>Moderator's Note:</b> I think <i>transeive</i> is transfer/receive
 
Although the Modbus standard does not define data formats, it is very, very common for Modbus to deal with 32 bit 'real' or 'floating point (FP)' values. The caveat is that the master needs to be able to interpret the 32 bit real or floating point values. Does yours?

To my knowledge, the IEEE754 standard is always used to define the format of the floating point value (number of bits in the mantissa and exponent). There might be one wildcat Modbus product that doens't use IEEE 7548, but I haven't run into it.

As you are aware, there are multiple formats for 32 floating point, sometimes referred to as Big or Little Endian. There are 4 combinations of word and byte order. I've only run into 2 of the 4 in 20 years of doing this.

You can do it the hard way and research which floating point format the slave has and then research what the master calls its floating point formats and decode it all (there's no standard terminology so it's a mess), or you can do what I do - do it empirically - read the value into the master and if it is a really bizarre value, like 3.77852^10-17, when it should 17.34, then switch to the alternative floating point format interpretation, which is more than likely to give you the correct 17.34 value (if you aren't off by one in the register addressing).

The generic Modbus master Modscan32 has two buttons for selecting floating point format - button labeled Floating Pt displays one FP format and the other button labeled Swapped FP displays the other word/byte FP format. Switch between the two and one of them will display the correct value.

A couple of the freebie Modbus masters only do one of the four formats, but the trial version of Modscan32 does both of those that are widely used in Modbus.
 
Hello David,

Thank you for your reply.

In my plant,I am using ABB-DCS Advant Controller. From the 1st day, they designed Modbus Communication Data as Binary & 16-bits Integer for transfering/receiving (transeive) Real/Binary, following IEEE745.
And of course, having sub-function block to combine 2 16-bits Int into Real.

But as I known, they (Controller) have 4 types in Data Block for Modbus (Boolean/Int/Long-Int/Real). Thus, I concerned whether 32-bits REAL Direct Transferring or not. If be able, why don't they use it directly?!
 
One would assume that a modern DCS would handle all four common formats, boolean, integer (signed or unsigned), 32 bit long integer, and the two common floating point formats and would do it without the need for conversion. Things are what they are, but it sounds like ABB covers those bases.

As to why any given sub-function exists, in this case, to combine two registers into a real (FP) [or vice versa?], I can only speculate.

First, it might be a conversion from a real/floating point value to a long integer?

There are known issues with totalizing with floating point because there's a point at which adding a very small number to a very large number (a large total) can result in no apparent change or increment (machine epsilon). Some people prefer to use long integers for totalizing, because integer math always recognizes an small incremental value summed to a large value, that is, until the total reaches its maximum.

Another reason for the sub-function might be that at one time, the method of handling any of the four floating point formats would be bang the bytes of the two 16 bit registers around to rearrange to the byte/word order to get the needed to intrepret format. Note that Modbus is NOT two 16 bit integers, it is two 16 bit registers with a defined mantissa/exponent format. That's not the same as two 16 bit integers end-to-end.

It could be a legacy feature. Why remove an already implemented, formerly used function? it'll only make someone mad who's still using it. <rant on> Take me, for example, I'm furious because this stupid Lenovo laptop that has eliminated key board entry of extended ASCII character with ALT + ASCII numerical code. Instead of ALT+number, I have to open the character map, find, select and copy the character, then paste it where I want it, rather than type it when it I need it from the keyboard. Why? 20-something cube programmers don't use extended ASCII to text their friends. Of course, they don't. They don't need math symbols, plus/minus or the little circle for Degrees. All Lenovo had to do was provide for numerical key entry - it's a full sized laptop keyboard. The competitors do it! But no, take away because no one uses extended ASCII. I wish I had a Dell. <rant off>

Maybe someone else has an insight as to the sub-function.
 
Top