Questionable toolpath generation with v-carving & 2-stage cuts

I’ve been enjoying the new v-caring features of Easel Pro. However, the toolpaths it makes seem really unoptimized. Maybe that code is still WIP, but it’s worth calling out. I’ve see this same behavior on multiple cuts. I’ll explain what is happening below.

I was recently commissioned to make the below sign. All and all it turned out fine:

And here are the toolpaths from Easel, which look normal at a glance:

I did the rough cut with a 1/4" endmill, and the finish pass with a 60 deg v-bit.
The rough cut went fine, nothing out of the ordinary.

Here are the issues I saw happening with the finish pass, with the V-bit:

  • As you can see, there is a (1/8") pocket that defines the outer frame (made during the rough cut): When the v-bit went to chamfer that edge, it did it 4(?) separate times. Not 4 times in a row: It would cut it once, do a bunch of other work, then do it again, etc.
  • Every letter’s outline was traced 4(?)s times in a row before any actual cutting happened deeper into the stock.

I put a question mark after ‘4’ since I think that’s how many times it repeated itself. Could have been ±1.

My guess is this: Since there was a pocket made in the rough cut, the v-bit algorithm had a malfunction: Rather than stepping down into the pocket and doing all the cutting needed, it instead repeated the same toolpath over and over as if it was stepping down, presuming there was no rough cut. However, the funny thing was, it was stepping into the pocket, and then just tracing the same toolpath border (on the outer edge, and the outline of each letter) over and over 4(?)x in a row without ever actually descending further into the stock.
Then, it finally started cutting down into the stock to give me the finished product you see.
Safe to say, I found the whole process unerving… I couldn’t figure out why it just kept repeating the same moves over and over…

Again, my guess is this has something to do with the pocket cut during the rough: I’ve done other cuts where the v-cut wasn’t in a pocket, and it behaved ‘normally’.

The other issue was, none of the letters were cut sequentially in the finish pass. It would cut one letter, travel (really slowly for some reason) to another (seemingly as far away as possible), then would arbitrarily jump to another. This was painful to watch.

The bulk of the time on this finish pass was mainly traveling arbitrarily (and slowly) around the cut, and then making 4x cuts in a row that it shouldn’t have.

Again, enjoy the V-carving feature (can do this in Fusion360, but it can happen a lot faster in Easel), but the finish pass easily took 2-3x as long as it should with all the above-mentioned issue.

I’m happy to share this project with the devs if it would help.

1 Like

Vcarve does this same behavior when doing cuts like these.

What you’re referring to is called rest machining where each toolpath is generated based on having the previous path already run. Fusion360 has support for this.

Since Easel doesn’t force the order of cuts, it can’t assume that roughing was done so it must start “fresh” otherwise it would cause Machine issues if you run the finish path first.

Hrmm… I’d respectably disagree with that assessment:

I’d argue that it does do rest machining, since the v-bit didn’t try and cut the pocket from the rough (it respected the pocket and only cut the border like it should), nor did it try to cut the ‘letter pockets’ the rough generated. It only cut what it was supposed to except for the extra cuts mentioned above.

To be clear, it didn’t cut the frame outline at the top of the stock, trace the letter border, drop a layer, and repeat.

Instead, it literally dropped inside the pocket to the top of the roughed surface, then traced the exact same toolpath 4x in a row (the outer chamfer, and the border of each letter) before doing ‘what it should’.

It seems like it is using rest machining, just not doing it right?

I might have misunderstood what was going on. It was early so I apologize.

Without seeing the Gcode, I wonder if the ideal toolpath thinks there is material left over but in reality, it’s being either previously carved or its so small it chips out during the roughing pass. This could be because a 0.25" bit is cutting larger than 0.25" or mechanical stresses and bit deflection. I’ve noticed that sometimes my 0.25" downcut is cutting a little wider than 0.25" and when I do my detailed pass with a 1/8" bit, it thinks it should remove material when it’s already removed.

n/p, I appreciate your thoughts. My hope is the Inventable devs will chime in with their though.

I hear what you’re saying, and I’ve encountered similar things: A slight ring/waterline will be left over on my chamfer since the rough cut bit was maybe slightly bigger than stated. Sometimes.

But in this case, it’s still a bit different: When I did the 1/8" deep pocket, I set my roughing stepdown to be 1/8" : The rough bit only did one pass for that pocket. Then did a few other deeper passes on the letters. Then when the finish pass went in to cut the chamfer on all the edges. Like said, it just sort of did the same toolpath 4x in a row, on the exact surface of the rough pocket (I could see a very faint outline from the tip left after the first pass that didn’t change for the other 3), before dropping into the stock. I even had my v-bit stepdown set at 1/8" as well, none of this makes any sense, just a bug in gcode generation system.

hi @AK_Eric,
Could you please share the project? We will have a look.
Thank you
Ruwan.

Sure: Here is the link to it:


Thanks for looking!

1 Like

@Ruwan : Any chance you were able to understand what went wrong with this? Just wondering.

Hi @AK_Eric,

Sorry for the late reply. We will be fixing this issue next and we’ll follow up with you when the fix is out.

Thank you for your patience.

Ruwan.

has there been any progress with this issue? I have been noticing the same issue. After the pocket is roughed out, the v-bit will do several passes barley cutting anything if at all. out of a 45 minute cut 20% of it has been this “no cut” tool path.

any new information would be great. I believe that a 45 min v-bit cut could be shortened considerably.

1 Like

I’ve noticed a lot of questionable tool-pathing as well, but not just with V bits. It seems that there is a LOT of un-needed retractions or carving a portion of a text letter only to jump to the other side of the material for another partial cut then back again. I have a lot of wasted time in “illogical travel” or retractions to only move over just a bit and plunge back in for a cut that that could have been done without the retraction at all. I notice it’s the worst on the 1/32 bit and I could give a little understanding to it being that the bit itself is so tiny and brittle, but it really does seem excessive and doesn’t explain the seemingly random hops to other places in the project rather than just working/cutting it logically from one side to the other.
Anyone have any ideas about this?

1 Like