Fusion 360 for the Nomad

I’m a little worried that I can’t use my own CAM with the Nomad, despite the advertisement of “If you have a favorite CAM program and work flow The Nomad 883 will work with it. Carbide Motion can read gcode from any CAM program so you’ll never be locked into proprietary software.”

Specifically, has anyone generated g-code for the Nomad 883 from Fusion 360’s CAM workspace?

Shooting in the dark, I’ve tried mach3, grbl, Generic EMC, and haas. None have worked. I receive “Error in line 3: Unsupported G Code.”

Ed Ford mentioned in another post that the Mach3 and LinuxCNC post processors are similar to the Nomad, because they are both based on the NIST RS274/NGC standard.

Unfortunately, I read at CNCzone.com that implementers of the NIST RS274G standard often want their own extensions and those extensions make the code incompatible across other machines. For example, Mach3, while based on NIST RS274G, may not work with Nomad, also based on NIST RS274G, because the extensions are different.

Any corrections to this information? Suggestions? Solutions?

1 Like

Can the g code be edited to allow for use with the Nomad 883?

Using a simple example of a small cube, the Mach3 option from Fusion 360 CAM workspace provides the following g code:

(T1 D=0.0625 CR=0. - ZMIN=-0.02 - FLAT END MILL)
G90 G94 G91.1 G40 G49 G17
G28 G91 Z0.

T1 M6
S12000 M3
G0 X-3.602 Y1.9687
G43 Z0.6 H1
G1 Z0.005 F20.2
Z0.001 F8.
X-3.6801 Z-0.0004
G2 X-3.9063 Y2.1949 Z-0.0066 R0.2261
G1 Y2.3917 Z-0.01
Y2.5886 F20.2
G2 X-3.6801 Y2.8147 R0.2261
G1 X-3.4754
G2 X-3.2493 Y2.5886 R0.2261
G1 Y2.1949
G2 X-3.4754 Y1.9687 R0.2261
G1 X-3.6801
G2 X-3.9063 Y2.1949 R0.2261
G1 Y2.3917
Y2.5886 Z-0.0134 F8.
G2 X-3.8887 Y2.6759 Z-0.015 R0.2261
X-3.6801 Y2.8147 R0.2261 F20.2
G1 X-3.4754
G2 X-3.2493 Y2.5886 R0.2261
G1 Y2.1949
G2 X-3.4754 Y1.9687 R0.2261
G1 X-3.6801
G2 X-3.9063 Y2.1949 R0.2261
G1 Y2.5886
G2 X-3.8887 Y2.6759 R0.2261
X-3.6801 Y2.8147 Z-0.0196 R0.2261 F8.
G1 X-3.6593 Z-0.02
X-3.4754 F20.2
G2 X-3.2493 Y2.5886 R0.2261
G1 Y2.1949
G2 X-3.4754 Y1.9687 R0.2261
G1 X-3.6801
G2 X-3.9063 Y2.1949 R0.2261
G1 Y2.5886
G2 X-3.6801 Y2.8147 R0.2261
G1 X-3.6593
G0 Z0.6

G28 G91 Z0.
G28 X0. Y0.

Carbide Motion does not like the following excerpted lines of Mach3 g code generated by Fusion 360 CAM:





However, when I alter the code to reflect the following, Carbide Motion accepted the g code:

G90G94G91.1G40G49G17 > G90G17


G43Z0.25H1 > DELETED


Unfortunately, when I ran the program, the cutter zoomed off to the left and cut into the tool measuring probe, leaving a nasty scar.

Let this be a warning to anyone considering messing with g code. Though, perhaps the code was not the issue. It should be noted that I’m unsure if the work coordinate system was set up correctly—the machine may have been attempting to go to a zero point I said to be somewhere off to the far left of the probe.

Is it possible to get a G-code/M-code list so we can see what is supported by Carbide Motion?

It would be very helpful for trying to choose or edit post processors generated by our preferred CAM software.

AIUI, this uses Grbl. See http://www.shapeoko.com/wiki/index.php/G-Code#G-code_supported_by_Grbl and the following section.

We rewrite all of the gcode on the fly as it goes down to the GRBL processor so I can try to make changes to get your example working as is.

We have anew version of Carbide Motion being tested now so I’ll see if I can get it worked in before release.


That would be great Rob. I use Fusion 360 as my CAD, so time to times would be nice to use it’s CAM capabilities.


I’ve made the changes to Carbide Motion to take your gcode except for the G28 command. I believe the post process section of Fusion should have a “Use G28” option that can be unselected. If not, I can add it at a later point but it was just a little more code than I wanted to add right now.

If the rest of the testing is good, I’ll post a beta of Carbide Motion 2 on Monday.

What post processor did you use in Fusion to generate that code?


Thanks so much for working on that, Rob!

I used the Mach 3 post processor.

Looking forward to Carbide Motion 2.

I ran a file through HSMxpress using the Generic Grbl post option, and it included this line:

G28 G91 Z0

Which according to Carbide Motion is “Unsupported G-code” so should I remove that line and carry on, or would you recommend a different post option?

I’ll see if I can un-check something similar to the folks using Fusion if I can.

Well, I tried just deleting that line, then got another post-error in line 792 of my program:

“Bad Arc Format, No I/J”

I will mention I’m using Carbide Motion 2 beta, btw.

@robgrz and also, when using the Mach 3 post option, I got an error in line 19:

“Bad Arc Format, R Not Supported”

I’d really like to use the toolpath options from HSMxpress from Solidworks, so would appreciate some posting guidance :slight_smile:

When posting the code:

  1. Uncheck “Use G28”
  2. Uncheck “UseRadius”

Let me know if that works.


1 Like

I had unchecked both of those, but still getting problems because of the dropped I/J variables—when the value is zero it seems the post-processor doesn’t write it.

Also, I discovered that I can’t use lead-in/lead-out moves, and that’s what the whole G17/G18/G19 thing was about. If I get rid of the lead-ins and helical ramping, etc. it will take the file, however at the end of the program I get a G53 still, so I had to delete that out, then Carbide would take it.

About to try my tool paths from HSMxpress to see how they go. I’m concerned about the tool-change working correctly b/c of the tool-length sensor/tool-length definitions potentially conflicting.

I’ll keep you posted as to if this works.


Well, that was disappointing. It successfully went through the first tool and completed a facing operation, paused, and then came up for tool-change when I clicked resume. Once I changed the tool out it homed, checked tool length then went out over the center, fired up the spindle and started plunging, not in the right location at all, on any axis, and crashed into the spoil-board. Here’s the NC file prepped with the Mach3 settings for you to look at.

Here’s what the tool paths look like in HSMxpress:

And here’s what’s gone on in the machine:

So I’m not sure why it’s off… and not just on the Z axis.

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?