I recently added a Raspberry Pi to my setup to use my Jackpot board as a GRBL 1.1 controller. I modified the USB cable to prevent the Pi from powering the Jackpot board which eliminated nearly every problem I had… except this one.
I use Fusion360 CAM with the flyfisher604 post-processor, in GRBL1.1 mode. Even while CNC.js is running, I can have FluidNC open in one tab, and CNC.js in another and use either one to jog the machine, upload gcode and run jobs.
I can run multi-hour jobs from FluidNC to cut/mill/carve both wood and aluminum. I’ve never had this problem occur with FluidNC (on wood or alum).
I have run multi-hour jobs from CNC.js to cut/mill/carve wood. I’ve never had this problem occur with CNC.js + wood.
The issue is CNC.js + aluminum. Using all the same software and workflows (but obviously updating feeds & speeds), just about any job I run through CNC.js for cutting aluminum will freeze after 5-120seconds. All motors will simply stop. Jackpot board won’t respond to anything and has to be reset. There will be no errors or warnings in the console. There are no errors or warnings in the CNC.js logs on the Pi (~/.pm2/logs/cncjs-*.log). It’s been a while since I tried this, so I don’t have an example, but I can try to trigger this again if it’s relevant.
Because of the above, if I’m cutting aluminum I will use CNC.js for keyboard jogging and to run my XYZ probe macros, in order to set my work coordinates. Then I can just switch to FluidNC, upload my gcode there, and run from there. That workflow has never failed, despite being somewhat obnoxious.
The router (which I turn on and off manually) continues running fine. The raspberry pi is still responsive, I can still SSH in. CNC.js interface is still up, it just stops being able to communicate with the Jackpot.
Since this is material dependent, I feel like this must be electrical somehow. In my recent upgrade, I did run cable chains, as seen in the picture below. The 600W router cable runs through the same chains as everything else. Not sure if that matters. But again, I can run an hour-long wood carving with no issue, it’s only aluminum.
Taking a stab, since it appears to only be for conductive material, could there be static building up somewhere and a discharge causing issues with the controller? Could also be electronic “noise” from the router motor brushes somehow making it back to the controller.
This is all supposition on my part, but to experiment I’d check to see if there’s continuity between the work piece and the controller ground. If there is, try seeing if you can separate them. If there isn’t, try grouding/bonding the work piece to the same ground as the controller and see if that resolves the issue.
Another thought, how is the router getting its power? If you created an outlet or power extension for the router, are you sure you kept the neutral and hot wires the same throughout the extension? Again, just a stab in the dark.
… try grouding/bonding the work piece to the same ground as the controller and see if that resolves the issue
I’m not the best at dealing with these kind of second-order electrical issues, but I could see that helping. I already have an XYZ plate permanently connected to ground nearby, I will just place it on the workpiece next time to see if that changes anything.
how is the router getting its power? If you created an outlet or power extension for the router, are you sure you kept the neutral and hot wires the same throughout the extension?
I decided not to mess with 120V AC and simply have the router directly plugged into a power strip (the same one as the pi and all the other electronics), and I turn it on and off manually for jobs. Though I wouldn’t be surprised if the 120V AC power cord running alongside the motor wires could cause some kind of electrical interference issue.
What of you run the same gcode in an air cut or in foam?
I don’t like the guess that it is EMI or static. That does make some sense. But it is too easy to just go to those as a catch all. It also seems very consistent at 5-120s. That seems too regular for emi. Static often kills parts. Not just stopping things.
Cncjs does have some trouble if it ever misses an ‘ok’ response from Marlin. I am not sure how it works with grbl, but it always seems more reliable. Is it possible the USB cable is bad?
What [i]f you run the same gcode in an air cut or in foam?
It’s weird that the exact same G-code that fails with CNC.js + aluminum, can be loaded and run on FluidNC + aluminum without issue. I never tried running it in CNC.js+air, though. I’ll have to try that. Maybe there’s some aluminum-specific feeds and speeds that CNC.js can’t handle.
Cncjs does have some trouble if it ever misses an ‘ok’ response from Marlin. I am not sure how it works with grbl, but it always seems more reliable. Is it possible the USB cable is bad?
The USB cable an interesting thought. But again, I have run multiple 1+ hour carving jobs with CNC.js + wood without issue. Yet nearly every aluminum job fails in the first 1-2 minutes.
Cncjs does have some trouble if it ever misses an ‘ok’ response from Marlin
I can’t remember exactly how it works…can I try to connect to it as a Marlin controller instead of GRBL? Maybe that’s worth a try.
Btw, I’m sure you don’t need a video to understand what the problem looks like, but here is one anyway. It literally just stops as if the motors were suddenly disconnected.
Something I forgot to ask: is there a way to activate/access debugging on the Jackpot board to get better visibility of this? I am able to see CNC.js logs on the Raspberry Pi via PM2 (the process manager that makes sure CNC.js is always running), but that doesn’t tell me anything. I suspect there’s a way to see exactly what the Jackpot board finds so offensive.
Now I’m wondering if grbl may be seeing activity on this and interpreting it as an end stop trip. Do CNC.js and Fluid NC have different behavior designed for end stops? I know Marlin only pays attention to the end stops during homing where grbl has them active all the time.
Super interesting idea. I have been annoyed that the default FluidNC behavior is not to listen to the endstops after homing. Maybe in GRBL mode it’s the reverse.
But, I have to put a clip on the bit and move the XYZ plate onto the workpiece for the circuit to be complete for triggering the Z-endstop, and during these stops neither of those conditions are true.
HOWEVER, the wires for each side are super long, with the positive side going through the drag chains with the other wires. They are basically antennae, and I’ve had problems with limit switches in other projects using long wires. I solved it with a pull-down resistor to stabilize the signal low to overpower the fluctuations. I was under the impression the Jackpot board had these integrated for their endstop pins. But maybe somehow the 22k RPM spinning bit and large conductive metal plate are generating fluctuations and triggering the endstop.
I will try running a CNCjs job in air with the router off and see if it stops the machine when I trigger the Z-stop.
My Burly was very prone to false positive end stop triggers before I added capacitors across the pins on the arduino CNC shield. I had a spool of 6-conductor shielded cable, so my end stops run in parallel to the motors so lot’s of noise on the line.
You should be able to see if the probe or end stops are triggering with the $ command.
I just tried running a job with CNC.js in air, and confirmed that triggering the Z-endstop did not stop the job. It was a feasible theory, but that wasn’t it.
Did you test the exact same gcode, but in the air? I would test it with the router on and off, in the air. That will eliminate aluminum as the source of the problem (or confirm it).
From the video, is doing a lot of small arcs to do the helical drilling. Maybe that is the issue with this gcode and cncjs
