Software Crash?

Hey all,

I haven’t updated in a while, but the lowrider is cutting pretty great recently! I’ve been able to use it to actually make stuff, rather than just troubleshooting it non-stop.

However, I decided to give some 3d carving a try, and I’m experiencing an issue that I /think/ is in software:

Attempted Model:

Gcode of cut:

F360 Photo of Cut:


Symptom: At the burn-mark, the machine stops for a moment, the LCD screen reboots, and in that time, it loses all motor power, crashing the router into the piece. And both attempts it stopped at exactly the same point. The operation is a warped spiral, so it doesn’t spend long in that spot. And the diameter of the exposed area is the same on both cuts.

Feedrate X/Y: 500mm/min

Feeddrate Z: 333mm/min

DOC: 4mm at the deepest, which this is not

Bit: 1/16 flatmill

I’m going to be away for the weekend, so I won’t have time to do further tests beyond inspecting the gcode, but I wanted to see if anyone else had ideas…

I think it might just be bad code or a bad save, looks like a bunch of info is missing.

Unfortunately I’m on-call right now so I have basically no time to look at the gcode. But I sent this thread to a friend, and he’s introspecting the gcode now. Sounds like there’s a bunch of crazy stuff happening. I’m going to take the liberty of copy-pasting his texts.

There does appear to be some issue in the GCode, I'm seeing similar results to Ryan. Line 6378 has a bunch of some character that's not a space/tab/linereturn. Same with 14419
I can't even delete the characters, it's being super fuckey
I've fount that N++ can handle the file a little better, and it shows about 200K and a million NULL characters on those lines. If I remove the null characters the code doesn't line up so I'm guessing those chunks turned into the nulls
So! Sounds like Fusion360 really messed up on this.
But at the same time, I do wish the firmware was resilient against bad Gcode. It's been a long time since I wrote any embedded SW, but this could be the time to do it :)

I would just try to save it again, it was probably just a bad save.

I always look at my code in repetier like that screen shot I sent, it helps a lot. the built in code previews rarely pick up on the issues. Repetier will show it like the machine will move.

You’re approaching a holy war here. Fail early, or fail gracefully? I’m in the fail early camp. If it had just ignored the crap, then kept going, the problem may have been more subtle and taken days to find. I like to say, “Fail early, Fail hard” and I sometimes add, “Fail often”, just for fun.

If you come from a “one chance” type of industry, like medical, space, or some parts of defense, then continuing with errors in production code might be preferred, but it’s hard to do that during development because the software walks past problems so quickly. They end up being hard to detect.

I’m guessing the reboot want the only clue either. I wonder if there was a message on the serial port explaining they couldn’t handle those characters.

Your buddy is right as to what’s wrong with that file. It has a bunch of NULLs in the middle, and removing them shows that a bunch of the gcode is actually missing. Best to try and resave it. If the save fails the same way, try saving to a different device. If that’s also bad then it’s time for a bug report, since the issue is repeatable.