Traveling Salesman Syndrome

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