Fusion 360 for the Nomad

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.

-Jonathan

2 Likes

Jonathan,

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!

-Matt

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.

Yes, I agree; probably not grbl. I just got my nomad a little while ago, so all my software is ~1 month old.

I’m going to 1) switch to mm and, failing that 2) write a script to write out the IJ offsets so that they are “correct” and to more decimal places (if CarbideMotion/grbl even pay attention)

Hi; changing the output to mm from inches fixed my error (on my problematic job and 3 more as well)!

So: easy workaround but maybe something worth looking at inside CarbideMotion or elsewhere since the error was getting thrown on a G2 command that was technically legal (just very close to .005mm)

Another little mystery with “grbl error: Invalid GCode ID: 33” if you guys are interested ( @chamnit or @UnionNine … maybe @robgrz? ). I’ve worked around it so it’s not critical to me personally anymore, but… maybe you care?

I’ve run a whole bunch of Fusion360 jobs through successfully now (after posting in mm instead of inches) and this is the first issue I’ve had in maybe 20 jobs.

I have this job which dumps a “grbl error: Invalid GCode ID: 33” error somewhere between 1/3 and 1/2 job completion. All the arcs should be just fine (largest delta_r is .0014 mm, nowhere close to the .005mm which should trip the error). Here’s the file:

With my previous error job last month I was able to narrow it down by cutting away chunks of the GCode until I was left with just the 2-3 lines which caused the error, but in this case, the error was very nondeterministic. I would see that it crashed between 1/3 and 1/2 job completion, so I’d cut out most of everything else, and then I’d end up with a smaller job that would fail with the same error… but only sometimes - if I ran it again it might go through successfully. So I was unable to narrow it down very far. BTW it would be incredibly helpful if I could see the exact line that CarbideMotion/grbl was on when it croaked instead of having to eyeball the progress hexagon as guess that it was somewhere around 37% completion (and if you have a 10000 line program that only narrows it down to a hundred lines anyway).

I have a vague suspicion that it is possibly one of the G18 arcs (there are 9 in the file I believe). The G18 arcs (XZ plane arcs) are all smooth vertical lead-ins so it wasn’t critical that I kept them, so I replaced them all with G1 moves: the resulting file is here: (it’s identical to the previous file except for those 9 G18 lines) Dropbox - File Deleted . This job went through successfully with no errors. So it’s tempting to say that the G18 arcs were an issue… but then again this error was a little nondeterministic so maybe I’m wrong. I do have previous jobs with G18s that finished successfully, so I don’t know. Spooky!

To confirm the inches to mm fix.

Working in Fusion CAM, I encountered the same GRBL Error: Invalid gcode ID: 33. I made two mistakes:

  1. Forgot to uncheck G28
  2. Generated code using inches

To fix the error, I unchecked G28 and switched the units to mm before generating the code.

No more problems!

Proof of success:

1 Like

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.

http://forums.autodesk.com/t5/computer-aided-machining-cam/g-code-output-to-nomad-883/td-p/5498898/page/2