Part of my workflow involves cutting out batches of shapes with both drilling and engraving. There seems to be no rhyme or reason to some of the generated tooth paths. For contours it start generating the toolpaths from top-to-bottom on the stock, so if I want to control the order of shapes to be cut out, I simply move one shape slightly lower on the design. Drilling and engraving don’t seem to do that. They have chaotic rapids after. Due to the sheer number of drilling and engravings I have on a sheet, any small inefficiency in the rapids between the toolpaths adds a lot of time to the cut.
Previously I had to create groups of paths and assign their own unique toolpath group to maintain efficiency and reduce the number of long rapids all around the material, which means any small change in design or toolpath settings requires me to change A LOT of toolpath groups and even more time spent wanting to rip my hair out.
I’ve tried grouping paths together but that doesn’t seem to force the toolpath generation to complete a grouped path over any others.
In this file you can see the Contours have a very logical and efficient order of cuts - because I aligned them accordingly. The drilling and engraving…leave much to be desired. In this example, the tips of the rockets (3 drills) are last to be drilled for some reason, which causes a long path of rapids when it finally catches up.
Is there any hope? I am not open to adding a 3rd party toolpath optimization at this time, though I’ve seen that suggested on here before.
There are (were?) 3rd party G-code tools which would analyze a G-code file and re-structure it for efficiency.
The machine isn’t that slow when moving in-between toolpaths at Rapid, and the decrease in cut time is hard to make up given the effort involved (write out G-code, load it into 3rd party tool, process it, check new file in 3rd party G-code previewer to verify, and only then run).
EDIT: To expand upon the above, this is a very hard problem in computer science colloquially known as “The Traveling Salesman” — even with modern computers it is quite difficult to have an algorithm which both arrives at a solution quickly and which calculates an optimal path for every possible example.
Although TSP is a hard problem, in our world we don’t need an optimal solution. There are many different heuristics that will give very good results most of the time, which I think would be a vast improvement over what is happening now.
It seems that every time this problem is discussed, the TSP is trotted out as a justification for the poor behaviour in CC. Really,how hard TSP is is just irrelevant, because nobody is asking for optimal soultions - people want better solutions, and it’s obvious from how CC creates paths right now that even heuristics as simple as the Greedy Algorithm would likely produce better results.
It seems more likely to me that the real problem is that the code structure of CC makes it difficult to gather then reorder the cut paths before outputting the GCode. We see this problem already in the “Pockets cut depth first” bug that keeps popping up. So the reason we don’t get a fix is not that the problem is hard, it’s that the implementation is hard. And that’s a valid reason, but if that’s the case say that, instead of claiming that the problem itself is too difficult to solve.
In my last project one of the passes required over 4000 lines to be engraved. I had some issues with consistency which made CC’s implementation of traveling salesman suspect. So I spent three days writing a program to reorder the sequence from bottom to top, not too onerous since the lines were all parallel to the X-axis. This appeared quite a bit more efficient to look at it but it only reduced the machine time by about 10 -15 percent. So it may not be worth worrying about too much.
It is a curiosity how much more efficient the profile milling of your rocket ships is compared to the engraving process.
A simple solution is having an option to cut grouped paths together as a “single” toolpath vs many. That way you can essentially have a manual override of any algorithm. Instead of needing to optimize 1000 small paths, you could cut it down to 20 if my paths are in groups of 50, for example.
It also has the benefit (and what I mainly wanted it for) of completing sections of the cut in-full so if anything goes wrong - and it most certainly does - I can quickly remove those “complete” groups from the revised design when I have to restart the cut so I can begin the cut where it left off.
Correct, it’s not the case. In my case I grouped all the drilling paths together and all the engraving paths together. And then I duplicate the entire complete shape. So each rocket is grouped and then duplicated.
I did a test a while back, and it looks to have similar results with the latest version.
A 10x10 array of circles with different toolpaths. Drilling & Contour seemed to have an optimum path with this simple of an arrangement. Cutting a row, then the next row in the opposite direction.
Where pocket, engrave & texture all followed a slightly more random, but OK path.
Of course it gets more complicated as the geometry does. Don’t even get me started on V-carve…!!! It’s all over the place. But part of this is the 3-4 separate operations within a V-carve path (shallow picks, carving between the lines, picking out corners, rest milling areas the clearing tool wouldn’t reach…) , and each operation following really random looking paths.
The only way I have ever found to get V-carve to machine the way I want it to is by creating separate toolpaths for each object. Whatever algorithm is in the program I find is entirely too random for the most part - seems to lack over-riding strategy or checks to ensure efficient toolpath generation.
I hope one day that C3D will be able to delve into that code & make it more ‘intelligent’ or customizable. But I’m sure making changes to that code is a risky endeavor as it could easily result in random/unforeseen problems once released to the user-base.
I’d really like to see a toggle that turns off the corner picking, or allows a maximum angle. i.e. if the corner is over 135°, don’t bother picking it out.
A lot of cases, lettering for example, waste a lot of time picking out corners that don’t need it.
I may want the square ends of a letter picked out, but non-smooth nodes in the middle of a curve I could just accept the radius of the cutter. and in some cases I’d be OK with just round ends, so no picking needed at all. In that case I’d set the max angle to 0° or 1°, and just let the vee bit cut.
I’ve been looking for gcode optimization tools for years and currently use the FOS GCodeClean, a utility that does a number of gcode optimizations. The latest versions break gcode into blocks separated by travel moves, and do a TSP optimization rearranging those blocks. The UI is somewhat rough, it’s all command line and the path optimization requires running several commands currently, but in my tests it works. I’ve had to take a CNC break due to medical issues and haven’t tried the latest version, but the earlier ones worked with Carbide Create V6 and other CAM gcode with no issues. I pull it out for “What the heck is it doing that for” gcode. It will also optimize plunge/retract moves, using G0 for retracts and for plunging to just above the workpiece surface, and maybe cutting surface but check the docs along with straight line to arc conversions, all can be turned on or off as desired. As always I’d recommend testing it first before launching into a mega (local currency units) project. I’ve tried it on my recent chip carving projects, while it worked great those cut so fast (especially compared to the often full day design effort) that I haven’t been bothering.
The developer frequents the Maslow CNC forum, hopefully that link is allowed, and is very responsive to any questions or problem reports
One thing that I found to reduce v-carve times by a LOT is the safe/retract height and plunge rate. On really detailed v-carves, the tool is going up and down as much as sideways. I did a 32" Star Wars Aztec Dial. It was 6 hours of carving at my first settings. Reducing the safe/retract and increasing plunge rate cut the carve time in half. After I got my S5Pro and could really put the hurt on plunge rate, I was able to do the same project but 48" (almost double the surface area) in only an extra hour.
Typically safe/retract set pretty high as default because it is safer for the tool not running into clamps. I set it to the minimum I need to clear any top clamps, or 0.032" if I have side clamps and the material isn’t really warp-y.
Also, plunge rate is usually set pretty low, again for safety. Keep increasing plunge rate until it gets really protests.