From a safety perspective, it’d be really great if the firmware inside the CNC could turn off the spindle if the serial messages stop coming. Presently, if the PC app reports a loss of serial condition, the CNC just stops where it is, with the spindle still going full bore.
The real problem is that the system can’t handle the voltage and current that the spindle draws. It’s also running on (for the most part) an Arduino which has very limited memory and functionally. Remember you (we) bought a hobby CNC, but dreaming is always fun.
I understand the possible failure mode. I was thinking of a simple timeout if no serial commands are received in N seconds (2? 5?), the Arduino runs a few simple commands itself. At a minimum, set spindle speed to 0; perhaps more elaborately would be running the homing process. I perused the GRBL source code briefly, didn’t see anything like that implemented. Is the firmware for the Nomad totally split off from that, or are GRBL improvements rolled into Nomad?
Good question and I’d also like to know that answer. The guy who writes the GRBL code is also here in the forum (don’t remember his name). I noticed that the Ver 2.4 board has a additional set of plugs labeled “Nonmad.” I’d love to see if someone could find the motor on/off pin. Guys???**l
not sure how well that will work. If I filled the buffer with 4 simple commands that perform a square at set feed rate of say 10imp and the square is the 4 max extents of the machine, it will take quite some time for the machine to complete before I am able to send more commands. Personally I would not enable such a feature.
If there is some way to detect a usb disconnect other then waiting for a command, then it may be an option but waiting for a message I think is not the greatest route to take. Maybe if the usb chip has a signal pin they could test for connection with, it would be great. I have not studied the circuit that well to determine if there is even such a thing.
1 Like
Good point, Roger. I don’t know the system well enough to speculate. I just know that I see a serial command failure show up on the PC, and more or less simultaneously, the CNC stops doing anything. It sits with the spindle turning, which suggests that it finished the last G-code line and doesn’t know what to do next. So that suggests that it’s waiting for a command to come in. In that event, I’d propose that the Arduino turns the spindle down to 0. But I defer to someone with more knowledge on the specifics of the system.
Sorry Roger - just realized what you’re saying. Most of my runs are short hops of G-code (a few mm at a time). I don’t know what the right answer is.
Do you see the serial failures often, where Carbide Motion loses connection to the CNC?
To answer this question correctly let me give you some background.
When I got the machine, I did experience this 3 times. 2 of the 3 times happened when my wife decided to start the vacuum in another room. Not sure about the other time.
At that point I decided to move the CNC controller to a UPS or APC power supply and connect my computer to the same UPS /APC. From that point I only experienced it once because I tripped on the USB wire lol.
However I will also say I don’t use Carbide motion much if at all any longer. I do use Carbide create a little from time to time but now that my software does everything Carbide Motion does, I no longer use it because I find it slow and clunky. I have not had my software disconnect on me (yet) knock on wood.
That’s pretty good! Did you homebrew some software, or is it another package that you use? I see a serial failure a few times a day, if I’m running the CNC all day. Interestingly, I have a small shop vac on the same power strip, and I run it every few minutes, and I’ve yet to have a serial failure that way. Always seems to be random otherwise. Not a huge deal, just delete out the lines of G-code that are already done, and restart.
So I had a thought, and it’s probably more involved than the simplest solution. One solution to your use case of running the machine to the four corners at low speed would be to have the Arduino compute travel time to the next point, and the timeout period is travel time + 2 seconds. Not as simple as just waiting for a straight timeout, but would accommodate long travel distances.