Inventables Community Forum

Traveling Salesman Optimization

I’d like to see better optimization of of how the tool moves around on the workpiece and the order in which shapes are cut. I’ve noticed a lot of wasted time with G0 moves when it could just complete an entire area before moving. Here is an example:

When the textured areas are being carved, it is constantly moving back and forth between the two areas wasting a huge amount of time.

There is a proof of concept here: https://xyzbots.com:4000/gcode-optimizer/ for addressing the traveling salesman problem. It works by optimizing the distance between G0 moves. It results in an optimized tool path like so:

Animation_3

NOTE: DON"T USE THIS IN PRODUCTION! Using this as is will screw up the order of how your project is carved. Instead of doing it depth by depth it will sometimes do the full plunge.

So I understand that inventables can’t just use the algorithm as is. But at least certain parts of the carve could be grouped together and then optimized.

2 Likes

Yes, “tool not in work” time is way too high with the current Easel algorithm.
Even something as simple as a quote of text has the tool traveling up and down the lines and “jumping over” letters too much.
Also cutting a line only in 1 direction, rising, and returning back to start it again. There needs to be an option to “cut on return path”.

Another example of horribly not optimized.

The first operation is drilling the nose dots and then it traverses back to near 0,0 and starts those cuts.
They are “deep” and so the tool stays in the area but only cuts in one direction.
Once the first set of deep cuts is done, it moves up to the patch of “shallow” single pass lines between y=2 and 4. Again only cutting in one direction and haphazard order. The frustrating thing about the one direction thing is that the set of lines near the center the tool path is in the opposite direction (right to left) than the other ones (left to right) nearby.

I’d like to know what the Easel order of operations / algorithm hierarchy is. There is tremendous room for improvement.

As I plan to be cutting this piece a lot, I’m probably going to edit the order myself. It will be time consuming, but it will be less than spending several minutes each carve watching my x-carve appear to be “lost” or of “really short attention span”.

1 Like

I am very curious what their algorithm is for determining the order of operations, there seems to be no rhyme or reason to it. That’s been the most frustrating part of watching the carve. I find myself shouting at my machine saying, “Why would you go over there!? Just finish this part first. Well don’t do it now! Sigh…”

There are 3rd party tools for optimizing G-Code — see the list at: https://wiki.shapeoko.com/index.php/G-Code_Utilities

3 Likes

I might be completely wrong but I think it won’t do a cut on return path as the cutting side of the bit is only on one side.
You’ll know what I mean if you’ve ever used a router by hand, it’ll cut smooth one way but it won’t like it going the other, it’ll cut it but it’ll be jumpy or create some burn.
It’s easier to picture on a v bit.
(Again, I might be wrong)
I also agree about its attention span, going off and doing something else before it has finished its first task, is annoying.

The cuts I am irritated by are single pass cuts. They are only the width of the bit. It is a climb cut no matter which way it traverses.

Yes, there are times that direction matters, but for times that it doesn’t I want the cutting time to be expedited. Tool in material for as much of the process as possible. The point of doing some things with a machine is efficiency. The Easel g-code generating algorithm is highly inefficient at times. There are ways to improve it. It has been done by others. Some of it is open source. Implement it is all I am asking.

Reviving this thread to say that we worked hard on this issue. Join us for our Easel Live Event on 5/3 at 1PM CST (links in the header banner) to learn more. Thanks for your input here!

1 Like