Need help with AllenBradley PLC data type conversion

[Pandiani]

Hi guys,
I have no experience when working with AllenBradley PLC, but I hope someone could clarify the result of multiplication shown in the attached picture. As far as I know, the input variable is REAL and output is DINT.
But the result is really strange and it is not the simple integer part.

 

[plvlce]

Obvious questions to ask:

Is this instruction currently being executed?

Is the Position variable modified (set) in multiple places in the program?

 

[Pandiani]

Obvious questions to ask:

Is this instruction currently being executed?

Is the Position variable modified (set) in multiple places in the program?

Great questions, but I don't know the answers, jut got a screenshot as attached, hopefully I'll have access to the actual running PLC program tomorrow and will know more.
At first I thought this is bit string manipulation issue (REAL binary representation vs DINT bin representation)but it seems not.

 

[drbitboy]

Obvious questions to ask:

Is this instruction currently being executed?

Is the Position variable modified (set) in multiple places in the program?

^^^this

A more important question to ask than "what is happening?" is "when is it happening?"

In this case we need to know when the displayed value of dPosition is sampled for display. If it is immediately after that MUL instruction is evaluated, then the result shown would be strange. But it is more likely that the displayed value was sampled during the time between program scan cycles, so many other instructions could have overwritten the value of dPosition between the time of the MUL instruction evaluation and when its value was sampled for display. E.g. this could have happened:

​

 

[BachPhi]

Is this coming from chatGPT again?

 

[JaxGTO]

Just tried it in Emulator version 30.0 and got 1978259

 

[GaryS]

It looks like you problem is in the conversion
If the source is a REA data type and the destination is DINT data type
When the function runs it must first convert the 2 data types to the same type
In this case it would convert the Source (REAL) to DINT and then convert the multiplier to DINT then do the math and place the result in the destination.
When the REAL data type is converted it is rounded off producing the effect you see.
You best option would to would change the destination to REAL data type variable, do the calculation. Then convert the result to a DINT type variable I think you will see a better result
you should always do math functions using the same data type then convert the result

 

[Pandiani]

Hello and thank you for the replies. I still don't have access to a complete AB program in RSlogix. However, I have a "wider" screenshot.
Can you please help me understand BTD blocks. From this, I can conclude that 32 bit is placed into two 16 bit words. First bits from 0 to 16 are transferred and then the remaining 16bits (from 16th bit to 32nd bit) are transferred to another WORD.
What I cannot understand are the actual values shown. If the dumber (DINT) is really 10938900, its bin representation is: 000000 10100110 11101010 00010100

So, the first BTD block should transfer 16 bits (from bit 0 to bit 15) to MCParaWord0 and the second transfer from bit 16 to bit 32 to MCParaWord1

Can you explain how values are calculated?
For example 11101010 00010100 corresponds to 59924?

Thank you!

 

[Ken Roach]

It is common to sneak a floating-point number into a data block by packing it into the bits that would be otherwise occupied by integers.

In this case, your floating point value is a "IEEE 754 Single Precision Floating Point" value, 32 bits in length.

It's being packed using a Bit Field Distribute (BTD) instruction, into two 16-bit signed integers, which would be 15 data bits and a Sign bit if they represented Integers. RSLogix shows you the decimal value of that data if it were encoded as an integer. But it's not.

You already understand how integers are represented by each bit, in Two's Complement Binary: the data bits each represent a power of 2: 2^0, 2^1, 2^2.... and so on, and the Sign bit inverts them all.

But IEEE 754 works differently, and the communications link is really just passing an array of bits: it doesn't do any conversion or interpretation. So we have to think about those two "integers" as an array of bits that encode an IEEE 754 value. There are three segments of that group of 32 bits: the sign bit, 8-bit "exponent", and the 23-bit "mantissa" (aka "significand" or "fraction").


I'm not going to try to explain it because I'm a lousy teacher. But here's a couple links to guys who are good teachers:

https://www.h-schmidt.net/FloatConverter/IEEE754.html

https://mathcenter.oxford.emory.edu/site/cs170/ieee754/

 

[Pandiani]

Thank you Ken, very helpful.
Regarding the MUL instruction problem, it was corrected in a way to multiply and store again into REAL variable and then to truncate to DINT. And that worked as expected.
Thank you all for you valuable inputs. This is solved.

 

[drbitboy]

can you explain how values are calculated?
For example 11101010 00010100 corresponds to 59924?

32768 * 1 =>              32768
|
|16384 * 1 =>             16384
||
||8192 * 1 =>              8192
|||
||| 2048 * 1 =>            2048
||| |
||| | 512 * 1 =>            512
||| | |
||| | |     16 * 1 =>        16
||| | |     |
||| | |     | 4 * 1 =>   +    4
||| | |     | |          ======
||| | |     | |           59924
11101010 00010100
   | | | ||| | ||
   | | | ||| | |1 * 0 =>      0
   | | | ||| | |
   | | | ||| | 2 * 0 =>       0
   | | | ||| |
   | | | ||| 8 * 0 =>         0
   | | | |||
   | | | ||32 * 0 =>          0
   | | | ||
   | | | |64 * 0 =>           0
   | | | |
   | | | 128 * 0 =>           0
   | | |
   | | 256 * 0 =>             0
   | |
   | 1024 * 0 =>              0
   |
   4096 * 0 =>                0

 

[drbitboy]

I understand it is solved, but something is still rotten: the MUL instruction should have promoted the 10000 to REAL, done the multiplication with those REALs to calculate the correct REAL product (1.97M+), and truncated/cast that REAL product back to a DINT, all by itself.

See the example below.

• MicroLogix/RSLogix 500, but still
• F8:2 (~197.82588) is REAL
• N7:0 (10k) is 16-bit Integer i.e. INT
• L9:0 (1978259) is 32-bit Long i.e. DINT

What version of Logix is in play here?

​

 

[drbitboy]

And excuse me for beating a dead horse, but the (-24288,7) word pair displayed in Post #8 also make no sense: those words come from a DINT value of 500k, not 1.0M; see the attached image:

​

 

[Pandiani]

Hello guys, something was way off. Like I said in the first post, I didn't have access to actual running PLC program so I couldn't be able to experiment. I would probably figure it out if that was the case. A colleague of mine sent me the original screenshot asking for opinion what could it be. In the meantime he got a new version of PLC program, which, after download worked without any problems or strange behavior. He asked the creator of PLC program what was the cause and got that short clarification without getting into much details. Screenshot in post #1 was totally unexplainable to me.

 

[GaryS]

Wow I see a lot of things passed around here
First Logix processors do use Floating point numbers in fact they have no provisions to use them at all
All numbers are Real, DINT, INT
Keep in mind that inside any computer all data is stored as DINT (32 Bit Words ) or on newer systems as LINT ( 64 Bit Words ) we have to tell the program how to use the data. Even string data types are stores as SINT ( 8 Bit Words ) so trying to convert from Real data to INT will not work as expected and will give you an error
Take a few minutes and do a little research to understand data types.
And as I said before all math in a PLC should always be the same data type then convert the data in a separate function
In the posters problem it looks like the Real data is converter to a DINT type before the math. This will reduce the resolution of the data and round the trailing data to fit the data type. Them when the math is preformed the result will be the rounded number with a much reduced resolution