Fusion 360 for the Nomad

I’ll continue looking at the offset problem today. We’ll get it fixed.

I added G53 to the todo list. Shouldn’t be a problem after we get the current bugs sorted out.

Longer term, we’ll get G18 and G19 working

For what it’s worth, we use HSMWorks for our internal production. It’s a system that we’re familiar with and want to see working flawlessly.


Thanks Rob :slight_smile: I know this stuff isn’t easy!

If you’re using HSMworks internally, how are you editing your files to get them to run on the Nomad, if you’re doing that?

I tried outputting just the tool path shown above as it’s own post instead of outputting the whole job (the facing part first), and it complained about an undefined feed, so that’s another example of the post sending an implicitly passed value, and Carbide wanting an explicitly defined value. Also something to put in the hopper with the handling of implied/missing I & J values.

If you guys can get Carbide to handle helical and other lead-in/out moves, that’ll be fantastic.

We run our HSMWorks files on our Haas, not the Nomad (yet).

I’ll add the IJ to the Todo list.


Just uploaded a new CM V2 beta that works with Autodesk CAM.

  • Use the Mach3 post
  • Uncheck “Use Radius” in the post processor




So would you consider the Nomad 883 compatible with fusion 360 after that release?
I am just curious because I mainly use the fusion 360 SW and am looking to purchase a Nomad 883 (well pre-order), but compatibility with fusion 360 is important to me.

I noticed that Autodesk has many CAM partners, cam.autodesk.com
Does Carbide3D have any intentions of becoming a partner and ensuring software compatibility with the nomad 883 hardware?


Hi @mtpatane, I’ve been using Fusion360 and the integrated HSMworks CAM with my Nomad for the past few months and I can vouch that it works quite well!

Per Rob’s comment there, you’ll just want to post your tool-paths with the “Mach3” post and “use radius” un-checked, and everything else is pretty straight-out-of-the-box.

I’ll try to post some screenshots of my workflow and setups in the next few days when I have a chance. :relaxed:

Also, I can send you my HSM tool library I’ve drawn up for the Nomad if you’d like. It’s got some “starter” values plugged in for the tools, which you’ll need to adjust on a per-material basis, but it’ll get you off the ground.




That would be awesome! Looking forward to seeing those shots. I am looking to purchase one sometime this summer, so the tool data would be an awesome help as well.

Thanks for the reply!


Hey @UnionNine - I’ve been using fusion360 with the Nomad this past week and it seems to be basically compatible, except every once in a while a job will die with a grbl error: Invalid GCode ID: 33. I have been able to sometimes get it to go away by changing something about the milling operation that changes the toolpath a little bit (like, once I changed a parallel pass to go from “upmilling only” to “both up and downmilling”, and once I changed the transitions from smooth to straight-line, and in both cases the slight changes in toolpaths got rid of the error).

But I was wondering if you (or @chamnit) knew what in particular in fusion360’s toolpaths were tickling this particular bug and if there was a setting I could set or avoid in fusion360 to avoid it (like, I dunno, maybe I should avoid all helical ramping or avoid all smooth transitions or something like that).

1 Like

Error ID 33 is caused by an invalid target for a G2/3 arc command or a G38.x probe command. I’m guessing it the arcs and helical motions fusion generates. Typically these errors come from radius mode arcs, but the error bounds are fairly generous. Try having Fusion export IJK offset mode arcs, 90deg radius mode arcs, or arcs as G1 motion, if possible. If you have a test program that i can check out, I’ll take a peek to see if it’s a bug in Grbl’s parser error checking.

1 Like

@chamnit: I was trying to get a smaller program that exhibited the bug but I fixed the short ones. This one is failing, but it takes a long time (like 30 minutes to get to the fault).

It fails at I think 76% done in carbinemotion

edit: I don’t know how to do any of those things in fusion360 (ijk offset mode arcs, 90 radius mode arcs, etc.). Maybe somebody else ( @UnionNine ?) can give me pointers on that? I can’t find it as options in the post processor or elsewhere, but I’m basically 100% brand new to machining as of ~2 weeks ago :slight_smile:

Hey, so I looked at my gcode, and I don’t see an issue with it.

I do have one set of lines where the radius changes by 14% (!):

G1 X5.9717 Y0.9165
G3 X5.9724 Y0.9145 I0.0006 J-0.001

startradius: 0.00116619037897 inches
endradius: 0.00100498756211 inches

but if I’m reading your code right, it should not trip this:

        if (delta_r > 0.005) { 
          if (delta_r > 0.5) { FAIL(STATUS_GCODE_INVALID_TARGET); } // [Arc definition error] > 0.5mm
          if (delta_r > (0.001*gc_block.values.r)) { FAIL(STATUS_GCODE_INVALID_TARGET); } // [Arc definition error] > 0.005mm AND 0.1% radius

since delta_r is smaller than .005mm (It is .000161 inches or 0.0040894 mm).

There are many other places where delta_r is > .1% radius but none where the delta_r is also >.005mm.

Only other place I can see where you throw STATUS_GCODE_INVALID_TARGET (which I believe is Invalid GCode ID: 33? My coding is pretty rusty…) is if the target and current positions are the same, but I don’t see that anywhere either (smallest movement is by .0004 inches or 0.01 mm), and in any case, looks like that’s a different mode anyway (G2 and G3 with Radius parameter, or G38 codes, neither of which are in my gcode.)

Kind of stumped. Maybe tomorrow I will replace that 14% radius change arc with a G1 just to see what happens since it’s so tiny anyway…

Hi @kjl, Which post-processor are you using on the export? I would recommend Mach3, with the “use Radius” set to “no” to force it to use the IJK arc notation. I haven’t had any errors with Mach3 posts yet, so I’d be curious what you’re exporting the code as.

Yikes @mtpatane, didn’t mean to leave you hanging on screenshots and workflow. I think at the time I probably was doing client-work and thinking “I’ll get a personal project in here to show…” but just didn’t get there in a timely fashion.

Here’s my current tool-library—with the caveat that feeds & speeds WILL NEED ADJUSTING based on the material you’re cutting, the size of your tool, etc… to get to the right chip-load. These defaults are based on what I’ve been cutting lately, so you’ll need to still run the numbers for yourself.

The error checking for G2/3 arc is directly from the LinuxCNC g-code description, so if Fusion360 supports LinuxCNC, it should support Grbl. That said, I ran your program in $C check mode (Arduino 1.6.4 and Grbl v0.9i) via Grbl’s Python streaming script. I searched the output and found no errors related to arcs. Only errors related to unsupported M9 and H3 g-codes.

I’m not sure if there is something going on between when Carbide sends the program and Grbl receives it or if something else. Are you doing any feed holds or pauses to the program as its running?

Hey @UnionNine; yeah I was following Rob’s instructions; using the mach3mill post processor with G28 and useRadius turned off.

No feed holds or pauses at all; I just loaded the program in carbidemotion and hit go and stared intently.

When a job triggers the Code:33 error, it is 100% reproduceable and always happens in the same spot…

Hi, I just spent some time narrowing down what causes my job to fail and got a super tiny example:

It’s basically just 3 moves:

G0 X1.5548 Y2.4386
G1 Z0.5 F60.
G3 X1.5616 Y2.474 I-0.0076 J0.0197

Not sure why it’s failing - the delta_r is 0.0001885951 inches, or 0.00479031554 mm, so it shouldn’t trigger the error, correct? It’s close, however, and the delta_r is > .1% of the original radius, which means it would throw the error if it entered the “if delta_r>.005” block.

I wonder if there is some precision error, maybe converting from inches to mm or something similar?

Can anybody else can try running this program if they get a chance to see if they also get an error? It should take just a few seconds (the program doesn’t even home or prompt for tool change - it just goes to ~1.5,2.4,0.5 and then does a single arc).

I just tried it, and it did not throw an error. I connected through a serial terminal and manually sent these lines. Can you tell me the Grbl build date you have on your machine? A '$i` command will have Grbl spit it out.

Sure; where do I put this ‘$i’ command? I have to wait until tonight when I get home to do it, though.

So, you said you manually sent the lines and got no error? I wonder if it is elsewhere then. @robgrz wrote earlier: “We rewrite all of the gcode on the fly as it goes down to the GRBL processor” - I wonder if some precision error is happening or something else is getting garbled there…

I wonder if getting fusion360 to write out in mm instead of inches might help…

Not sure how to do it in Carbide Motion. Perhaps MDI mode and show the log? If you connect to Grbl directly with a serial terminal program or another GUI like Universal G-code Sender, you can send Grbl the $i command and it’ll spit out the build version and date. I ask only if you happen to be using an old version that has a bug, but I don’t recall recently that has this issue. So, it’s probably not Grbl.

My guess is that it’s more likely something to do with the conversion from CarbideMotion to Grbl that is slightly tweaking the value. Just enough to cause this error, since you are right on the threshold.

Changing to mm from inches will probably help, since mm is standard unit of measure internally for most of these programs. Grbl included.