Pause No Longer Raising Z

Was there a change in the latest version of CM 517 where the “Z” no longer lifts up when you press the pause? I had a bit come loose yesterday. I heard it and quickly hit the pause expecting the Z to move up…however, it didn’t It just sat there, still engaged in the wood. I stopped the spindle and couldn’t get the Z to move with Jog or anything else. I ended up resetting the machine and reinitializing and it finally came up.

Did something change in 517?


Yes, this seems to be a defect in CM517 which has been noted. Hopefully we’ll have a fix presently.

Until then, revert to 513 if you can.


A related topic: I sometimes repeat a cut exactly as just run, to improve finish quality (especially on inlay VCarving). On completion of the first cut, the gantry moves up and to the back (Z moves up, Y moves back, X doesn’t change). So far so good. If I then hit ‘start’ again, the sequence is that Z drops to ‘safe height’, and then X and Y position to the 0,0 reference in the job. I know ‘safe height’ means that there should be nothing in the way when the gantry moves, but sometimes there is a clamp or similar ‘in the way’. If the gantry moved XY first, then finally drops Z it would avoid this entirely.
Using CM513 and most often gcode files from Vectric VCarve. I will check if the post-processor in Vectric is what sets this sequence, but I don’t recall it being so… It seems to be a CM513 thing

My mistake - it was set like that in my edited Vectric post-processor script. I transcribed header to footer settings and didn’t reverse the sequence of Z then XY.

Now reads correctly;


1 Like

Is a link to 513 available, please?

Thank you :slight_smile:

I’m not sure it’s your mistake. It makes sense to me that the return sequence should happen in reverse to the safe sequence.

Is this something ‘programmable’ in CC or can this only be done in Vectric software?



@NewToThis the necessity to tinker with post-processor scripts is down to Vectrics not being specific to any given hardware. CC doesn’t have this issue as it knows exactly which hardware it will be used with - hence no post-processor ‘editing’ either necessary or available

I too, have had the z-axis drop before going to the XY coordinates and it smashed into one of my clamps that I thought was completely out of the way.
I think your suggestion of XY positioning before Z is a wonderful idea.

Actually, in CC5 we’ve begun to add post-processor support — there are 3 thus far, and more will be added in the future.


“Parking” during pause was removed in the latest build. If there are strong opinions one way or the other, please let the management know.

1 Like

It would be really great if the Pause screen has buttons for

  1. Re-home the machine
  2. Remeasure the bit on the bitsetter

That way if you notice you lost some steps or snapped a bit, you can take corrective action and survive

Winston - when you say ‘parking’ do you mean retract to max Z, or that Z retracts then XY. If no movement in Z will now happen at all upon pause activation, I would personally argue for its return

Maybe it should be a 3 stage thing?

  1. Pause == stops where it’s at
  2. Retract == lift in place
  3. Stop == stop spindle (if under spindle control), lift completely and go to back edge and abort job

Or a checkbox preference?

1 Like

It has to retract - just because one major reason for pausing is when you’re hearing something that’s not quite right and you want to check it out before completely committing a restart. Once you move X or Y, you’re starting again (unless resume returns to the same XY)…but raising it in place makes sense. For my problem, it definitely would have helped.

1 Like

“Parking” during pause was removed in the latest build.

Hey Winston - was this documented somewhere? I hate to discover deprecated functions by trial and error. The release notes for CM don’t seem to mention it - unless I’m missing it:



  • (FIX) Changed calibration limits for Nomad 3.


  • (NEW) Changed settings page to make the machine travel a little more configurable.
  • (FIX) Warning before sending configuration to Nomad.
  • (FIX) Probing offsets for BitZero V2.


  • (FIX) Better handle pulling off of limit switches when initializing.
  • (FIX) Longer dwell on Nomad spindle RPM changes.
  • (FIX) Edge case where the machine position could be off after homing.


  • (NEW) Added support for Nomad 3.
  • (NEW) WASD also active for XY jogging.
  • (NEW) Added support for BitZero V2.
1 Like

I’ll have a talk with the boss. Personally I’d like a checkbox in settings for whether or not you want to allow parking, as I don’t believe this is baked into GRBL.


given the #define ENABLE_PARKING_OVERRIDE_CONTROL in config.h I guess this could just a matter of sending M56 P1 or M56P0 depending on a setting ?


I’m all for as many checkboxes as you’d like. The more flexibility, the better!

I’m not sure checkbox options would help here. In my mind there should only be two options mid-process:

Pause, which would raise the spindle and, if you have BitRunner installed, stop the spindle. A continue option after this would start the spindle the return it to the job.

Panic, which would do pretty much the same, but ‘home’ the spindle as well.

Just my 2 cents worth.

1 Like