Inefficient toolpaths with lots of shapes

I’ve done a ton of little projects, but started recently getting more detailed. I’ve noticed that the toolpaths can be quite inefficient. Instead of cutting one pocket at a time, it cuts each pocket individually at each depth.

Sometimes this isn’t a problem (actually it almost always is, just not noticeable). But I was cutting a bit case, and it just became to much for me. Can anyone help? I’d love to know if I was just doing something wrong that was easy to fix.

Easel drawn in adobe, converted to SVG and tweaked to get the right depths.

Also, I’ve found that it doesn’t seem to be flagging uncuttable areas anymore? Perhaps a byproduct of the 2 stage cutting beta?

Unfortunately the grey/white layers create the lip for the lid, and the depth is so the bits contact the magnet at the bottom of the tray, so neither are optional.

It seems the algorithm is flawed with those additional layers. Definitely interesting path choices. I think it added about 20 minutes to the cut, and over 400 unnecessary XYZ moves by dropping that lid layer in.

I have had some projects come up with really convoluted paths as well. Some of them I have taken into bCNC and moved the chunks of gcode around to limit the distance traveled in rapid, though the time required to clean up the “one layer at a time” silliness didn’t feel worth it - I’d have spent more time messing with the code than I would have saved in the cutting.

It is one of the things about Easel that has me looking towards other software for gcode generation and sending. I’m not ready to switch away entirely yet, but I am moving in that direction.

Depth first carving (as we call it), would not work well If there is a zero depth shape. We could use the combine functionality to get rid of a zero depth shape. Once we do that, easel should generate better toolpaths.

Please check following…

1 Like

That makes a lot of sense. Thanks!


I was just yesterday working on a project and it was doing an air carve of an object on a cleared surface before it finally reached the lower surface and continued properly. Couldn’t figure out why. Now I know.

Phil, Thanks for the explanation.

1 Like

@MichaelMccormack, You don’t have to do the above “combine shapes” trick anymore. Toolpaths generation handles that internally. Please check, and let me know if that worked for you!.

1 Like