Well, this one was quite odd. Never seen it before. I left my Nomad running unattended for a few hours, and came back to find that CM had crashed with a Windows pop-up: "Carbide Motion has stopped responding and must be closed."
Okay, these things happen. But the disturbing (and possibly dangerous?) part was that the spindle was still going at full rate, touching the stock, with the axes all frozen where the Nomad had been when CM stopped.
The weird part was that, when I rebooted CM and tried to re-run the same GCode file, without re-zeroing (I couldn’t anyway – I’d zero’d to the top center of the stock, and it wasn’t there anymore), the Nomad had completely lost zero – in fact, the table went right to the back end and started cogging the stepper motor (isn’t there a limit switch at that end?). Now, as far as I was aware, the machine zero is stored in the GRBL board, so crashing and/or rebooting CM should have no effect on it, yes? The Nomad was not rebooted, just CM.
So, I dunno – I mean, nothing caught on fire from the spindle burnishing the same bit of the wood for hours. But was there a risk? At the risk of being the “how hard could it be?” guy, I have to wonder if perhaps having the firmware stop the spindle when there’s a communications timeout would be a good safety feature to have.
The Zero loss is more puzzling, but less worrying – I can always throw in another block of wood and re-run the job. But it does run counter to what I (thought I) knew about the Nomad’s firmware workings.