1. ## G Code optimising

JayC ,

I need Your help with the G code optimising software.

I think the optimising algorithm may be a bit dicky.

Does the algorithm work out distance between coordinated motion start points or is does it work out distance with a bias in a particular direction?

When I say distance between start points i men true radial distance ( square root of ( sum of xdistance ^2 + sum of ydistance^2).

I have tried to use the optimiser on a well sorted file and the optimisation is apparently not working the best on this data set.

2. And ofcourse the data set

If the algorithm looks for head to head distances then the optimisation will be inferior in some cases ( general case)

In case of G code generated by Eagle ULP ( JJ's Eagle to G code) then the optimiser will perform adequately since in this case the isolation paths are invariably closed loops where start and finish of isolation pass coincide.

In case of large area rubout optimiser will perform less than adequately because optimisation has to be a head of next to tail of previous optimisation.

4. a traveling salesman problem solver would be a good addition to opencamlib:

there is a simple TSP solver in the boost-graph library, there should even be example code available online - that is where I would start:
http://live.boost.org/doc/libs/1_38_...sp_approx.html

5. Andy,

thanks for the links; interesting work.

The optimiser i refered to is a G code parser which notionally rearanges elements of the g code file to cut down on high speed treverse time.

It is a simple sequential next nearest start point algorithm which does an amazing job considering its simplicity.

The order of complexity approaches O(n^2) but is well wort the effort.

6. Originally Posted by Zig
JayC ,

I need Your help with the G code optimising software.

I think the optimising algorithm may be a bit dicky.

Does the algorithm work out distance between coordinated motion start points or is does it work out distance with a bias in a particular direction?
It looks for the Z up and Z down moves. Those are the path delimiters no matter the number of actual X,Y coordinates between them. After reading in all of the paths and storing them in a vector:
1. The system retains the original positions of the first and last paths
2. Starting the the first path, it finds the nearest neighbor as you describe below and moves it from the vector to the output file
3. Repeat until the vector is empty

What this all does it cut down on the unecessary air moves. JJ's code outputs the polylines as Eagle outputs them. This optimizer doesn't even dig into those paths or their order. However, GOpt (Gsuite: free gcode tools) does ... have you tried it?
When I say distance between start points i men true radial distance ( square root of ( sum of xdistance ^2 + sum of ydistance^2).

I have tried to use the optimiser on a well sorted file and the optimisation is apparently not working the best on this data set.

7. Originally Posted by Zig
The optimiser i refered to is a G code parser which notionally rearanges elements of the g code file to cut down on high speed treverse time.

It is a simple sequential next nearest start point algorithm which does an amazing job considering its simplicity.

The order of complexity approaches O(n^2) but is well wort the effort.
Oh, and the original code was posted on the old Yahoo group site by an aussie by the name of Daniel Purvis. I took that code, cleaned it up, added some error checking, code comments, and a GUI. The code is freely available on the pcbgcode.org site.