Small increment issue with REAL (Logix5000)

The attached pdf shows a CPT instruction that should calculate the value of tag Cell_Charge_Percent_Remaining[1]. I've included the relevant monitored REAL tag values to demonstrate that they are all non-zero.

Apart from an initial result when (for example) the value of the tag Initial_Mass_kg is changed, the calculation result remains static. Is this a case of too small a change in the tags' values -given the high initial result- when the tag Cell_I_x_t[1] increments? From searching posts here, I understand that a REAL of value >7,000,000 will not increment/decrement by 1, and at the time the screen shots were taken, the change per second would have been 0.000847

Have I answered my own question?

BTW, I checked the result with a calculator, which came out as 214,592,274.678, not the program's result of 214,592,288.0

Thanks.

Yes.

Check here: https://www.h-schmidt.net/FloatConverter/IEEE754.html
214,592,272 and 214,592,288 are the two nearest values which can fit in a 32-bit float.

Totalizers are hard. You could use LREALs and that would give you more precision.

actually the limit where a 32-bit REAL cannot be incremented by 1 is 2**24 i.e. 16,277,216

A 32-bit float has one bit of sign, eight bits of (base 2) exponent, and twenty-four bits of mantissa, and 16,277,216 in binary is one 1-bit followed by twenty-four 0-bits until the "binary" point (analogous to a decimal point i.e. the point between digits representing values of 1 or more and digits representing values of less than 1), which is twenty-five bits of mantissa, so the least significant bit of the mantissa is truncated to fit into the 32-bit REAL.

Now that is for adding (or subtracting) 1, but to first-order, the ratio between the subtrahend and the minuend is what is critical i.e. at or below the ballpark of 1 part in 16million is where it is no different than subtracting zero.

Your calculator is almost certainly using 64-bit REALs (LREALs in Logix5k-speak; one sign bit, eleven exponent bits, fifty-three mantissa bits), which is why it can subtract that smaller value from the large one.

As @AustralIan suggests, LREALS will give you more bits of resolution; the program below confirms that 16 is the smallest increment that can be subtracted from a 32-bit REAL value of 214,592,288.0.

Cf. https://en.wikipedia.org/wiki/Single-precision_floating-point_format#IEEE_754_single-precision_binary_floating-point_format:_binary32

On my soapbox again

I know I'm a repeating broken record on this point - and it does not directly answer the original post - but it's important to understand and properly apply data types. IF what someone is doing is incrementing (counting) it's best to not do it into a REAL (float).

There was a timing error that caused a Patriot missile to miss a SCUD. This resulted in a lot of casualties. It was from trying to count discrete fractional events into a REAL - maybe tenths or hundredths. A real may do OK on accumulating halves or quarters but it has no clue how to accurately add up tenths.

There's another post on this site where someone fixed a math problem by switching an INT to a REAL. That may have been the correct solution for that problem but the ultimate answer is to understand how the numerics work before making decisions. I very much appreciate the earlier replies on this thread that assist in that understanding.

How different PLCs handle data typing is another hairball that we could discuss and cuss over several replies. Maybe better let that dog sleep for now.

AustralIan, drbitboy, Corsair, thank you for the enlightenment (well, not the enlightenment) I will examine my options.