I cut four lantern faces spread across a 12x48 piece of pine. The faces were all one toolpath: a cutout normal with a -.020 breakthrough. The time shown in Motion was 39 minutes.
I noticed that a lot of time was spent moving from one side of the material to another. It might cut one eyebrow on the right and move all the way across the board to cut a feature on the left. Rarely did it cut two features adjacent to one another.
So I guess there is no attempt to optimize movement around the workpiece.
I’m thinking grouping each face individually and assigning each its own toolpath might work to save time. I’ll try that the next time I have a similar project.
Even with modern computers if one could come up with an algorithm which could always solve arbitrary inputs for the most efficient in terms of time toolpaths, it would probably take longer to calculate than the toolpath would take to run, making using a CAM tool using it a tedious batch operation (set up toolpath calculation, allow to run overnight, get the perfectly optimized toolpath ordering after hours of the computer working).
An algorithm which could solve such problems efficiently would probably be worth a Fields Medal, or possibly even the Millenium Prize for P vs. NP…
My experience is to cut each tool path (Lantern face) separately, your thought process is correct. You can also check your retract height as this will increase the total cut time if the value is larger than needed to clear obstacles on the CNC bed.
How are the start points on each vector determined?
It seems random, arbitrary, and not associative to the order algorithm. (TSP solution)
The problem is exacerbated in V-carve which seems to complete the V-bit path in 3-4 separate steps/phases (pick out some small spots?, cut around the vectors, clear areas too small for the clearing tool, pick out corners), rather than lumping them all together.
As of now, I think sorting your geometry into groups & machining them separately is the answer.
I spent a good part of my pre-retirement career on performance optimization on a variety of hardware and software products, and even after retiring I couldn’t forget about it and move on. I have noticed that no matter how much you talk to your CNC router including cajoling, threats, and yelling, it just won’t automatically make poor tool paths work any better. I’m hesitant to call it stupid gcode but you get the idea.
GCodeClean on github, an outgrowth of the Maslow CNC project, will postprocess gcode using the traveling salesman algorithm as one of many features. I used it a fair amount on older Carbide Create gcode with good results along with other CAM software. The UI needs work, it’s all command line with multiple passes to preprocess, split into code blocks defined by Z moves, then reorder and recombine back into a single gcode file but after a few issues with the early beta versions it never failed on me. The developer was quick to respond to questions and issues and is still active in the Maslow forums afaik. Most of my projects in the last few years have been long design times/short run times, and I’ve drifted away since saving a bit of run time didn’t help much.
Even without the optional TSP processing it will help out issues with Z up and down movements, it’s pretty good at recognizing redundant Z lift/plunges in the same location and intelligently removing them along with turning feed rate retracts and plunges into rapid moves. In the case of plunges (other than the Z only up/downs) it will G0 to a low height out of the workpiece, then continue with a G1 (it won’t keep track of already cut areas and plunge through the intervening air ) at the original feed rate. It will also recognize curves made up of short line segments (a particular issue for the original Maslow with its computationally intensive hanging chain kinematics) and convert those into G2/G3 arcs. All processing is configurable and most with tolerances, and can be turned on/off as desired.
I can’t guarantee that it will help out the OP, but it’s worth considering. It will make a big difference in optimized ping-pong travel moves jobs.
FWIW there are a number of YT videos about manual optimization of vector files for the big V CAD/CAM company in the UK, with techniques that can also apply to Carbide Create and other software. A number of those techniques involve improving changing vector order, switching vector directions, moving the common start/end point of closed paths, and similar stuff and can apply to CC. There’s probably similar information for other software but I’m not Will and can’t keep up with everything these days
I don’t have an answer but perhaps tiny bit of insight that I hope isn’t off topic. There’s an old post on vectric forums in response to this question regarding Nesting toolpaths. A user with a specialized experience explained these calculations are so computation heavy they use 3rd party library code only a few vendors in the world make.
So, I don’t know how Create is written. But I think its true these are very complicated calculations. Like that xkcd cartoon. At some point all CAM software has to make a choice of how much time is worth investing to save time. Maybe as these softwares advance we’ll see settings to optimize for single run or repeated runs. Who know maybe, gulp, AI could someday solve this if its not too busy with the funny photos and planning how to reunite with Neuromancer.
If all of your cutouts are the same repeated I draw up the first elements and do the tool paths. Then I copy and paste the additional objects. That seems to work as far as doing one element at a time instead of jumping around. I have not made a study of this but it seems to work. Plus if you do tool paths for the additional elements you have the opportunity to screw up subsequent tool paths. I have the Pro version and on pockets there seems to be something in my keyboard that will change from offset to raster on multiple occassions.
The delta between CC tool path times an CM goes all the way back to v3. Tool paths are estimates but there are additional time to change bit and so on. The time to change a bit varies from user to user and project to project.
What you described as moving around @WillAdams has called in the past the traveling salesman in executing tool paths in random order. That is a combination of OS and the CC/CM programs. It is found in a lot of computer code other than CC/CM.
Since you didn’t upload a file to look at, I can only give background info. We’ve had bugs that reduced efficiency, and we’ve received files from customers that gave us additional test cases to review. I’m sure there are more bugs and inefficiencies in our code because it’s a pretty large program at this point. So, with that caveat…
There’s a great deal of effort spent to find a good path between segments of a toolpath. For anything non-trivial, the absolute best cannot be found, because there are too many options to check. But we do millions of calculations to find a reasonable output.
That reasonable output may look non-optimal, and we get a lot of emails along the lines of, “I think it would be faster to cut each part of a little before moving on to the next,” but that’s almost never true.
In the past, we’ve added code to pick a slightly less optimal option in some cases, and that reduced complaints, even though the toolpaths were objectively less optimal.
I recently had a project with a bunch of wavy jaggy lines for texture. Some ran the full width of the project at 24” and others were short segments between raised foreground material.
I use Vectric for the design and CAM and noticed that the paths were all over the place. In Vectric you can change the start point of each vector. I went through and altered the start points so that the machine would begin the next line at the same side of the project that it completed the prior line and kept the direction consistent across all short segments for a given line.
It was a laborious process and in the end maybe saved 5-10 minutes on a toolpath that was around an hour.
So the rapids from one spot to another weren’t killing me.
If it was a production setup with many to do or a 4x4 project then it may have been worth the time invested in tweaking those start points but in my case I am sure I spent closer to 30 to save 10 at best.
Now, if I could have found a push button way to do it in the software that would have been handy.
having built a few optimizers that take carbide create gcode… CC is actually very very good and gets the “NP complete” side amazingly right.
There are things where it maybe could do better (example, when cutting a “V pocket” for an inlay that has multiple letters, and for the V bit your max depth of cut is less than the total depth, CC cuts one depth for all letters, and then does the next depth level etc … rather than just finishing one letter at a time)…
if this is a real issue I could dust of the optimizers and see if It could be used to show users that indeed the path is very good
) at the original feed rate. It will also recognize curves made up of short line segments (a particular issue for the original Maslow with its computationally intensive hanging chain kinematics) and convert those into G2/G3 arcs. All processing is configurable and most with tolerances, and can be turned on/off as desired.