Adding to a REAL number gives an unexpected sum?

[Duranthas]

First, a background on the equipment so you know what is going on. I have an AB ControlLogix L63 processor controlling some Mitsubishi MR-J4-500TM4-EIP servos. The AOI instructions from Mitsubishi controlling the drives make it very similar to the native AB motion commands. The position field of a MAM (MMAM using Mits AOI) is REAL, just like AB.
Now, all that said, I have a part which requires a second cut that is a specific distance from the first cut. On the HMI, I only give the option to adjust the distance of the first cut, and then I use a math function to add the 0.780" distance from the first cut for the second cut. For some reason unbeknown to me, my value is a bit off and it doesn't matter if I use ADD or CPT to do it. If I add 0.78 to 13.74, instead of getting 14.52 which is what I would expect, I get 14.5199995. Why is there a discrepancy in the math? The only reason I found this is that I was using the equals (EQU) to compare the servo actual position to the assigned position. If they matched, then I knew the horizontal slide was where it needed to be before I commanded the vertical slide to move to cut depth. As it turns out, 14.52 does not equal 14.5199995 so my EQU run was never going true.
Any guidance as to why adding a constant to a REAL does not give the expected value would be greatly appreciated. I know this is going to be detailed and nerdy, but I really want to know.

 

[Bit_Bucket_07]

Here,

Dive in!

https://en.wikipedia.org/wiki/Machine_epsilon

 

[Bit_Bucket_07]

First, a background on the equipment so you know what is going on. I have an AB ControlLogix L63 processor controlling some Mitsubishi MR-J4-500TM4-EIP servos. The AOI instructions from Mitsubishi controlling the drives make it very similar to the native AB motion commands. The position field of a MAM (MMAM using Mits AOI) is REAL, just like AB.
Now, all that said, I have a part which requires a second cut that is a specific distance from the first cut. On the HMI, I only give the option to adjust the distance of the first cut, and then I use a math function to add the 0.780" distance from the first cut for the second cut. For some reason unbeknown to me, my value is a bit off and it doesn't matter if I use ADD or CPT to do it. If I add 0.78 to 13.74, instead of getting 14.52 which is what I would expect, I get 14.5199995. Why is there a discrepancy in the math? The only reason I found this is that I was using the equals (EQU) to compare the servo actual position to the assigned position. If they matched, then I knew the horizontal slide was where it needed to be before I commanded the vertical slide to move to cut depth. As it turns out, 14.52 does not equal 14.5199995 so my EQU run was never going true.
Any guidance as to why adding a constant to a REAL does not give the expected value would be greatly appreciated. I know this is going to be detailed and nerdy, but I really want to know.

As for dealing with your issue from a programming standpoint, you could set up deadbands around your target value and use > and < compares to the deadband values, rather than using an EQU compare.

 

[bernie_carlton]

Note: I'm using the calculator link here It's a great visual aid and learning tool.


The closest representation in floating point for 13.74 is actually 13.7399997711181640625


The closest representation for .78 is 0.7799999713897705078125


So you can see where the error comes in.

 

[Duranthas]

Awesome, that's exactly the stuff I was looking for. Thanks guys.

Bit_Bucket_07, the way I got around it was I made a rung where I take my target value and add and subtract .002, storing those values in an upper and lower values tag. Then I use the LIM function with those as my upper and lower values in comparison to my target. I could probably get away with 0.001, but my spec is wide enough that 0.002" won't hurt the Cpk much.

 

[ASF]

Your other option is to use integers, and have them represent thousandths of an inch. Integer math is much more reliable than floating point math.

So instead of 13.74", your integer reads 13740. Then you can either use the SCADA to scale the value for display purposes, or have the PLC move the end result to a float for display purposes (divide by 1000), only after all of the math is done using integers and thousandths of an inch.

 

[JesperMP]

Integer math is much more reliable than floating point math.

I little too optimistic statement.
As long as you only add and subtract and stay within the range of values that can be represented by the integer - then yes.

 

[BobB]

You will probably have to turn the constant into a float/real in the PLC. There should be an instruction to do that. I have to do this all the time.

 

[parky]

Don't use equals use equals to or greater than. the problem you have is that due to the known errors in floating point maths (event though they are small), you are only using 2 decimal places anyway, so your compare is looking for a number that has say 7 decimal places, you only have 2 as your actual. using equals on it's own is a recipe for disaster on an encoder plus maths so if the actual figure is missed i.e. it passed by even 1 decimal place then it would continue to end limit I always use => or =< so if the encoder resolution is only 2 or 3 decimal places then it will trigger.
So for example if your set-point is 14.1234567 and your encoder resolution is only 3 decimal places then when it reaches 14.123 as the required position it is not equal, when the encoder reaches 14.124 it has overshot so can never be equal only if both the encoder & maths functions are to the same decimal places can it be true. which will never happen.

 

[JesperMP]

Btw.
Most HMI programs automatically round the display of the value if you select a limited number of places after the decimal.
So if the HMI is configured to display for example xx.yy and the HMI supports the automatic rounding, it will display a 'neat' 14.52 instead of 14.5199995.
If you observe the value in the PLC online you will see the 14.5199995, but the HMI should display the 14.52.

 

[BachPhi]

 

[janner_10]

Awesome, that's exactly the stuff I was looking for. Thanks guys.

Bit_Bucket_07, the way I got around it was I made a rung where I take my target value and add and subtract .002, storing those values in an upper and lower values tag. Then I use the LIM function with those as my upper and lower values in comparison to my target. I could probably get away with 0.001, but my spec is wide enough that 0.002" won't hurt the Cpk much.

Does the AOI not have a move done bit like the MAM does?

 

[ASF]

I little too optimistic statement.
As long as you only add and subtract and stay within the range of values that can be represented by the integer - then yes.

If you use a DINT to represent thousandths of an inch, your integer can represent roughly 34 miles with a precision of 0.001". I dont' know what the OP's application is, but if they're trying to measure more than 34 miles with 0.001" precision, I'd suggest that a PLC is the wrong tool for the job.

 

[JesperMP]

ASF, it was the blanket statement 'Integer math is much more reliable than floating point math' that I commented.

 

[ASF]

In which application is floating point math more reliable than integer math? Not being combative, I'm genuinely interested in expanding my knowledge on the topic if there's an aspect to it I don't understand. I mean, obviously, if you're dealing with decimal places, then integer math doesn't work for the application, but (a) using implied decimal calculations is one possible workaround for this, as I suggested, and (b) I still wouldn't view that as being "less reliable", only "more limited in it's application".

Edit: after re-reading your post I think I see what you were getting at - integer math is limited by the size of the integer, and can't do divide without rounding or truncating (and thus losing some accuracy), is that what you meant?