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.
1 Like
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.)
1 Like
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…
1 Like
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. 
1 Like
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.
1 Like
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.
Sure—I agree that it’s a Motion problem, just wanted to address your statement:
Or arcs involving the Z.
Because that felt misleading, as I am certainly doing effectively arc motion just fine 
1 Like
Yes, but providing Grbl with the actual arcs and allowing it to do movement planning should allow for better planning and smoother and faster movement.
1 Like
You are right Will! looking forward to the fix.
@WillAdams Actually, GRBL does a better job of planning if it doesn’t have to compute the segments, then the issue is just keeping the buffer full. In a pet project of mine (a new sender), I can input g-code with arcs and splines and it does the interpolation the same way grbl would and the machine seems very happy.
1 Like
So you pre-convert the arcs in the sender? Does that happen when your load the file or on the fly?
What kind of improvement in planning do you see?
When are we going to see this sender?
@neilferreri the sender has options per curve type that can be enabled to interpolate or send as is in the file. This way this sender can be used to support higher level g-code on multiple motion controllers.