Actually that’s @robgrz chiming in, not Apollo
But, his answer doesn’t explain why GRBL would need to be involved—since the job is streamed rather than dumped whole onto the machine to run, it should be possible in Carbide Motion to note what line the program is on when the pause fully goes into effect, and then issue a z-retract of known value and a spindle stop, just as if they had been in-line commands in the source g-code.
I realize that there’s probably a substantial amount of read-ahead and path-planning on the controller board going on, so I get that could be a factor, but I’m sure there’s some reasonable “block end” at which you could plan ahead slightly and break the execution, saving your spot in the original g-code program for coming back to.
You could also then open up the MDI to jog the spindle out of the way, clean up the part, add some lube, whatever you need to do. When you’re done and you press “resume” it could prompt the user with a “is it safe to continue where the job left off?” dialog to remind the operator to ensure the workspace is clear, and then it could do some logic to review current position relative to program prior position, and if in any doubt, it could even home again to ensure that the program position and world position haven’t been ruined along the way anywhere.
Then it’d make an X & Y move first to get above where it was in Z at the step where it left off, it’d kick the spindle back on (searching back through the g-code for the last issued spindle speed command, it’d reissue that speed) and plunge slowly back into cutting position, and then resume the job from that line.
Even better would be to have it go to a point several moves prior so it can get the momentum/inertia right too.
Yes, it’d require implementing some logic, yes it’d require some fancy footwork on the Carbide Motion side. I didn’t say it’d be easy, I said it’d be extremely helpful