Toolpath efficiency problem

First off, I am pretty new to all of this. And I appreciate all the content and interactions on this site! It’s a pretty incredible community!
My issue is I am trying to figure out how to make the toolpaths more efficient for a project I would like to make. I am making basic shapes side by side, but I can’t figure out how to not run over the same toolpaths multiple times. Hopefully this makes sense.
I will attach a gcode that is doing what I am talking about, just on a simpler scale. I would appreciate any help I can get, Thanks!
efficiency (3.1 KB)

Hi @Bitz,

I think your question may be addressed in that recent thread about doing boolean ops to having going over shapes multiple times?

Or maybe I misunderstood what optimization you would like to see for your particular case:

Thank you for the quick response.
Maybe I didn’t explain well enough or my example wasn’t a good one. I am including another gcode that may better show the efficiency/ deficiency I am wondering about. The shapeoko cuts each hexagon before moving on to the next in this example. Therefore it cuts over areas that have already been cut. I’ve tried messing around with booleans but with no luck. I am just wondering if there is a more efficient way to design this or tool this.
Thanks again for all the|attachment (37.6 KB)

This is an NP-complete problem in computer science known as “The Traveling Salesman” — if you have a file where the pathing is esp. egregious please send it in to and we’ll try to have a developer look into it.

1 Like

Hey Will,
Thank you again for a quick response. I am still new at this and was wondering if I was overlooking an easy solution. It sounds like I am not, and it’s not terribly egregious, so I can live with it. Thanks again, you guys rock!


It’s sort of like that game where you have to make a one-line drawing of a house or something without lifting the pencil off of the paper, and without retracing a line.

I looked at your ‘efficiency example’ file in NC Viewer, and if I understand your question, I think the important counter-question is are you trying to pocket/v-carve or engrave? Most toolpaths need closed boundaries so they can properly calculate the gcode based on the dimensions they are bound by. So for instance, if you have those 4 rectangles sitting edge-to-edge and ask it to pocket each one to different depths, it would make sense that it needs to pass over the same edge lines multiple times because it is clearly 4 separate areas, even if they happen to touch.

Some toolpaths don’t necessarily need boundaries. For instance, a zero-offset profile/contour toolpath can simply ‘trace’ any line or vector path that you give it whether it is closed or not.

In your case, the same 4 small rectangles could also be defined by one large rectangle with 2 simple lines connecting at the midpoint of each edge (a rectangle with a cross in it). The software won’t see this as 4 separate areas–it will see it as one large area. In other words, if you need to pocket these 4 smaller rectangles, then you can’t select different depths, because the only enclosed boundary is the large rectangle.

However, if you just wanted to engrave or cut right along the outlines (as in your ‘efficiency example’ file), then this arrangement would work fine. You could make your zero-offset path for your large rectangle, and then make your zero-offset path for the 2 intersecting lines. This would accomplish what you were trying to do in that file, without ‘retracing’ the inner lines.

Hopefully this explanation was not too confusing.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.