Normally, when a job is running, two LEDs on the controller board are blinking.
Today, when running a program in soft pine, motion stopped abruptly in the middle and Carbide Motion (macOS) becomes unresponsive. Switching the machine off and on again allows to re-start the program from the beginning (work offset is not lost), but then it just stops a few seconds past the last stop. I’ve rewritten the program for half the initial load, but the same problem occurs even when running the “lighter” program at 70% feed.
When stopped, the controller LEDs are either
only blue LED on, continuously
blue, read and green on, continuously
Does anyone know where to find an explanation for the controller LED light patterns? I think that would be useful for troubleshooting.
I’ve had this same exact thing happen and the cause, I believe, was static discharge. I replaced my original dust collector hose with a carbon impregnated, conducting hose that I have grounded to my house ground. Since doing this modification I have not had the error again.
Thanks for the tip! I’ll definitely try that. Although it does seem a little strange, it’s could be that the static builds up during the job and then discharges after a little while.
Thanks for the explanation of the limit switch LEDs, didn’t even know they were down there.
Hmm, the job was more or less in the middle of the work envelope, so I don’t entirely understand how the limit switches would be involved. They certainly work fine when homing on startup. Or do you mean that they have a tendency to fire spontaneously and could go off in the middle of a job?
That the switches will occasionally indicate being closed when not due to electrical issues is I believe part of why they aren’t enabled as limit switches — they should be made up w/ shielded wiring for that — the other reason is there aren’t enough (need two more on X and Y at least.
It doesn’t look like the homing switches are the problem: When I intentionally push them in while a slow program is running, the program just continues running. So it looks like the switches are ignored in this situation.
Back to the title of the original post - judging from discussions on github/grbl, red & green LEDs all-on or all-off means the USB interface chip got confused, which interrupts communication between Carbide Motion and the controller.
After various experiments, it appears that the problem was that the MacBook was running on battery. The theory is that after some time, the GND potential that the laptop puts on the USB connector deviates too much from the GND that the controller sees from the power supply brick, so that the USB interface chip on the controller board doesn’t understand the signals any more. Not sure that could happen - depends on how the USB interface on the board is wired (isolated?).
Anyway - simple solution: Just always have the USB host laptop connected to power. Maybe something for @Julien’s excellent book?
I’m not familiar with MacOS power management options, but is it possible that it put the USB ports to sleep after a while when running on battery ?
Anyway, I added the advice of running laptop on power (and/or checking power management options) to the list of tips & tricks to address USB disconnects, in the ebook (upcoming v3 version), thanks !
if one would just solder a 0.1mfd capacitor across the switch, then transient events would not occur.