Re: Traveling Salesman Syndrome

Bob,

I used to see fairly inexpensive pen plotter optimization software
which aimed at solving the same problem encountered in milling. I
don't know if the software actually changed the original dxf file or
produced a temporary optimized hpgl file which was plotted
immediately. I suspect the latter. If so, maybe the hpgl could be
intercepted and converted to gcode.

interesting topic,

Doug

--- In CAD_CAM_EDM_DRO@y..., 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