Re: found a problem... Supertech mill

Actually it is entirely possible there's nothing wrong with the
program itself. This morning Dennis sent me a copy of V3.7K, which
he says he thinks uses the 2nd timer on the motherboard exclusively,
rather than only occasionally.

So I install 3.7K and it keeps repeating "Initializing timer 2" over
and over...only way out is to reboot.

Here's Dennis' take on that:
[quote]
3.6Z did not use it excusively.
3.7K I think does use it exclusively.
[unquote]

In another email he states
[quote]
That means the timer counter #2 on your motherboard is not
responding, not working. That is the hardware timer that is used as
the time referrence for generating Step frequencies. SuperCam is
sensing that it is not counting and is trying to reinitialize it.
But it doesn't start so it try's again. And so it goes in a deadly
embrace.
[unquote]

Too bad it took til v3.7K to make it show up consistently. Right now
it's running a 7200-plus-line CAM file with no tool in the spindle,
on a computer pirated from another use, just to see what happens. If
the axes are all still accurate [within known backlash values]
tomorrow morning, I'll consider the issue resolved, and be in the
market for a replacement motherboard for the mill computer.

On the other hand if it still screws up I guess I'll make use of the
xml file for Mach3 Dennis provided.

Lurch

--- In CAD_CAM_EDM_DRO@yahoogroups.com, Kevin Martin <kpmartin@...>
wrote:

>
> 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.
>