Fusion 360 for the Nomad

I haven’t tried it. I don’t understand all the issues, but I think the Fusion 360 folks are receptive to making a post processor work with Nomad.


I’ve tried a couple of Shapeoko 3 specific post processors, but still get this error when I try and load the job “Bad Arc Format, No I/J”. I’ve tried mach3 and grbl, but don’t have any post processor options in fusion 360 for Mac.

  1. feature request : show the offending g-code command whenever there is an error.
  2. any ideas on how to get some working g-code from fusion 360 Mac and carbide motion?


I’m also getting the No I/J error code.

Here is the two lines of GCode that are a problem:

I’m using the Carbide 3D Post process from the Autodesk link above. If I take the lines 127 and 128 out and load the GCode again to Carbide Motion, it loads fine. I ran the code on air and it seems to be doing the right thing. Any idea if this code is anything I should worry about. Experimenting with different options in the Post Process export pane to see if I can find out what option is writing this code. I like the way Fusion 360 allows me to design my tool paths and strategy. Here is the test piece I’m working on to test CAM in Fusion 360.

…those lines look legal (I think; I’m still new to this). Looks like it’s just trying to draw a circle, I assume at the bottom of the helix. Does it work if you append J0.000 to those 2 lines?


X-1.508 I-1.508 J0,000
X1.508 I1.508 J0,000


BTW, I don’t know what material you’re cutting into, but that toolpath will almost certainly not work (you’ll be trying to eat away 1/2" of material at once after the initial helix plunge, which the Nomad probably can’t do. You should try using the Pocket operation instead of the Adaptive one - it makes much more reasonable paths for the Nomad.

1 Like

I was going to try it with a scrap of wood I have. Haven’t done it yet though. Yes, after I posted this I had the same thought about the depth. It is 15mm. It drills a center hole and then starts the spiral. It might be ok but I also had my doubts. I have revised the path and now it does it in three separate depths of 5mm each. I will try adding the code that you suggest and also looking into pocket clearing and not adaptive but if memory serves well looks the same but with square paths as opposed to round ones. Thanks for the feedback.

1 Like

Yikes, that still sounds very aggressive to me (another newbie). You ought to check out a trial copy of GWizard from CNCcookbook. The trial period is pretty long, and I was able to get a 3 year subscription for $79. It has taught me a lot and comes w/ a Nomad machine definition. I consider it well worth the $79.

Yeah there’s no way you’re going to be able to do 5mm at once in wood. What I did to get my various settings in fusion was go through the carbide auto toolpath wizard thing in MechCam and then write down all the settings that it generates. You can peek at the gcode it generates to see the spindle feed, and then plug all that stuff into fusion as a good starting place, and then tweak from there once you get a better idea of what’s going on.

Iirc stepdown for wood is something like 1mm…

Did anyone tried 5mm stepdown? : ) If so what are yours feedrates for hardwood?

I want to try it as well just to check if nomad and mill can handle it without any cooling.
These are my settings
(0.005’’ chip load * 2 flutes) * 7500 = 75 ipm (1.9 meters per min)

I am new in this as well and trying to experiment and see the limits.
Should I try to mill a soap bar before hardwood? : )

That’s too much feed. It would require the spinde about 137.5W to cut at this rate. However, Nomad’s spindle power is only 50W. Try 10000 RPM and 27.25 IPM and you should be good removing 5mm of stock. I’m assuming you’re using 1/8 in end mills.
I suggest you download GWizard tool to compute feeds and RPMs for diffferent materials on your machine. I’m also a noobie but once I downloaded the trial, I’m learning a lot about the capabilities the machine can handle. And the machine is doing very well since then.

I like GWizard now. thanks.

So I see a new “Generic Carbide 3D (Grbl)” Post Configuration option on the latest download of HSMXpress for SolidWorks. Awesome! Anyone use it yet? If so, how did it work for you?

I use one in the Fusion360. It works:)

1 Like

I second that, I’ve been using it since I saw it a while back, and before that the Mach3 post worked with a few minor things to pay attention to.

Hi Rob - Sorry to pop in here, but this is where all of my error searches bring me. I am having all sorts of errors when running the Carbide Post files from Fusion 360 to the shapeoko xxl. I am using all stock firmware, etc. and newest Carbide Motion. I am now getting error error in line _ bad arc format, no I/J after editing the gcode (deleting lines prior to when it just stopped for no reason and screen didn’t give error. I paused and resumed, it cut for another inch then stalled and I couldn’t get going again with only pause / resume in carbide create. Any help would be greatly appreciated as I’m worried all of these posts are from 2 years ago! Thanks!

Another possible cause (esp. if using AutoDesk Fusion 360) is inaccurate conversion from Imperial to metric — convert project to metric, then do CAM in metric, then send a metric G-code file to Grbl. Seems to be an accuracy or calculation problem.

and that last is footnoted from:

or you may want to adjust other settings:

List of post-processors at: Post Library for Autodesk Fusion 360 | Autodesk Fusion 360

1 Like

Well having been a part time CNC programmer for many many years and professor, I try to teach my students about the problems of trying to cut a program into pieces. The problem is 2-fold, 1) Modal switches and 2) look ahead features. The easiest solution, DON’T do it. Just re-run the program.

If you are getting errors, go back into F360, and during the post, uncheck allow helical and curve moves. G33 Error: Watch the min radius setting in the operation, as WELL as the min rad setting in the post.

If this sounds all Greek, then it’s time to step up the training. Time to watch some training videos (YouTube).


Hi William,
Thank you for the very detailed synopsis!
I have been making sure I was in mm already but will try some of the settings recommended for min. radius, etc. Hopefully it’s something to do with that! Have a great weekend!

Hi Rich - got it! I get the jist of what you’re recommending to check/do. I haven’t played with the min rad settings in both the front or post end. If trying to use your idea of " during the post, uncheck allow helical and curve moves", Does it affect the quality of final operation or just increase the gcode because it’s sending alot more code to make those moves? Thanks again!

No, quality decrease at all and it’s what I use everyday.

1 Like

I just posted this in another thread. Repeated here for reference.

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.

I also fully agree with @RichCournoyer about arcs, if you are running into problems. Just disable the helical and arc motions in the post options. It’ll prevent Fusion360 from using G2 and G3 arcs altogether. FWIW, these types of “arc-disabling” options are there primarily for this exact problem. G2 and G3 arcs are so poorly mathematically posed that very small differences between CAM programs and machine controllers can throw errors. Most seasoned machinists just avoid G2/G3 arcs, unless they know for sure that their CAM and controller like each other.