FYI, myself and others just looked into the Fusion360 problem with G2 and G3 arcs.
It turned out that this is indeed a bug in the Fusion360 source and/or a post processing file a lot of people use. Namely the Strooom/OpenBuilds version of the Grbl post that increases the precision of the arc values. From our limited testing, it looks like Fusion360’s default grbl post doesn’t produce G2 or G3 errors anymore. This may have been a recent development with Fusion360 ongoing updates.
In addition, we also narrowed Fusion360’s problems down to G18 and G19 arc planes, but not the typical G17 (XY) arc plane. When you actually look at the arc command, they are way off. The radius and the targets are not even close to lining up on the same arc, which indicates value precision has nothing to do with Fusion360’s problems. We suspect that it more has to do with their minimumChord and minimumRadius settings and how they are handled internally.
From what I can tell, arc error in Grbl occur when the arcs produced by a CAM program at very small and/or very short. The G2 and G3 arc g-code standard doesn’t really account for this very well and makes it easy to create a poor arc. While I can check for these situations inside Grbl and apply an internal fix, this only patches the overall problem and can lead to situations where Grbl isn’t sure how to trace the programmed arc. For example, the CAM program could have meant to program a full circle, but the arc is so poorly generated that the closest arc solution is a small arc. Another example is, if both the starting position and target positions don’t lie on the same arc, which do you choose to trace from or to? You end up with a step in the traced arc, not a smooth arc.
@jgreely : I just met some of the Vectric folks at MakerFaire a few months back. I’ll take a look at what is causing the problem and notify the right people at Vectric to see if they can fix the problem.