Re: found a problem... Supertech mill

The file was created entirely within SuperCAM itself.

And the files creatred within AutoCAD, the failure pattern is not
consistent.

In either case, that doesn't explain why, when stepping x from 3 to -
3 during a cut, halfway through the cut it will lift the spindle, re-
zero an axis, lower the spindle, and keep going...and run the tool
into the tabletop, or a hold-down clamp, or whatever.

Whatever program was used to create the source file, there is NO set
of circumstances under which I can see it stopping to re-zero an axis
halfway through a cut **without** any input from the operator.

Since it has happened on a couple different computers, it has to be
either the software or the controller itself, is my thinking.

And repeated re-runs with no tool in the spindle, I am unable to
consistently replicate the failure. But I'll bet a dollar next time
there's a tool and a workpiece, it will do it again.

It comes and goes at will, and has existed across multiple computers
in multiple physical environments.

--- In CAD_CAM_EDM_DRO@yahoogroups.com, "R Wink" <rwwink@...> wrote:
>
> If you're using AutoCAD, download and run the "LISP" routing called
flatten
> (HYPERLINK
> "http://www.markcad.com/download/Flatten.lsp"www.markcad.com/downloa
d/Flatte
> n.lsp or several other places on the web-search Google
for "flatten.lsp").
> ACAD sometimes does not draw on a single plane and you might have
one of the
> endpoints of the lines of the "box" you drew somewhere other than
on the
> plane of the drawing.
>
> Running that through a drawing converter that can utilize 3D
points, it may
> be picking the point up and outputting a 3 dimensional coordinate.
>
> R. Wink
>
> _____
>
> From: CAD_CAM_EDM_DRO@yahoogroups.com
> [mailto:CAD_CAM_EDM_DRO@yahoogroups.com] On Behalf Of Lurch
> Sent: Sunday, August 26, 2007 8:41 AM
> To: CAD_CAM_EDM_DRO@yahoogroups.com
> Subject: [CAD_CAM_EDM_DRO] 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 HYPERLINK
> "mailto:CAD_CAM_EDM_DRO%40yahoogroups.com"CAD_CAM_EDM_-DRO@...,
> "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 HYPERLINK
> "mailto:CAD_CAM_EDM_DRO%40yahoogroups.com"CAD_CAM_EDM_-DRO@...,
> "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
> > >
> >
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.484 / Virus Database: 269.12.8/973 - Release Date:
08/25/2007
> 5:00 PM
>
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.484 / Virus Database: 269.12.8/973 - Release Date:
08/25/2007
> 5:00 PM
>
>
>
> [Non-text portions of this message have been removed]
>