"The motion command has an invalid target" despite using updated Fusion 360 postprocessor

I created some g-code using Fusion 360 and tried to run it. It starts out OK but then stops after the first depth of the first operation (facing) with the error message shown on the screenshot.

I searched for that message here on the forum and found these:

So I downloaded the latest carbide3d.cps file from https://cam.autodesk.com/hsmposts (It says last change was on 12/3/2019, MD5 I got for that file is 100890b4d1b1ee46fb74efb854c3fbdf). I installed it as a cloud post processor in Fusion 360 and regenerated the g-code. I compared the old and new output file and indeed I see a lot of changes like this:

-G1 Z16.7 F333.3
+G1 Z16.7 F333.33

-G1 Z16 F333.3
+G1 Z16 F333.33

So the new postprocessor seems to make a difference. However when I then run the new file, it stops and fails at exactly the same point.

The .nc file is attached here. As you can see in the screenshot it fails at line 126.

base top v5.nc (73.4 KB)

Try using the latest version of Carbide Motion, there’s a little more conditioning in there to help fix small arc errors. You’re a couple months out of date.


Thanks I’ll try that and report back. I thought I should check that but then I saw the “No Updates Available” message below the version number and thought I was all set.

Unfortunately the result is exactly the same with version 4.0.428.

Is there anything I can tweak in Fusion 360? Or can I hand-edit the .nc file or write a script to fix it up? What exactly is it unhappy about in that command shown in the screenshot?

I tried it with the output in Fusion 360 set to inches instead of mm as well, and it stops at the same line.

There’s a line in the post processor, around row 77 that you can change to add an additional decimal point to the output.

Original: var xyzFormat = createFormat({decimals:(unit == MM ? 3 : 4)});
Modified: var xyzFormat = createFormat({decimals:(unit == MM ? 4 : 5)});

You can then upload that to your cloud library or wherever you keep your posts.
You may also want to change the header information so that you can tell which post has been modified when you open it in Fusion. I used:

description = “Carbide 3D (Beta)”;
vendor = “C3D - Beta”;
(lines 13 and 14)

GRBL isn’t happy that the coordinates for the arc move aren’t mathematically perfect. The radius of the starting point from the center needs to be identical to the radius of the end point to the center point, to within the margin of error for floating point numbers. Solution is to export gcode with more precise coordinates.


Oh that cps file is JavaScript, who knew…

Unfortunately that also didn’t work. I made the change from 3/4 to 4/5 digits and regenerated the g-code and verified that the output contains an extra digit.

Carbide Motion stops at the exact same point again. In the screenshot below you can see that it’s indeed using 4 digits, where my earlier screenshot shows 3 digits.

BTW thanks a lot for your help Winston, I really appreciate it.

Hmm. This is perplexing. It’s one of those things that works fine 99.99% of the time, but sometimes you just have to shake up the box and pray to the gcode gods that it fixes itself. Can you try changing the size of your lead-ins/outs (if you’re using them) by like 0.001, and also tweak the tolerance by a tiny tiny amount? Sometimes all it takes is nudging your fusion setup/toolpaths by a microscopic amount and the resulting gcode will end up being something completely different.

1 Like

Try a different sender.

What are my options? I didn’t realize I can drive the Nomad with anything but Carbide Motion.

It worked after I completely disabled the lead-in and lead-out of the facing operation. Fusion 360’s default was 0.3175 mm for the “vertical lead-in radius”. When I changed that to 0.3mm I got the same failure. When I completely disabled both the lead-in and out, it worked.


That’s a small lead in (.3175 mm = .012") , and it’s causing the helix to be uncalculatable at the precision that’s set in the GRBL settings - that’s a really tiny curve, and it’s really short. So short, the straight lines it calculates into are beyond the arc tolerance (a grbl setting) That isn’t usually the default lead in - increase it to something like .125" and it’ll likely work fine. This isn’t a post problem, it’s a bad parameters that might not be obvious, and the realities of approximating curves with small straight lines.


Interesting, thanks!

FWIW I did not pick this value. It was Fusion 360’s default. Looks like it’s

cutter diameter / 10

I tried with 3mm lead-in radius but that also failed, with a different error message:

A G2 or G3 arc was commanded but there are no XYZ axis words in the selected plane to trace the arc

It seems I really need to omit the lead-in of the facing operation completely.

There’s a list on the wiki.

I mainly use CNCjs and bCNC.

EDIT: I just ran the original file in “Check Mode” ($C) on both of those senders with no error.


Awesome, thanks for the check and the information!

Looks like I just need to ditch Carbide Motion. I got a second recommendation for CNCjs so I’ll try that.

In my understanding, that shouldn’t really matter here.

The error @liyanage is seeing has to do with miscalculated arcs or arcs with too low of a precision that they result in being outside the tolerance for this.
Here is the source for that error.
Basically, for that error to occur, the radius of the arc at the start and the radius of the arc at the end would have to differ by .005mm (AND be greater than 1% of the radius). In the original, less precise, version of the file he’s only off by .001mm (which is also less than 1% of the radius).
I wonder if Carbide Motion is doing its own check?

Let us know how it goes.

1 Like

Will note here that you mentioned ‘Nomad’ so there is probably some required reading before swapping to CNCJS or the like as the setup for tool probing is not an out of the box sort of thing.with this. Slightly worried you are looking for a quick and easy solution and changing senders with Nomad is a bit of a journey.

That’s very good to know about the tool length probing, thanks for the heads up.

I did quickly fire up CNCjs and played around with the UI a bit and what I saw so far looked great. I was able to jog the steppers around etc. right away.

I think we’re talking about the same thing - the arc tolerance which is by default set up as
$12=0.002 [Arc tolerance, mm]

Which is interesting given the code seems to be hard coded at .005mm