Uh, no new files there 
- I downloaded it 2x more after you posted (1) and (2) and it’s the same file:
e78a1464f738fbd50a7490f4af4d867e09e8bac153c6e93d4432597669949753 CarbideMotion-429 (1).dmg
e78a1464f738fbd50a7490f4af4d867e09e8bac153c6e93d4432597669949753 CarbideMotion-429 (2).dmg
e78a1464f738fbd50a7490f4af4d867e09e8bac153c6e93d4432597669949753 CarbideMotion-429.dmg
Try one more time, my mistake
Is that the same file you uploaded earlier?
No - it’s after I set smoothing and I also increased the lead-in distances. That’s all that changed though… per an email exchange with you guys.
Are you running a totally stock machine configuration? (No custom GRBL or custom settings)
Completely stock, just downloaded and installed and that’s it… defined machine itself in terms of ipm, rpm, work envelope etc…
I remember a comment about G19 plane changes for arcs being a factor. In lieu of lead in, try using a ramping move. Or try setting vertical lead in radius to zero, and only using horizontal. I can’t replicate your error on Shapeoko with your last 2 files. Will test on Nomad tomorrow.
Vertical lead-in radius set to zero fixes the problem so yeah… definitely a G19 plane change problem
Out of curiosity, can you provide the machine coordinates of where you’re zeroing to start the program? Wondering if the initial condition of the steppers and positional resolution may play a factor.
(Jog to your origin, then click on the “Position” label over the readout on the left.)
having a vertical lead in anywhere seems to do it on several different projects also.
From a bunch of different zero coordinates? I’ve been using both vertical and horizontal lead-ins for months without any issues. This is perplexing…
Well, having a vertical lead in radios that is non zero… all of the other lead in values seem to function as expected without error
Removing all lead in and out moves is exactly what I now always have to do, see my other thread:
Needless to say that is not a good permanent solution.
in checking back in, I still think I like the interim solution of disabling the PLANE_ZX and PLANE_YZ in my post the most, and have had no issues since 
Or arcs involving the Z. 
While searching I came across this discussion:
Anything relevant?
Pretty sure this one is a Motion issue, not a Fusion 360 or grbl issue. None of the trouble files here that I’ve tested cause issues with other senders. I have only seen those errors on this Forum, and I use Fusion 360 pretty regularly.
Actually, with this setting it just interpolates the arc motion to linear motion and gets on with it, and does lead-ins and outs just fine—albeit with larger gcode files. Not really a problem as far as I see it at the moment.
Sure they’re not “true” arcs, but with this kind of tool and equipment, doesn’t seem to cause any problems.
That’s what GRBL does on board anyway. I just think there’s something in Carbide Motion causing the errors. Some of us are ok modifying post processors…it might turn others away from Fusion.
