Fusion 360 for the Nomad

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.

@robgrz

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.

-Rob

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.

-Rob

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

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

-Rob

2 Likes

Rob,

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?

Thanks!!!

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.