Remedying Rounding Errors Discussion

I just kind of wanted to propose a general discussion.

I've recently implemented a program in an Allen Bradley PLC. One of the lines of code used is the following:

Output := (Distance/2)-(Distance*(Dwell/2));

Click to expand...

The variables 'Value', 'Distance', and 'Dwell' were declared as REAL (floating point) data types.

In a specific scenario, the value of Distance is 100.0 and the value of Dwell was 0.7. Now if you do the math, you realize that this expression should assign the value of 15.0 to 'Output'.

However, what is really being outputted is a value of 15.000001. I assume this is do to a loss of precision from using the floating point data type.

My questions for all of you are: Have you ran into troubles with this before? How have you remedied it? Did you make it so that your program logic would not be affected by this slight error?

I'm working specifically on motion logic and am getting compilation errors due to this so the topic has come of interest.

The inability of floating point numbers in a computer to exactly represent single significant digit decimal fractions (ie, .1, .2, .3, .4, .6, .7, .8, .9, .01, .02... .001, .002, etc) exactly has long been known and hashed out many times here on the forum. It is a problem that affects ALL computers, not just PLCs. Some computer programs employ sophisticated routines that detect these cases and display, for example, .1 instead of the exact value of the IEEE float.

One way around this limitation in motion control is to do your math in integer units, be it encoder counts or counts of your limits of resolution, such as microns. All moves will be computed this way, and conversion to a base 10 float ONLY occurs for display purposes.