ControlLogix real type tag limitations?

Using a ControlLogix L63. I have a customer who wanted to totalize millions of gallons. The CPT instruction worked fine until the totalizer reached 256 and then it just stopped. The CPT is adding approximately 0.00001 each time.

After playing around for a while I discovered that I could key in 256.0001 for the value of a real tag but, 256.00001 is not accepted.

After further playing I discovered the following:

Accepted Not Accepted
2.0000002 2.0000001
2.000001 2.0000001
32.000004 32.000001
32.00001 32.000001
512.00006 512.00001
512.0001 512.00001
2048.0002 2048.0001
2048.001 2048.0001
32768.004 32768.001
32768.01 32768.001
262144.03 262144.01
262144.1 262144.01
2097152.3 2097152.1
2097152.0 2097152.1

Can anyone explain what is happening here and is there some workaround?

IIRC, it's a 32bit IEEE variable. Since it is a Binary number, not all base 10 numbers with that many digits to the right of the decimal can be represented.

Look at Data Types in the Help file for limits. You may want to use a DINT for whole gallons.

The real tag can handle whole gallons just fine. When I divide it by 1,000,000 to represent millions of gallons, the result fails as described.

I'm not as worried about this gallons totalizer as I am with understanding how the real value is represented and do I need to worry about this every time I'm performing any math instructions.

Integer, The Musical

You're looking at the "floating" part of "floating point". Search the archives for IEEE 754 Single Precision Floating Point for several discussions of this effect. The Wikipedia entry on IEEE 754 is also pretty informative.

In short, "Real" or "Floating-Point" values are always approximations and cannot perfectly store all integer values. When you add an increment to a larger value and expect the larger value to increase by that increment, by definition you are performing an Integer function.

This is inherent in the floating-point data format. Any controller or computer, not just Allen-Bradley, will handle 32-bit IEEE 754 floating-point data in exactly the same way.

The real - like other numbers in computers - are held by bits. The bits which represent the fractional parts represent 1/2, 1/4, 1/8, 1/16 etc. There are some fractional values (like 1/3) which will not have an exact representation using these no matter how many you have). Study up on the structure of computer number storage to learn the limits of any number representation. There is no perfect one. Only those more suited for a particular use.

OK, thanks for the replies.

How many gallons are you going to be interested in? A DINT can go up to 2,147,483,647. If you're going to stay under 2 Billion gallons, using a DINT would work just fine.

Would it be possible to work with whole gallons in that float, instead of millions-of-gallons, then representing the single-gallons out in the decimal part?

Or, you could use cascading counters - perhaps gallons and thousands-of-gallons, then concatenate the results back together.

And if you're really working with millions of gallons, does single-gallons even matter?? It seems like such a minuscule portion would just be ignored...

Here is a link:

http://babbage.cs.qc.edu/IEEE-754/

That will give you more info on how IEEE-754 floats work and it has some utilities where you can enter a float value and see what it will look like in binary so that you can understand what is happening.

One solution to your problem is to use a DINT as has been suggested. Another option is to change the units you are measuring with. Instead of totalizing gallons, totalize cubic feet or some other appropriate unit.

As has been suggested, floating point arithmetic is is prone to roundoff while integer arithmetic is exact. Floating point arithmetic errors are minimized by adding terms that are of similar orders of magnitude.
Ideally, your flowmeter would offer pulses according to an accurate time-base; you'd use integer math to produce a high-fidelity totalizer.

If you must use an analog flow signal, establish an accurate timebase, then contruct real-valued fractional increments of your total. As the increment surpasses some threshold, increment an integer counter and reset the real fractional increment.

Don't use some order-of-millisecond timebase for flow totals; think a second or two. Also consider accounting for no-flow situations when an imperfect meter-zero would otherwise erroneously add to your total.

I know I'm a bit late on this topic, but it's worth noting that you can use the MOD FUNCTION to avoid the limitations of real floating point. Especially when dealing with powers of 10 or in this case 0.000001. So MOD(INC/100000) would return the decimal part of the number which could be stored in a dint or string.