Re: found a problem... Supertech mill

No, no metric/imperial conversion or anything like that. It's
milling a square pocket laid out by drawing the 4 border lines
manually then using the FILL command.

I grabbed the same file and ran it in the demo version of SuperCAM Xp
and it didn't re-zero any axis halfway through a move...which leads
me to think very strongly the issue is either in the version of
SuperCAM I have, or in the controller itself. And it's been doing
this from day one.

Dennis DID offer me the newest version of SuperCAM for DOS for
another $95.

Lurch

--- In CAD_CAM_EDM_DRO@yahoogroups.com, "Tony Smith" <ajsmith@...>
wrote:

>
> You'd think it would work...
>
> It's not trying to convert metric to imperial is it? Metric CAD

with

> Imperial screws on the mill? The small number is from some sort of

rounding

> error?
>
> A bit wierd that it doesn't understand it's own file. You could

change all

> of the numbers to scientific notation, eg
>
> line -3,0.15,3,0.15
> line 3,0.1,-3,0.1
> becomes
> line -3.0e-000,1.5e-001,3.0e-000,1.5e-001
> line 3.0e-001,1.0e-001,-3.0e-001,1.0e-001
>
> In theory, a program that understands scientific notation should

treat the

> two chunks as the same.
>
> If that works, then it's probably the tiny number causing grief.

That's a

> bit hard to fix. You could load it into Excel and use the ROUND()

function,

> it specifies how many digits after the decimal, so =ROUND(1.259e-

006,4)

> returns 0 (actually =ROUND(0.00000126,4)). =ROUND(0.00000126,6)

gives you

> 0.000001
>
> Still a pain.
>
> Tony
>
>
> > What vexes me, is that it was the SuperCAM software that
> > generated this CAM file...and at Dennis Bohlke's suggestion
> > it is running under DOS 6.21 with no other files on the hard
> > drive...maybe the scientific notation ISN'T the reason it
> > spontaneously aborts the cut, and etc.
> >
> > --- In CAD_CAM_EDM_DRO@yahoogroups.com, "Tony Smith" <ajsmith@>
> > wrote:
> > >
> > > Excel can clean that up for you. Save it with an extension of

CSV

> > (comma
> > > separated values), and open with Excel.
> > >
> > > It'll pick up the 1.259e-006 as a number, but set its format to
> > scientific.
> > > It'll still look the same, but when you click on it you'll see

it's

> > really
> > > stored as 0.00000126. Highlight the columns, and do
> > 'Format, Cells,
> > > General'. This will clear the scientific formatting.
> > >
> > > If the column isn't wide enough to fit the number in, Excel will
> > display it
> > > in sci notation, '1E-06' or even just '0' if the column is

really

> > skinny.
> > > Just make it wider, Excel handles 10 decimal places like this,

or

> > you can
> > > fiddle with the formatting to get 30 decimals places. Is your

mill

> > that
> > > accurate? :)
> > >
> > > Click 'Save', hit 'Yes' if it complains about saving in a

different

> > format
> > > (csv / xls), and you're done. Now if you look at the file,

it'll

> > have
> > > 'fixed' the numbers.
> > >
> > > Tip, when you click 'Format, Column, Width', the number it asks

you

> > for is
> > > for how many characters do you want to display. '0.00000126'

has

> > 10, so
> > > entering that will set the column to the precise size.
> > >
> > > Tony
> > >
> > >
> > > > I ran into a similar problem with some engraving code
> > (which has 5
> > > > decimal place numbers) which was then run through a java

program

> > > > that flips it around. The java program insisted on
> > rewriting it in
> > > > exponential notation.
> > > > EMC2 wouldn't run the program, so I just did a global change.
> > > > It was only one letter that had a problem, so there were
> > only about
> > > > 5 instances.
> > > >
> > > > On 8/25/07, Stephen Wille Padnos <spadnos@> wrote:
> > > > >
> > > > > Lurch wrote:
> > > > >
> > > > > >still fighting with my supertech mill. the .CAM file it
> > > > creates, has
> > > > > >some odd code in it...I understand every line of the file
> > > > except one.
> > > > > >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.
> > > > > >
> > > > > >I don't even know what "e-006" IS...but at least now I know
> > what's
> > > > > >happening. I'm going to manually edit the file to remove

those

> > > > > >glitches and do a 'dry run' with no tool and see whre it
> > finishes
> > > > > >up...
> > > > > >
> > > > > >
> > > > > It's printing out very small nubers as exponential. 1e-06
> > > > is 10 ^ -6,
> > > > > or 0.000001. 1.259e-06 is 0.000001259 Why it's doing that,
> > > > I have no
> > > > > idea :)
> > > > >
> > > > > >Lurch
> > > > > >
> > > > > >
> > > > > - Steve
> >
>