More g2, g3, g38.2 error fun (somehow)

I’ve been having a greeeeat night with this. See below

Yesterday: Generated .nc file “A” from Fusion 360 using the latest .cps file for Carbide 3D from their website (
Runs fine on Nomad 883 classic (SN 00003) with Carbide Motion 416

Today: Generated .nc file “B” (a slight modification of A) from F360 and the exact same .cps and post processing settings
I get the dreaded g2, g3, g38.2 error

The machine has not been updated, Carbine create has not been updated the only difference is the file, so I loaded up file A (the exact file that ran perfectly yesterday). Hit in the face with the same error, from a known working combination of inputs.
I’ve tried tweaking the post processing settings in Fusion, switching between mm and in and all the anecdotal hacks from before this issue was “fixed” to no avail.

The only lead I have is that the .cps config file has a copyright date of 2018, despite the Autodesk change log showing changes into 2019. Is it possible I somehow have an outdated .cps from them?, even though that .cps had no issues generating a working .nc file yesterday.

I am genuinely at a loss as this seems to defy all troubleshooting logic.

Random thoughts, sorry if they don’t help much:

  • it seems possible that the problem was there even in the original A file ? If I understand correctly, this g2/g3/g38.2 problem relates coordinates precision down to the very last decimal, and how GRBL deals with them. The generated G-code uses relative coordinates, but internally it may make use of absolute machine coordinates, and if it does, a very subtle change in the (absolute) start position may induce a slightly different rounding error, which may sometimes lead to the problem, and other times not. I have no idea if this is the case, but I have seen weirder occurrences of the butterfly effect (a minute change in initial conditions leading to a very different behavior of the SW)
  • If I were you, I would first go and try to prove whether fusion actually uses the post file I think it is. And to do that, I would hack the CPS file and add one custom comment line of mine in there, and see if it shows up in the generated G-code file. For example, add a writeln(“CHECKME”) statement in the onClose command in the carbide3D.cps file:

function onClose() {

writeRetract(Z); // retract

writeRetract(X, Y);

writeBlock(mFormat.format(30)); // stop program, spindle stop, coolant off

  • Once you have proved that it uses the right cps file, triple check whether the content of carbide3D.cps matches the latest one from the site
  • If all else fails, kindly ask @wmoy to look into it !

I have a feeling that first thought would be most likely, I hadn’t considered starting conditions messing with the machine’s internal coordinate system. It seems weird that I hit the “correct” conditions several times in a row, and only once tonight (right after I posted, and then nothing for ~10 attempts). Perhaps some files can be more susceptible than others?
I started diving down the rabbit hole of using UGS or another alternative, but I’d prefer to stick with the standard Carbide Motion that I’d been using a few months prior without issue.

I also made sure to wipe my system of any other matching .cps files and made a modification to double check that the right one was being used during the post.
My current solution is to try and downgrade the machine’s firmware to before this whole g2 g3 error started occurring. A functioning, less capable machine is worth much more to me than a hypothetical more advanced machine.

Edit: also checked with Carbide Motion V3, no change.

Please send this in to us at — we’ll do our best to loop in @chamnit and see if there’s one final adjustment which is needed.

Note that you can test such files by putting Grbl into Check mode (machine processes file but doesn’t move) by sending


(send it again to exit Check mode)

1 Like

The G2 and G3 error is due to how the g-code is defined. It is horribly posed in a mathematical sense and is prone to solutions that dramatically differ in certain conditions. Notably, very short arcs with large radii.

However, the only CAM package that Grbl has had problems with is Fusion360. It has been working fine with every other CAM program, except this one.

A few years ago, I did a deep dive looking into what was causing this problem. It turned out to be a bug in how Fusion360 computed their arc commands. If you try to compute them by hand, they are totally wrong. It sounds like they never fixed the problem. The typical solution has been to not use arcs. You can alter the post-processor and force a CAM to output only G1 commands and avoid G2/G3 arcs.


I just checked a program I used recently and I had g2 and g3 in there without issues.
(f360 generated with carbide grbl post)

g38.2 however is no where in the code. also, cncjs is the sender, not carbide motion.

unsure if this helps, but something to note.

1 Like

@314159td Can you share the offending gcode?
I have used Fusion 360 (and Inventor HSM) for years and I’ve never seen that error.

CM won’t make a difference, and more so, you can’t use CM3 with a system that works with CM4 and vice versa - one works with GRBL 1.1, the other is .9. On top of that, there is really no good reason this should be sender related - none of them are translating g2/g3 commands that I know of, they just send them on.

If you downgrade firmware, know that you’ll need to reset a bunch of stuff in eeprom, which you would have had to have done on the upgrade too (you did this, right?) . Remember, CM3 only works with grbl .9, and cm4 only works with 1.1+.

Beyond that - the Fusion360 GRBL cps isn’t awesome, latest or not. Have you tried another one, like ?

What do you have the chord/radius parameters in Fusion360 set to - are they too small or too large? (5.5 KB)


Just ran a test using that post processor and didn’t seem to have any issues other than incorrect speeds and no tool changes (as expected), so that narrows it down to the post processor being the current issue (edit: all the settings shared between the two were the same as well). I’m starting to think Autodesk might have actually uploaded an outdated .cps file by accident. Does anybody have a known working post processing .cps file for the Nomad they’d be willing to share?

Thanks for the help so far!

1 Like

@314159td Why would the speeds be different with a different post? I use a modified version of the default grbl post. Can’t see why it wouldn’t work on a Nomad.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.