Z axis cannot be stopped


Just had a second case of a non-stoppable movement with Carbide Motion (Mac OS, Current version). It happened as follows:

  1. set my X and Z to my piece of wood
  2. went down in Z and accidentally hit the wood when doing that, then corrected it up again
  3. set 0 to exact top of the wood
  4. started job
  5. job started appx 1 mm over the top of the wood, so i stopped the job
  6. Now the issue:
  7. tried to calibrate the NOMAD again via Carbide Motion
  8. Homing finishes, tool measuring finishes
  9. now i want to move the spindle via arrow key to the right, and the Nomad starts moving DOWN on the Z axis instead, and keeps moving and moving. clicking anything (like other directional buttons) in Carbide motion does not stop it from moving down on Z. The buttons get pushed in though when i click them. So i stop the NOMAD via its power switch.

This happened the second time, the first time it didnt happen right after the homing, but when i had the spindle positioned on X and Y already, when i think tried to lower the spindle on Z, it also did not stop anymore and kept going down until i had to flip the emergency off.

Any idea what can cause this? It might have to do with my error in step 2 somehow. I do not really want to repeat it just to try to see if i am right though, but maybe Rob knows what causes this, maybe a bug in the code where a buffer doesn’t get flushed?

I’ve had the exact same thing happen. Any time I have to quit a job, via e-stop or the carbide motion ui - I have to close carbide motion and power cycle the machine, then all is well. Otherwise it seems all bets are off.

Maybe it is a code thing, I wonder if some of the variables in the code that determine either the current position of the end-mill or the 0 point don’t get cleared so that it is always off.

Something only @robgrz can tell… Rob, maybe as a quick fix, maybe it can be implemented that when the user clicks to Quit the job, that carbide motion just spawns a new version of its executable in another window, then closes the initial executable. That should be so fast that the user cannot see it happen, or even if, if it helps to avoid that issue (its really scary if the spindle starts moving and you cannot stop it although the buttons seem to react) its worth it.

On another note: is there a function in the code that prevents the endmill from ever hitting the original metal tray?

Something like “If EndmillTipZ = MetalTrayUpperZ+1 do not decrease Z anymore”? That would help new users (or if we make a mistake) to at least never cut anything lower than the wasteboard bottom.

This happened to me. I notice it happens when jobs are cancelled, especially if you hit the estop (that is if it even recovers).
Solution for now is to exit carbide motion and re-connect. I do not have to power cycle the machine.

I have gotten in the habit of treating both MeshCAM and CarbideMotion like command line apps. I only ever do one job with them and I have not seen hardly an issue. In MeshCAM I will generate one or multiple tool path files for a single part only. In CarbideMotion I only run one nc file as zero is remembered by the machine. Yes I have to re-home the machine every time, but that is not as bas a loosing a part. I have not lost any since I have started doing this.

1 Like

I take the same approach, I think it helps. Plus I find Carbide Motion opens instantly on my Mac, so it’s no hardship. I don’t bother power cycling the machine though.

I often go a step further, using MeshCAM to generate separate tool path files for roughing, parallel finishing, and waterlining/pencil finishing, so I can switch cutters and test multiple speeds/feeds.

But why are you re-zeroing the machine every time?

Not re-zeroing the machine, it homes every time you start CM.

I currently do separate job files when I need tool changes, or want to add extra detail passes in confined regions.

Oh, sorry, I mixed up zeroing and homing. Oops! :sweat_smile: