Bit not retracting

So I have created a project in easel to run on my shapeoko and there is something wrong with the bit not retracting to a proper high in a few instances. Hopefully the video shows and I’ll also post the link as well. Does anyone know what is happening.Untitled(1).wmv (4.5 MB)

No video atm.

Does it happen when completing the carve or randomly in the midle off a carve?

Video just posted. Randomly during the carve. Mostly the E C A part of the carve

Does the bit return to the original XY after completion of carve?
If so its in the code, perhaps a post processor issue. (Easel -> ShapeOko)

Yes it dose return to the original xy after completion.

Is there a way I can report this to inventables? Other than posting on the forum?

Link to Inventables support on the bottom of this link:
https://inventables.desk.com

If the bit return to the XY origin (and Z safety height) then the reason for bit not retracing is in the code.

@HaldorLonningdal He has some “retracts” that only reach the height of the first step down (-0.125"). I’ve seen this same problem reported by others. I’ll see if I can find the threads.
@AlexGrecheski They always say to click the button where it asks how the carve went as a way to get the issue to support.

1 Like

Yeah I recall such posts from earlier this year, thought it was fixed.
@AlexGrecheski - could you open up Machine inspector and report back Easel and GRBL version?

Here’s another:

More:

New one:

I’ve never seen the button to click that asks about how the carve went but that’s probably because I download the rough and detail files and import them to carbide motion. So I’m also guessing that machine inspector and reporting what easel and GRBL version won’t work as well.

Okay, Easel -> CarbideCreate (CC)…

The Easel bug have been dealt with but when you use a different sender (CC) all bets are off.

Do you have to use CC or can you use Easel also as sender - staying entirely within Easel?

How so? Easel generates the toolpaths the same whether you’re exporting Gcode or running the path through Easel. So how would the bug be fixed when running through Easel as opposed to exporting it? It’s already been established it’s a toolpath issue…

Are you running the detail first and then the rough? Easel used to use some principals of rest machining and assumed you had run the roughin pass first so it wouldn’t fully retract so it could optimize carve times (well, that’s the only logical reason). I remember seeing a rapid inside of a pocket and thinking to myself that I was glad I did the roughing pass first. Not all software does this and there are times where doing the detail pass first is beneficial but, another reason why I bought Vcarve.

1 Like

@JustinBusby Yes I do the roughing pass first.

There is a bug in the generation of the toolpaths. It’s simple to recreate.

Red lines in Easel preview are rapid (non-cutting) moves.
The highlighted rapid (among others) is a retract to -0.125" which is the same height as the surface of the carved text.
That move occurs at line 4378 & 4379.
Technically, it is at the same height as that was cut. In theory, it wouldn’t cut anything. Reality is different. Not many would run rapids across a workpiece with a retract to 0. If it’s not a bug, it’s a bad toolpath.
@JeffTalbot @Ruwan Is this the expected behavior in Easel?


1 Like

So how hard do you think it is for them to change that?

I thought that was fixed :confounded:

I did too.

@NeilFerreri1 and @HaldorLonningdal… SURPRISE!!! It’s not fixed. lol

1 Like