Hi,

I have recently noted that floats/real in my PLC 5 and ControlLogix controllers saturate their floats at 2^24.

This is excerpt from the help file:

The controller data types follow the IEC 1131-3 defined data types. The predefined, atomic data types are:

Data type Description Range
BOOL 1-bit boolean 0 = cleared
1 = set
SINT 1-byte integer -128 to 127
INT 2-byte integer -32,768 to 32,767
DINT 4-byte integer -2,147,483,648 to 2,147,483,647
REAL 4-byte floating-point number -3.402823E38 to -1.1754944E-38
(negative values)and0and1.1754944E-38 to 3.402823E38
(positive values)
The controller handles all immediate values as DINT data types

The REAL data type also stores ±infinity and ±NAN, but the software display differs based on the display format.

I cannot find the reason for this saturation. The value are counters and only get incremented. Could it be that there is an intermediate buffer that constrains the value?

If anyone has experienced a similar issue, help would be appreciated. I suspect it could be a firmware anomaly, but stopping the controllers to check is not possible without scheduling it.

Thanks,

I'm taking that by 'saturate' you mean that adding '1' to the float no longer increases it. Any type of computer number system has a limit. The limits on SINT, INT and DINT are fairly understandable.

A float/real takes a little more understanding. Imagine a chart showing, with zeroes, the possible range of reals. We see thirty-eight zeroes to the left of the decimal point and thirty-eight zeroes to the right of the decimal point (this is just for the positive numbers.) You think, 'wow, I can store a number with 64 digits!'. But no you can't. The Real actually stores a window of these numbers which is 24 bits wide (not 24 digits, 24 bits). This 'window' of values is the mantissa. Starting from zero the mantissa is centered around the zero. You start adding ones. As you get higher the 'window' has to shift to the left a bit as you keep adding (with the exponent, the 'position of the window' increasing.) You keep adding and adding, the window keeps shifting and shifting. But finally you reach a number where adding one more creates a new number that the 'window' can't entirely cover. This is your 'saturation' point.

If you want to count this high you would be better off using the DINT representation. While it, lke the others, has a limitation, it is more understandable.

Just in case it hasn't occurred to you, the flexible positioning of the 'window' is the 'floating' part of 'floating point'

We have had several threads that discussed this here. Try the forum search tool to see some of those discussions.

The most you can count by units of one is 16,777,215. This is a limitation of the IEEE754 32 bit floating point format, not a limit of your PLC, and all computers that use that format (which is most computers in the world) suffer from the limitation. 64 bit floats also have the limitation but at a higher value. Another limitation is the inability of a float to express certain numbers exactly, for example 0.10 cannot be represented as an exact value.

Once you reach (2^24)-1 cannot count by units of one but you could count by units of two for a time, then as the number gets even larger you would have to count by units of ten, then even larger units. This is the resolution of your floating point number, the larger the number becomes the less resolution you have.


If you would like to see how various floating point numbers look and work here is a tool that will show you the format and how the number is expressed in a computer.

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