I started working on adding a routine to webcontrol to perform gcode optimization. I stumbled upon a python implementation of travelling salesperson problem (TSP) that used genetic algorithm that I think will work with some adaptation since this isn’t precisely a TSP:
I made some modifications to it and I think it will work. But the real difficulty with gcode optimization turns out to be the parsing of the gcode and its re-assembly after the code is optimized. So I started this thread in hope knowledgeable people could provide some feedback and answer questions.
*Note:I’m putting aside optimizing gcode with tool changes, lasers, spindle control, relative positioning etc. until I can get gcode without any of them optimized.
In a CAM program, you typically set a traverse height that’s used for G0 moves. I can parse through gcode and determine what that value is and then use that to rebuild the G0 moves.
My first question: is there any reason to assume a gcode would have different traverse heights in G0 commands? That is, one G0 command uses 5 mm whereas another would use 7 mm? My thought is to just use the max Z value in a G0 command as the traverse height… this assumes that some silly CAM program would not just start off with a G0 Z25 but then use G0 Z5 when preparing to do a G0 XY? I wouldn’t want to use 25 for all the traverses when 5 is what the user wanted.
Right now I am breaking the gcode up into segments bracketed by G0/G00 commands… this leads to the following questions:
My second question: is there any reason to expect a CAM program to use a G0 Z command to move downward into a work piece? I would expect anything into a work piece to be a G1 Z command.
My third question: is there any reason to expect a CAM program to use a G0 Z command to move upward but not out completely out of a work piece? For example, during a move to cut a tab, might a gcode program use G0 Z+ to lift the bit to clear the tab? Since it’s not cutting material, maybe some CAM program might use max feed rate…
I wanted to add a huge thumbs up to this approach. I have a maslow system running development code, so I can help test alpha webcontrol versions to help. Anything that will help with optimization is desired. Having said that I’ll offer what limited perspective I have with the disclaimer that my experience is extremely limited.
I think no. There is no reason to assume gcode would have different traverse heights on the maslow. The reasoning is that with maslow we are working on a planar surface, not a contour and we have no reference z map so if a different height was needed, the sled effectively makes it a relative height if it clears it… if that makes sense.
G0 by definition (according to my friend google) is a fast move / traverse, not a cut, so I would echo that sentiment with a “No” it is not reasonable to expect a plunge with a G0 command. if anything it would only be a raise or lower to "travel height.
Echoing the sentiment of #2, if cutting like in a carve operation, this should be expected to be a G1, not a G0. In my “vast and varied” (air quotes for sarcastic effect) experience, I’ve only ever seen a tab cut as if it were a complete skip and the cutter goes to g0 travelling height, the next position is located, bit lowers and cutting resumes. If an intermediate cut is desired, then it should be a G1, not a G0.
My question regarding optimization: There are a few different approaches to cutting successive depths that I have seen
the entire shape at one depth, then the next depth…
groups of shapes at one depth, then the next, then the next, then the next group of shapes.
each line segment (or arc segment) at each depth, then the next segment until the entire shape is complete.
Depending on how you organize the gcode, in the optimization, you may need to/be forced to lock on a specific approach to be consistent. What does the TSP algorithm do with that and will that affect or be affected by the optimization algorithm of interest? I read something recently about an ant colony approach where you swap nodes until the overall path is shortest, but they didn’t offer code.
I wanted to add a huge thumbs up to this approach. I have a maslow system running development code, so I can help test alpha webcontrol versions to help. Anything that will help with optimization is desired. Having said that I’ll offer what limited perspective I have with the disclaimer that my experience is extremely limited.
I think no. There is no reason to assume gcode would have different traverse heights on the maslow. The reasoning is that with maslow we are working on a planar surface, not a contour and we have no reference z map so if a different height was needed, the sled effectively makes it a relative height if it clears it… if that makes sense.
nothing prevents it, but I wouldn’t expect CAM to use different hights, but
someone manually manipulating gcode could do so.
G0 by definition (according to my friend google) is a fast move / traverse, not a cut, so I would echo that sentiment with a “No” it is not reasonable to expect a plunge with a G0 command. if anything it would only be a raise or lower to "travel height.
I could see it if you are switching tools, rough out with one tool and then move
down close to that rapidly before going slowly and cutting
I’ve accidently done cuts with g0, the only difference between g0 and g1 is that
g0 is supposed to move at the max feed rate your machine supports while g1 goes
at the tate you specify.
Echoing the sentiment of #2, if cutting like in a carve operation, this
should be expected to be a G1, not a G0. In my “vast and varied” (air quotes
for sarcastic effect) experience, I’ve only ever seen a tab cut as if it were
a complete skip and the cutter goes to g0 travelling height, the next position
is located, bit lowers and cutting resumes. If an intermediate cut is
desired, then it should be a G1, not a G0.
agreed (with the emphisis on ‘should be’)
My question regarding optimization: There are a few different approaches to cutting successive depths that I have seen
the entire shape at one depth, then the next depth…
groups of shapes at one depth, then the next, then the next, then the next group of shapes.
each line segment (or arc segment) at each depth, then the next segment until the entire shape is complete.
Depending on how you organize the gcode, in the optimization, you may need
to/be forced to lock on a specific approach to be consistent. What does the
TSP algorithm do with that and will that affect or be affected by the
optimization algorithm of interest? I read something recently about an ant
colony approach where you swap nodes until the overall path is shortest, but
they didn’t offer code.
I think the thing to do is
minimize the G0 movement
minimize the Z movement
any G1 movement can be re-ordered, but not eliminated.
Don’t cam programs make the g-code according to the post-processor for the machine it will run on?
FreeCAD for example exports with LinuxCNC post-processor G0 for fast moves at clamping clearance height and safe height. Simple but does the job.
G1 G2 is for the cuts in material.
I might have got the question wrong, just wanted to say i missed you guys.
Estlcam is pretty darn spiffy… the author uses G0 Z moves from the traverse height to drop the bit to just above the worksurface and then issues the G1 command to penetrate rather than issuing a G1 command from the traverse height. To avoid eliminating that nicety, I now scan the file for the highest G0 Z move, use that as the traverse height and then treat all G0 Z moves that don’t reach that height as part of a path.
For example, here’s a snippet of an engraving of a line:
The optimizer treats lines 1-5 as header lines because they precede any move and they get added to the beginning of the optimized gcode. Scanning through the code, both lines 7 and 13 are Z-axis moves to 5mm (the greatest Z height) and therefore the program will use 5mm as the traverse height. The program right now will create just one “path” from this file with start and end coordinates of (0, 76) and (0, 0), respectively with a start index of 10 and end index of 12 (the G0 line below traverse and all the G1 lines). The G00 moves at traverse are dumped since they new ones get created after optimization.
I seldom do full height tabs… most of the time I opt for half height… but regardless, based upon the above, it will treat any G0 or G1 Z-move that isn’t at traverse height as part of a cutting path.
The primary goal is to reduce the total distance traveled by G0 moves. That’s basically all that can be optimized from what I can tell without doing CAM itself.
The method I use basically divides things up into groups of paths where the router bit is into the workpiece. So a multipass cut that drops 5 mm per pass is treated as one single path group and all the lines stay together. If your gcode does a single 100 mm circle, 5mm depth of cut per pass, to a depth of 25 mm, then there is nothing to optimize because its treated as one single path group (there wouldn’t be any G00 movements to optimize).
Now if the CAM program trying to generate two 100 mm circles produces code that does a 100 mm circle at 5 mm, moves over and does another 100 mm at 5 mm, then goes back and does the first circle at 10 mm, then the second circle at 10 mm, then back to the first at 15 mm… and so on, then the optimizer would optimize it and reorder it so it does the first circle then the second circle (if you follow). But, during each pass it would raise the Z axis to traverse height and then drop down again. I guess this could be a further optimization that might address @dlang’s comment regarding minimizing z-axis movement. But my concern is that drill operations raise and lower the bit to clear the hole… so I wouldn’t want to optimize that out. Lots to think about.
And my last post for the night. I switched algorithms and ditched the genetic thing as it produced really, really bad results and was very slow. It probably needed tweaking, but I found other code using google’s OR tools and it was rather easy to implement… its fast and produced good results. This is a snippet of the gcode for a field of stars (part of the one of my kid’s American flag project I did a couple years ago) as it came out of Makercam:
a drill operation would be a g1, not a g0 (IIRC, g2 and g3 are similar but
moving in arcs)
if you can re-order things to minimize the g0/g2 movement that is a fantastic
first step
but if movment up to the transverse height is g1, then you want to minimize
that.
a peck operation would be down/up/down/(up/down repeated)
a wasted move to the traverse height would be movement in any other
direction/up/down/movement in another direction
let the user set a flag to let you remove that so that if this is needed, they
can get the rest of the optimization, but by default look for this up/down and
eliminate it.
also, look for any G1 movement that’s above Z=0 and have an option that will
convert that to G0 movement.
define your blocks of movement as g-code that’s bounded by Z movement with no
x/y movement
In a later revision you can look at the entry point into a shape and direction
of cut type of thing, but a first pass that re-orders things to minimize G0 and
Z axis movement will give the biggest bang for the buck.
I haven’t really tested it beyond seeing if it looks optimized… I just got it working late last night. Unfortunately, groundcontrol/webcontrol doesn’t have a run time estimator, but I agree it would be a good thing as that’s really the metric of how optimized it is.
I think I can do this and just replicate what estlcam does (i.e., drop to just above worksurface using g0 and penetrate using g1).
I would be very curious how optimal the paths are that are generated by Kiri:Moto by default for these complex parts. There were recent code improvements for cases just like this. If you enable “depth first” under “output” in CNC mode, it should optimize for local cuts and moves.
Hey @madgrizzle that’s really awesome what you are doing!
I often wonders why the gcode is that overload with movements. Nice to see someone with knowhow working on it
If people could send me sample gcode files at madgrizzlemaslow at gmail dot com, I’d appreciate it. I need a good sample from various cam programs to test with. I’m particularly interested in ones with tool changes and spindle control.
project that i am looking forward to 