Hi all. I just finally got around to upgrading my v2 Lowrider to a v4. Got everything up and running with new Jackpot board (Jackpot1… I purchased the parts a while back but haven’t got around to actually upgrading the machine until now) and FluidNC 3.9.9.
I was cutting my strut plates when the the cnc just stopped, roughly 70% into the job. It had been milling for about an hour, maybe slightly longer, without issue. Reconnecting to the AP, I found FluidNC had seemingly reset and was giving an Error 152 for Invalid Configuration. It did not show any files on the SD card at all, and the Work coordinates and machine coordinates were zeroed out. It seems like it had a reboot in the middle of the job, and didn’t boot cleanly. Power cycling the Jackpot Board brought it back to normal, with my config loaded and the SD card read successfully with my files shown.
So I guess I have a few questions:
Is there any way to capture logs or error codes when something like this happens in the future? I had been running the job off my laptop, but the battery unfortunately died before the CNC stopped, so I didn’t have the console output from the time of the reboot.
Is there a way to see how far into the gcode I got before the reboot, or do I just need to manually measure the cuts and guestimate? Any tips for picking up the same work zero location for resuming stopped jobs?
Is FluidNC known to reset like this often during long jobs or when using large Gcode files? This file was 530,000 lines long (I accidentally had trochoidal milling enabled in Estlcam, which is also why it was taking so long). Any ideas why it would have rebooted?
Is it better/more stable to run the machine from the USB port giving the commands directly from the CAM program?
You can connect a computer via USB and run FluidTerm to see the logging. This way, if it does crash, you can see the details.
No. How did you zero X and Y last time? What gcode do you have in the Estlcam start gcode? (Specifically wondering if you used G92 or G10. G10 survives restart but still might be lost if the controller crashed.)
Can you share the gcode? Sometimes crazy G2/G3 moves with large I or J values cause problems.
I’ll have to do that when I start it back up and keep a better eye on it. Time to put a laptop charger by the cnc table.
I use the startup script from the Milling Basics for GRBL. After the reboot, the coordinates did not survive. My startup script: G21 G90 G94 G10 L20 P0 X0 Y0 Z0 (set current location to zero, survives reboot) G0 X10 Y10 F2000 (move to probing location) M0 (MSG Attach probe) G38.2 Z-110 F200 P19.05 (probe down set thickness ) G1 Z25 F900 M0 (MSG Remove probe) M62 P1 (If used start spindle pin27 )
Gcode is too large for the message board, so I’ve split it into two. It failed during trochoidal movement exactly like what was used for the rest of the cuts, around line 152000 (~Y280) in the second file:
I normally home the machine the record the x and y offsets before zeroing on the part just in case. Since z is probed, i just reprobe it. It has made resuming much easier on the rare occasion it is required. Pencil on post-it or the spoil board to mark the offset from home to workpiece zero. Only takes a few seconds to do it.
You’ve had good advice from others, so I’ll offer a couple of suggestions to questions you didn’t ask?
Q: are there other known things that can cause a Jackpot system to reboot?
A1: How is your dust collection set up, how is it grounded, and what is your shop environment like? If you have dust collection, don’t have it properly grounded (hooking it up wrong includes grounding it to the VMOT (-) terminal), and you are in a lower humidity environment… in that case you might be getting ESD events that are zapping your board.
A2: how well secured are your power supply connections? Not just at the jackpot board, at the power supply where the AC cord plugs into it, and across all the routing of the machine. I’ve found loose/intermittent connections that were causing periodic issues.
A3: Do you happen to use a VFD or other spindle controller? There are ways those can run amok.
Q: Are there network related things that can cause issues?
A: Maybe. If you have multiple client devices that connect to your router, and some older versions of firmware, you might get issues if one of your devices conencts and causes a problem. This is now rare as newer firmware has corrections for it. But, it’s worth asking…
Q: Have you reset your board since this happened? If not, you could send a $SS command and we’d get at least a little insight into your board right after it rebooted. If you reset the machine since then, that would no longer apply.
Yeah, the trochoidal really ballooned the gcode and made the operation much slower. That’s my fault for forgetting that the last thing I used Estlcam for was cutting aluminum. It’s been a while since I’ve used the table, so I’m still catching up on the basics.
Thanks for the reply! Good point about ESD, currently my dust collection is just a shop vac and isn’t grounded. I just upgraded the table to v4, so I don’t have a lot of things in their end state yet. Until I get that set up, I’ll probably just manually vacuum the dust while it’s running to prevent possible ESD events.
Power supply cords are reasonably secure, but again not in their permanent spots as I haven’t yet cut the strut plates.
No VFD or spindle controller, just a dewalt 611 that I’m manually turning on and off.
I have reset the board since it rebooted unfortunately, since I wanted to be sure the full config and SD card were still readable. If it happens again I’ll be sure to grab any error codes and the startup info.
Again, not a certain cause. Some environments have enough humidity that the dust collection causing problems is unlikely. I happen to live in a dry environment where it is a problem for me.
When you do set up grounding of your dust collection, the recommendations I have are:
use a dust collection hose with an integrated spiral ground wire.
Tie the ground wire to a ground point that goes as far back upstream as possible. (e.g. using an AC ground back at the outlet or even back to a ground bar).
DO NOT tie the ground to the VMOT power supply return, this is the worst place you can tie it.
This is a little PowerShell script I had Claude generate that parses a gcode file into a CSV and split the G1/2/3 lines into columns to see if any I/J values looked crazy. Parse-GCode.zip (1.2 KB)
