slc floating point-what am i doing wrong

Have a program I am developing and have some code where I increment or decrement a floating point and later use that in the program to change speeds of motors.
I have a attached a print of the code where I decrement. If for example, F12/0 contains a 3 and I want to decrement it, then when the operator button is pushed, it does decrement the value, now here is where I am confused. When the value gets to 0, as you can see from the post, it then goes to -0.1

Based on the code, at the moment I do not understand how that happens. Could someone explain why? Thanks

Try this:

Or change the source B in the GEQ instruction to 0.1

Or change the GEQ to a GRT.

Also note that you may see some oddball numbers when you add and subtract using floats.

Alaric has some great posts on this subject.

Thanks
made the change to GRT and then put in some code to clamp the value ( should have clamped it first time around)
Attached a copy, works on the bench.

Looks good.

You can delete the OSR instructions in rung 6 which clamps the values, since they will only execute once each time the value is out of range anyway.

EDIT: Also change the LEQ to a LES if you do that.

Paul

Floating point numbers in a computer have a property known as precision. There are many numbers that cannot be represented exactly. Your PLC uses the IEEE754 floating point format, which is what almost all computers use. But you are limited to what can be represented using a 7 bit binary exponent and a 23 bit binary mantissa where each bit represents 1/2^n , that is 1/2 + 1/4 + 1/8 +1/16 + 1/32, etc.
One problem that arises then is the impossibility of exactly representing any base 10 number i/10^n, that is .1, .2, .3..., or .01, .02, .03... or .001, .002, .003..., etc.

So, in your case, after you decrement 3 by .1 (actually .099999994 - the closest you can represent .1) twenty nine times and account for loss of precision in your answers, you have 0.10000061, which is not the same thing as .1 (again, actually .099999994), The next time you get .00000610947609 (what gets stored as the closest precision result) which is still greater than 0, allowing you to subtract one more time.

What to do about it?

First, what is the range of numbers you are working with? If it is less than 3276.7 then increment and decrement an integer, then divide it by 10 and store it in a float. This will give you the closest possible floating point approximation.

If that range of numbers doesn't work, then add a check right after you decrement to see if the number is less than 0 and if it is then move 0.0 into the float.


edit: I see I need to type faster. Oh well, hopefully it helps you understand what is happening.

Thanks for advice.
Great info