RSLogix 5000 DINT

pcola · Jun 12, 2012

I have a DINT tag and a Real tag that counts to a maximum of 67108864. It is same for both a real and a DINT. What is the reason for the cap?

bernie_carlton · Jun 12, 2012

The DINT counts in integers only (both positive and negative).

The Real's seperation between counts if very VERY small for very small numbers and gets larger as the numbers get larger. At the point you mention the seperation between counts gets GREATER THAN ONE. So it's not good to use a REAL if you want a continous count of single items. The Real is good for AMOUNTS, the DINT is good for COUNTS.

They both have their uses (and incidently both take up 32 bits) but you must be aware of them.

Ken Roach · Jun 12, 2012

I'm guessing at what you mean by "cap"

http://en.wikipedia.org/wiki/IEEE_754

Most 32-bit logic controllers, including the ControlLogix, use Single-Precision Floating Point to encode floating-point values.

Because floating-point is necessarily an approximation, when you add a small number (like 1.0) to a large number (about 7 million), the approximate value of the small number is zero, compared to the large number.

This is why counters or "totalizers" that use small increments should use Integers if at all possible.

pcola · Jun 12, 2012

I can understand the Real tag problem, but what about the DINT?

And thank you for the quick reply

Ken Roach · Jun 12, 2012

I guess I over-assumed your question

.

The Count Up (CTU) instruction will count to whatever the Preset value is. The Preset is a DINT datatype, so the maximum value is 2^31 - 1 (2,147,483,647).

What instructions are you using; CTU, ADD, or something else ?

pcola · Jun 12, 2012

I am using an ADD block to count rotations of a roll. I am adding a Real number (because of a gearbox ratio 3.12)to the DINT. I am not using a CTU. I tried using a real to see if that would help, but both of the sums still stop at 67108864.

bernie_carlton · Jun 12, 2012

I over-assumed also. Can you detail the particular ADD instructions and the values in both methods? Could there be some conditions to the ADD which no longer fire at that level?

pcola · Jun 12, 2012

Yes - and thank you - I have Tag L55_4004_D17 (DINT) that is added to a real (L55_4004_AUXR13) which is always 3.12 (gearbox ratio). The sum is then displayed to the operators so that they can change the sleeve of the roll after a predetermined number of rotations. This is the longest we have used the sleeve, and generally don't approach this high of a number. So the ADD Block is configured:

Source A - L55_4004_D17
Source B - L55_4004_AUXR13 (always 3.12)
Dest - L55_4004_D17

That is the whole calculation.
When the operator pushed reset, the L55_4004_D17 tag is zeroed out, and starts at 0, then 3.12, 6.24, ...

I tried using a real, but it performed the same way. I did this because I thought there might be a limit for adding reals and DINTs.

I appreciate your time on this.

Ken Roach · Jun 12, 2012

It's the same problem. 1.0 becomes insignificant to 7-million-ish, while 3.12 becomes insignificant to a larger number.

You'll just have to find another way to calculate the number of rotations.

ControlLogix auto-converts data types in the ADD instruction, so REAL + DINT = REAL is a valid way to perform an ADD. The problem remains one of IEEE 754 notation and the fundamental way that floating-point values are handled in microprocessors.

Ken Roach · Jun 12, 2012

Wait, the tag L55_4004_D17 can't be a DINT and have values of 3.12, 6.24 and so on.

Could you just count Motor Rotations by 1's, then perform a single MUL instruction (Motor Rotations x 3.12 = Spindle Rotations) and display that value for the operators ?

pcola · Jun 12, 2012

You are correct, but the L55_4004_D17 rounds the number to an integer. The Voith Handbook has all the values in rotation of the Roll, and not the motor, so Operations wants the value in Sleeve rotations, even though they could multiply it by 3.12. Anyway, I was more interested in why it didn't work, rather than correcting the Operator display. That is why I tried adding two reals instead of a real and a DINT. The results were the same. I could find nothing in Rockwell Literature concerning any limitations, and a web search for the problem didn't generate any satisfactory explanation. So that is when I posted it on the web site. Thank you for your time and sharing your experience.

Mickey · Jun 12, 2012

Add 312 using DINT's then divide by 100 for the operators.

TConnolly · Jun 12, 2012

The processor can't really add a float to an integer. It can add a float to a float or an integer to an integer. So when you add a REAL to a DINT the processor will first converted the DINT to a Real in the processor, then perform real addition, and finally convert the result to a DINT and save it to the DINT tag. Hence you still have the 2²⁴-1 (16,777,215) resolution limit for counting by ones.

This limitation is not unique to PLCs. Even 64 bit machines ultimately have a break down in resolution with real numbers.

Edit to add:
There are a number technote about this limitation in the Rockwell Knowledge Base. Refer to documents 7765, 59372, 29562, 18209, 29562.

rdrast · Jun 13, 2012

Mandatory read:

http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

daba · Jun 13, 2012

Ken Roach said:
I guess I over-assumed your question .

The Count Up (CTU) instruction will count to whatever the Preset value is.

To be pedantic, the CTU (or CTD) instruction is just a counter, and WILL continue to count after the preset value is reached. The Preset is just used to determine when the "done" (.DN) bit is turned on. You will often see A-B counters with a Preset value of zero, i.e. just being used as a counter, and making no references to it being "done"

RSLogix 5000 DINT

pcola

Member

bernie_carlton

Lifetime Supporting Member + Moderator

Ken Roach

Lifetime Supporting Member + Moderator

pcola

Member

Ken Roach

Lifetime Supporting Member + Moderator

pcola

Member

bernie_carlton

Lifetime Supporting Member + Moderator

pcola

Member

Ken Roach

Lifetime Supporting Member + Moderator

Ken Roach

Lifetime Supporting Member + Moderator

pcola

Member

Mickey

Lifetime Supporting Member

TConnolly

Lifetime Supporting Member

rdrast

Lifetime Supporting Member

daba

Lifetime Supporting Member

Similar Topics