RE: [CAD_CAM_EDM_DRO] Re: found a problem... Supertech mill

There are two problems here:
One is that the number is being formatted using exponential notation, which of apparently is not valid in this context. Why the CNC driver behaves as you describe is beyond me; either it has poor handling of incorrect input syntax or it actually thinks the "e-006" means something.

The other is that the program was written using floating point numbers without a proper understanding of their representation and behaviour. In particular numbers like 0.1 are *not* exactly representable in floating point; they form an infinite repeating fraction (just as 1/3 in decimal notation is 0.3333... requiring an infinite number of 3's) which must be truncated to fit into the finite precision of the floating point number.

To illustrate why it doesn't get back to zero, you can try it by hand using decimal notation, stepping from 1 to -1 by 1/3 of an inch using 6 digits of precision (not the same as 6 decimal places):

(0.100000e1 to -0.100000e1 step 0.333333e0): 0.100000e1, 0.666670e0, 0.333337e0, 0.400000e-5, -0.333329e0, -0.666662e0, -0.999995e0, -.133334e1

As you can see the values are incorrect (meaning the 6-digit number you have is not the closest value to the "true" value you would get with infinite precision) starting right off the bat.

If these values are rounded to the nearest 0.0001 they become 1.0000, 0.6667, 0.3333, 0.00000, -0.3333, -0.6666, -1.0000, -1.3333 which all appear correct. If they are rounded to 4 digits of precision, you get the same values except the zero is replaced with 0.000004, so the numbers would all appear correct except for the zero.

Also notice that the list doesn't quite reach -1 on the 7th value so it steps one more time getting to -1.33334. I noticed that your example seems to go from 0.15 to -0.2 and now I'm wondering if there is an extra pass there too...

So within your CAM program the Y coordinates might actually be values like 0.0999983642323... etc which display with 5 digits of precision as 0.1 etc, except that the value that should be zero is also off by a bit and the exponential notation allows the number formatter to show the error.

Although forcing a fixed-point notation when formatting the number will hide the error in a simple case like this one, the error can accumulate in a program that crosses zero multiple times, and eventually the zero could come out a 0.0001 instead...
-Kevin Martin

-----Original Message-----
From: CAD_CAM_EDM_DRO@yahoogroups.com [mailto:CAD_CAM_EDM_DRO@yahoogroups.com] On Behalf Of Lurch

I figured it might be that, just like Excel does with very tiny numbers...but I can't understand why it would want to when it's set up to increment the one axis in moves of .050, and the not-quite- zero's are NOT evenly split between the two .050 increments on either side...

> >Here's an excerpt:
> >
> >line -3,0.15,3,0.15
> >line 3,0.1,-3,0.1
> >line -3,0.05,3,0.05
> >line 3,1.259e-006,-3,1.259e-006
> >line -3,-0.05,3,-0.05
> >line 3,-0.1,-3,-0.1
> >line -3,-0.15,3,-0.15
> >line 3,-0.2,-3,-0.2
> >
> >when it gets to the line with the "e-006" part, it indexes the
> >spindkle to the retract height, resets the x-axis to whatever

value

> >it would have been at the end of that cut, and carries on...with

the

> >x-axis now out of calibration by whatever amount is the difference
> >between where it was at when it happened and where it would have

been

> >at the end of the cut.