M4 crashes whilst trying to cut gcode

Hmm… The G2 / G3 not being supported on fluidNC seems like it could be the culprit.

I have generated some linear gcode from FreeCAD which can be done without messing with the postprocessor using the flag “split arcs” for path/CAM operations (not that anyone seems keen on FreeCAD, fair enough).

That has no G2 or G3 codes in and I can try it next weekend. Here is the linear code in case anyone has the time to verify we are bumping into that
sheet1.ngc (411.9 KB)

If this turns out to fix the issue I don’t know if what I have been seeing would be a separate one to what @bar is working on, or if it just is the issue and others have not had such a pathological case of it.

Side note, with fixed point numbers on 24bit integer for the uController, we should have sub micrometer precision for a 24’ working area (12’+/-). Are arcs that sensitive in gcode?

Michael

1 Like

There are two different flavours of G2 / G3 - the one that uses I J K should absolutely be supported.

The other form is evil, and even the NIST spec for GCode does not recommend it.

1 Like

@md8n ahh, well FreeCAD does throw a lot of curve balls so the wacky gcode you saw sounds on brand. Thanks for showing the ncviewer and helping with looking through the code, I had not seen your update until after messing with FreeCAD.

1 Like

Might be worth try Ondsel. I was picking up freeCAD and stumbled across it. Seems like it might be a better fork of the same project.

1 Like

Michael Barrow wrote:

Hmm… The G2 / G3 not being supported on fluidNC seems like it could be the culprit.

There are at least two variations of the arc codes.

when you go through the CAM step, what type of machine do you tell it that you
have? you should look for GRBL if it’s there.

I have generated some linear gcode from FreeCAD which can be done without messing with the postprocessor using the flag “split arcs” for path/CAM operations (not that anyone seems keen on FreeCAD, fair enough).

That has no G2 or G3 codes in and I can try it next weekend. Here is the linear code in case anyone has the time to verify we are bumping into that
sheet1.ngc (411.9 KB)

If this turns out to fix the issue I don’t know if what I have been seeing would be a separate one to what @bar is working on, or if it just is the issue and others have not had such a pathological case of it.

Side note, with fixed point numbers on 24bit integer for the uController, we should have sub micrometer precision for a 24’ working area (12’+/-). Are arcs that sensitive in gcode?

I don’t think it does fixed point numbers, I’m pretty sure it does double
precision floating point.

and yes, arc can be that sensitive (among other things, if the start and end are
the “same point”, the gcode specs say that you are asking to cut a full circle,
if they are off by enough for it to notice, you but a very tiny arc instead.

Too many CAM programs create a TON of little tiny movements. This is one of the
things that gcodeclean looks for and cleans up.

David Lang

1 Like

I was able to look at this a little this weekend.
Had a power cut before I could test gcode clean version of the original.

However I had success with a minimal job including the problem arc, but rotated 180 degrees (attached).

Summary:
1 Original job with G2 and G3: crashes on first arc
2 Original job with G2 and G3 removed (linear): crashes on first arc
3 Original job, gcode clean version: Inconclusive due to power failure before arc reached

4 Simplified job with arc orientation mirrored, G2 and G3 removed: does not crash
sheet1.ngc (115.8 KB)

@bar, @dlang If there is some known problem with version 0.7X firmware crashing, pretty sure that 1 and 2 will reproduce it quickly. Only conclusion I can draw right now is that the arc in my jobs can be cut depending on orientation / location, which is very weird.

2 Likes