Gcodeman

Thank you for replying. I’ve found a few other forum posts here of people complaining about the same type of thing in regards to G2/G3 moves.

I’m hesitant to upgrade to the Edge firmware unless I know it’s stable & reliable enough for daily use. I don’t want to introduce other strange issues until I resolve my current issues 🙂

It seems like a lot of the occurrences about this issue happen under a combination of the same circumstances:

G2/G3 moves
Helical plunging
number rounding errors
large I & J values

I may have to try a combination of a few different fixes to see what works. I’ve only run into this issue on one of the projects I’ve cut out of a few dozen, but it’s frustrating that this is not a problem that I can proactively prevent from happening (save for the FW upgrade, perhaps).

I have compiled a list of strategies found in other threads on this form to maybe avoid this in the future:

Changes to toolpath generation:
-always stick with mm rather than Inches
-avoid helical-type plunges
-reduce use of toolpath smoothing in Fusion360 so G2/G3 moves are not created if not necessary.

Changes to post-processing:
-Force Fusion to create G1 codes in place of G2/G3. cut segments rather than curves
-modify the post-processor to not create counter-clockwise curves
-change post-process to always generate 3 decimal points on code
-Fusion has a setting for “USE RADIUS” which will generage G2/G3 lines with R values rather than I and J values.

hopefully this is useful to someone else having this issue