I’m not sure if this was asked or somewhere in the forums, but here is my question: I am making a rather large workbench top, and I have a lot of keyholes. Some are just holes, and some are inlay groves for the track. My rapids track is all over the place. How can I or can I determine in what order the pocket holes are cut?
The only thing I can think of is to group in smaller numbers and go from there…
I have a Shapeoko 5 Pro, 4*4 and Carbide Create Pro.
The only control you have is the order of different toolpaths. So, your first thought is correct.
There are long-standing reports of how bad the rapid ordering is, there doesn’t appear to be any change om the horizon.
As has been noted in the past, this is known as “The Traveling Salesman Problem”, and is a thorny problem in mathematics/computer science, which simply phrased is:
Calculate the shortest possible toolpath which traverses a given set of points only visiting each point once.
It is one of a class of problems known to be NP.
For a discussion of these classes see:
For this specific problem see:
and for a further background, and an off-hand comment that a general solution which works on all possible examples and which can be proven to be correct would be worth $1 million see:
For the sake of the user experience, we have to choose an algorithm which runs quickly enough that folks won’t tire of waiting for it — the tradeoff is that that results in an algorithm which has this result when running on the machine — which one has to wait for anyway.
Run the simulation in slow or step mode to see the starting point and order of regions.
When I look at that image I think it’s not too bad. Each region of holes is cut mostly sequentially. You will always have the rapids between the regions. The top region jumps around a little bit. The obvious, quickest path would be to cut each row then the next row in the opposite direction, which happens in all the other regions.
You could program each region separately to control their order. But I’m betting you would not get much improvement. (maybe 1-2 minutes). If you want to share the .c2d file we could do the experiment.
It is always nice to make efficiency a priority. However if this is a one of project why even try. If you were going to make these for a production run then spending some time to try and make the cutting more efficient would be worth your time and effort. By making only one just get yourself a cup of coffee and watch the show. Nothing wrong with trying to improve but at some point it is pointless. So unless you are going into the bench top production enjoy the ride and find something to keep you occupied in the shop for a few more minutes. Be sure to post a finished picture of your finished benchtop.
Be gentle this is still in the plainnng phase but 90% complete. the thickness of material or the depth of the pocket holes are not set yet.
bench top 3.c2d (572 KB)
Will do, I should have something next week.
One of the reasons I like Vectric is it has a “Vector Selection Order.”
Here is a field of Stars using Vector Selection Order.
Here is the same toolpath without Vector Selection Order:
Let’s see if I can rearrange the Vector Selection Order better:
Nope, it looks like my math isn’t MATHING as good as the folks at Vectric. Lol.
One more try. This saved 3 seconds!!!
The GCodeClean G-code postprocessing utility will split gcode into blocks based on travel moves, and then recombine them in a different order using a TSP algorithm, and on my aging i5-5200u laptop does that rather fast.
I hit enter before finishing, hoped that you wouldn’t read it that fast 
The readme seems to be rather vague about this, but there’s a discussion in the Maslow CNC forum where Lee provides a better explanation. I’ve used it on older versions of Carbide Create gcode, along with other CAM software including Vectric’s. Admittedly it’s UI is a bit crude, with an improved version planned.
The old Eggbot program from Evil Mad Scientist, stipplegen2, also implements a TSP algorithm that is also rather speedy. I’ve been playing with that a bit since getting a pen holder attachment, along with using it on an EMSL eggbot during egg decorating time in the past.
It doesn’t do that in an interactive context where the user is trying to use a graphical application as the calculation runs.
No, it’s a post generation G-code file improver. Perhaps I’m wrong but that doesn’t seem like that (interactive graphics context, not the actual TSP implementation) is too big an issue with a specific toolpath generation, although it could be difficult across multiple toolpaths.
I’ve been looking for improved toolpath ordering for a long time, but so far haven’t found much other than GCC that actually worked. In the case of Vectric software there’s at least one YouTube video on manually optimizing toolpath order
