Using Real Data Types to mimick a DINT or BOOL Data Tye

I work at a cheese factory and we recently ran into a problem where in an older controller they where able to use a REAL Data type in OTU and XIC logic. has anyone seen this?

Assuming you are referring to Rockwell controllers, I don't think you have ever been able to use REAL types at the bit level. I would need to see this to believe it.

I'm gonna have to be from Missouri here as well.

dmroeder said:

Assuming you are referring to Rockwell controllers, I don't think you have ever been able to use REAL types at the bit level. I would need to see this to believe it.

Click to expand...

check out the attachemnt

Bit "SO.Leny_Real_Reads" and "So.Lenny_Values" are all REAL data types being used at a bit level.

Doesn't the error mean that they are not in fact being used at the bit level, only trying to be used at the bit level?

dmroeder said:

Doesn't the error mean that they are not in fact being used at the bit level, only trying to be used at the bit level?

Click to expand...

So this error popped up when we where trying to install an update to our firmware but what we found was that those 3 rungs would not be accepted with the new firmware update. Then that's when we realized those bits where REAL data types being used a the bit level.

Forgive me if I'm being slow here. I think you are saying that at some point, you were able to use REAL types at the bit level, suddenly you cannot.

I'm saying that you must be mistaken, you have never been able to use REAL types at the bit level. Maybe someone, at some point modified the UDT and changed a DINT/INT/SINT data type to REAL, causing the error?

Edit: usually when I make a confidant statement, someone shows me I have been mistaken, while I'm pretty confidant in my above post, but I've been wrong before...

Edit2: I just created a new L61 project in V16, added a rung with a real type at the bit level, the software seems happy with it.... so I stand corrected, at some point, you could use REAL types at the bit level, it appears you no longer can...

Okay, I did some more testing. It appears that starting at v28 (I don't have 25/26/27) you could no longer use REAL types at the bit level. Odd, I didn't realize that you ever could, I wonder why you no longer can. Seems odd to take that ability away.

dmroeder said:

Forgive me if I'm being slow here. I think you are saying that at some point, you were able to use REAL types at the bit level, suddenly you cannot.

I'm saying that you must be mistaken, you have never been able to use REAL types at the bit level. Maybe someone, at some point modified the UDT and changed a DINT/INT/SINT data type to REAL, causing the error?

Edit: usually when I make a confidant statement, someone shows me I have been mistaken, while I'm pretty confidant in my above post, but I've been wrong before...

Click to expand...

Sorry but here is proof that those bits are being used in that way this snapshot is from 5 mins ago. I wouldn't be on here if that was the case.

Yea thats the problem we encountered have you heard of a way around this?

Is there some necessity to updating the firmware? "If it isn't broke, don't fix it" seems to apply.

delrioal_03 said:

Yea thats the problem we encountered have you heard of a way around this?

Click to expand...

use the COP* instruction to copy the bits from the real to a DINT and then look at the bits in the DINT.

* or CPW or CPS or whatever it is in Logix 5k

drbitboy said:

use the COP* instruction to copy the bits from the real to a DINT and then look at the bits in the DINT.

* or CPW or CPS or whatever it is in Logix 5k

Click to expand...

I agree. The COP copies bit patterns. Do not use the MOV which will move value but change to destination.

A MOV will move 43.1 real to 43 DINT
A COP will move the bit pattern of 43.1 to the same bit pattern
0 10000100 01011000110011001100110

Which according to my windows calculator would be a integer value of 1110206054

delrioal_03 said:

So this error popped up when we where trying to install an update to our firmware but what we found was that those 3 rungs would not be accepted with the new firmware update. Then that's when we realized those bits where REAL data types being used a the bit level.

Click to expand...

Okay, it appears that it's been established that, at one point, RSLogix could access bits of a REAL tag using the same syntax* as for integers. Whether that is (was) a good practice** or not is beside the point***: the question is what can OP do?

It appears the REALs in question are arrays that are part of a UDT, and some of the individual bits some of those REALs indicate states of the system.

One way that state bits could end up in a REAL is from data retrieved via Modbus Function code 0x03, Read Multiple Holding Registers, reading an array of Modbus registers, which are 16-bit unsigned integers, into an array of REALs in the PLC, where the sequence of Holding Registers have varied meanings: Modbus addresses N and N+1 comprise 32-bits of status; N+2 and N+3 together compose a single 32-bit REAL; N+4 and N+5 compose another REAL; etc. Such Modbus addressing is not uncommon.

If that is the case, and the .Bit# syntax was available to the original coder in some ancient version of RSLogix, then it is conceivable that they coded their solution in this way, oblivious to the future possibility that A-B would remove the feature that makes it work.

I'll admit those are a lot of assumptions, but they do seem to fit the narrative. If that is correct, then here is a possible solution, as proposed by @g.mccormick: