Re: Traveling Salesman Syndrome

Hi Alan,
Eagle has a ULP file that exports the pads and
traces as a DXF. The problem is the size is off! I was hoping
to be able to trace over the DXF in TURBOCAD. Thought I had
it! I just love these so called DXF files. They are as funny
as the words WINDOWS compatible.

Bob

--- In CAD_CAM_EDM_DRO@y..., Alan Marconett KM6VV <KM6VV@a...> wrote:
> Hi Bob, Jon,
>
> PLT format? I have found that ViewCompanion v2.0 is inexpensive
and can
> convert .PLT files to DXF or a host of other formats. From there,
you
> could import into Vector CAD/CAM; reorganize, and generate the
Gcode.
> OR the CAD-only could save DXF, and let Yeager's ACE generate the
> Gcode. The Harley file is a good file to experiment on (who can
read
> DXF's), as I have found out.
>
> I haven't designed any boards in Eagle (yet), but I have exported
the
> hexapod and other demos for experimentation/edification.
>
> http://www.softwarecompanions.com/ (ViewCompanion)
>
> I'll experiment with the .PLT file output!
>
> Jon had some good comments on the T.S. problem. Seems to me, that
as
> the "traces" are "closed" tool paths, when you cut them, you come
back
> to the same point. So like Jon said, we're only needing to sort the
> rapids, I.E., the starting points of the traces, as I see it. How
about
> a "flood fill" to keep the rapids in-between trace starts to a
minimum?
> Start at origin, find the first point from that within a specified
> radius, cut it, find the remainder of start points, then expand the
> radius, etc. Or maybe the center of the radius needs to be moved
to the
> point just done? (that's not really a flood).
>
> Alan KM6VV
>
>
> cncdxf@a... wrote:
> >
> > Hi,
> > The Traveling Salesman Syndrome (TSS) can be advoided
> > by planing ones GCode from the beginning. Since we know
> > a DXF drawing will convert into GCode the same way it
> > is was drawn, is the first step.
> > I mentioned the HARLEY file because it was avalable
> > as a DXF to everyone in the group. Having a drawing to
> > refer to as an example has really helped. The HARLEY file
> > can be easily and cheaply fixed. Pull it into a Cad or
> > Corel program. Trace it as an other LEVEL and save that DXF.
> > I suggest tracing the cuts in a circular pattern. Redraw the
> > outer cuts moving inwards. You could also cut from right
> > to left.
> > I mill circuit boards for local Engineers and
> > students. My machine is very slow. After laying out
> > a large circuit board using Eagle, I was shocked to see
> > the Traveling Salesman Syndrome strike big time. The
> > last few days I have been playing with saving the Eagle
> > layout outline in PLT format. Then I convert the PLT
> > to DXF. I then retrace the PLT file with a different layer
> > in Turbocad. I save the new layer as the new DXF. When it
> > is converted to GCode, it purrs.
> > What bugs me at this point is how Corel makes some
> > of the lines in a DXF fatter. I feel spending more money
> > for yet an other program to fix TSS is uncalled for!
> > Like I said before, I brought up this subject because
> > I thought I was doing something wrong. I say what good is
> > a fast machine if you are running a slow GCode. Please
> > keep thread title as Traveling Salesman Syndrome, this will
> > help future travelers when the search the archives.
> >
> > Bob
> >
> >
> >
> >
> > --- In CAD_CAM_EDM_DRO@y..., Jon Elson <elson@p...> wrote:
> > > rab@r... wrote:
> > >
> > > > Don't suppose anyone can recommend a good algorithm for
solving
> > the
> > > > Traveling Salesman problem ?
> > >
> > > There may not be any. Now, for machining, things are different,
> > because
> > > any cutting motion is good. What you try to minimize is the
non-
> > cutting
> > > movements. This makes the problem much easier. Also, the case
> > where
> > > there are hundreds or thousands of cutting movements, usually
with
> > exactly
> > > one non-cutting movement between them, is a lot simpler problem.
> > > You throw away all non-cutting movements, just keeping the
cutting
> > > movement strings as they were. Now, you pick one at random, do
it,
> > > mark it done and then search the endpoints of all other strings
to
> > see
> > > which one is closest. When there are no more uncompleted
movements
> > > left, you're done. this is a very simple scheme, but it usually
> > reduces
> > > badly
> > > planned toolpaths by up to 90% (Those would have to be REALLY
bad,
> > > but I've seen them.) Depending on how the toolpath is written,
> > detecting
> > > cutting from non-cutting movements may or may not be easy.
> > >
> > > Jon