I hit a limit switch while running an NC file – I was making a wide cut, and didn’t buffer my Zero far enough. CM gave me a “click to begin Homing” prompt, which I did. After the Nomad homed successfully and moved to center on the X axis, I got a pop-up “GRBL Error: Undefined feed rate.” When I clicked past that, I got a “Click to Measure Tool” prompt, but when I hit it, CM just went to a blank screen, and the Nomad didn’t move.
Shutting down and re-starting CM worked fine, so this is a pretty minor issue, if at all.
A few quick questions, trying to bug-hunt a bit here.
Is it a repeatable issue, in that it does it every time that you try to send that particular file?
Where are you generating the NC file? Is it from MeshCAM or somewhere else?
Is this on the first run on starting-up Carbide Motion, or is this happening after you’ve turned the machine off, moved the gantry off the limit-switch, and then turned it back on again without restarting Carbide Motion?
Hey, U9. Sorry, work has kept me away from anything not directly paycheck-related for the last two weeks.
I can’t speak to repeatability – once I finished facepalming over having created this situation, I went back to MeshCAM and re-made the NC file, with better attention to my scaling so as to avoid running off the edge of the map (so to speak).
I think this was my first NC file run in CM for that startup. I don’t recall having to turn the machine off and manually push the head off the limit switch – IIRC, I was able to simply click the “begin Homing” prompt and the Nomad walked off he limit switch on its own (but it’s been enough time passed that my memory could be wrong).
I did not restart CM until after it blank-screened on me after I hit the “measure tool” prompt.
Since you re-made the file, have your results improved? Any updates here?
Also, check to make sure you’ve got the most up to date versions of both MeshCAM and Carbide Motion before your next test, as that never hurts to check, and we’ll stay tuned.
My thoughts are that if the machine-state between GRBL and Carbide Motion gets out of sync then Carbide will send a command and not get the response it’s looking for, and that’ll cause that stall-out, where it’s waiting for a confirmation it’s not going to get.
If it’s a repeatable case, then we might be able to put a time-out check or other error handling to catch that condition and recover from it.
The reason restarting Carbide Motion solves it is that the first thing it does is start with a clean slate and reset the state of the GRBL controller
I haven’t seen any repeats of this issue, but I have yet to hit a limit during a cut, either.
Given what happened, my guess is that you’re correct. It’s pretty minor as glitches go, given that it only seems to happen with an unrecoverable fault (bad zero or NC file), and clears easily. But I thought it was worth getting on the buglist, just on general principles.
