Pause as a toolpath step?

I’ve run into this situation several times where I’ve wanted to add a pause between steps to allow me to check what’s done before continuing. Is that possible? I can hit the pause button if I’m standing right there but sometimes I’m not fast enough. Adding a false cut with a different bit works too but then it’s two extra trips to the bitsetter. Same if I end the cut and run a second script- gotta reinitialize and bitsetter.

Not sure if the code allows it, but if it could be added as a toolpath step, I’d find that handy.

There’s a feature request here for that:

1 Like

The problem with pause is the router lifts straight up and if you want to measure you have to work around the router. Just for looking the pause works.

Regular pause (clicking the button) does the same thing. Router is still there. That’s exactly how I’d expect it to work. I just want the ability to program in the pause and not have to wait there to click at the exact right time. From what Michael is saying, the command already exists, so why not have it as a selectable toolpath?

Gcode is just text. Add in the pauses where you want. Carbide create labels toolpaths very well in the gcode.

Yes…but doesn’t this put more requirement on the need to generate and edit GCODE, which is already a pretty sensitive topic here? Sounds like there’s a way in the GCODE language to program a break…so having it interface right into the toolpath dialog - and behave like any other Toolpath (move, enable/disable, etc.) - would be a boon.

@ProfessorEcks My only question is whether you’d expect the pause to happen during the simulation. I suppose it could pause the simulation (with the message) and then allow you to continue it. That would be pretty cool.

1 Like

I hadn’t thought of that, but that’s even cooler!

The gcode thing… honestly, that’s a hassle compared to a button in a list. Carbide create is designed to be simple.

Also not good for users who don’t have carbide create pro, since exporting gcode is now a pro only feature.

I understand the reluctance to edit gcode. @mhotchin put in the feature request. Just suggesting a workaround.


Yup…these are the points I mean…there’s so much discussion about the complexity of generating GCODE…seems to me, the less things that cause us to generate and edit GCODE the better!

This could also be handled by a post processor which I thought there was a hint at opening those up to the end user.

1 Like

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