Help Fusion & GRBL be happy friends

[mslatem]

First up - Kudos to the Entire Fusion Team for not only making an Awesome product, but building and nurturing what I consider probably the best community and engagement ecosystem around a product I have ever seen. Other companies take note, this should be the standard of "how it should be"

I am using GRBL (0.9i) and been spending a lot of time learning Fusion 360 with the intent of making it my only go to product for CAD/CAM and making cool stuff on my CNC router. I think there are/will be a lot of GRBL users attracted to Fusion 360 as its simply the best consolidated period. I would like to get the Fusion post processor mature for GRBL that is 100% reliable and performs similarly to other packages I have used. There are a couple of issues I have noticed with the default grbl.cps included with Fusion 360:

1. Spindle does not Turn off automatically at the end of a Job
2. Certain helical or arc geometries do not maintain a constant velocity and movements become slow and erratic. This does not effect the accuracy of the part but is particulalrly problematic when cutting acrylics that expect a high feed rate and when the spindle feed decides to slow down to 30% you can land up with melted material etc.

I have resolved issue 1 by using a Custom postprocessor that output M5 command at the end of the job to stop the spindle adapted from a forum post here by a user with the same issue.

The second issue I can not seem to solve - I have even tried to use the posted "carbide3d.cps" mentioned in these forums but does not seem to help.

I have attached both the customized postprocessor I am currenly using as well as the Fusion outputed gcode that I am using. There is also an image attached that shows the problem areas and the part I am cutting.

There may be something obvious that I am missing somewhere which is plausible. However I have not seen these issues with any gcode outputed and run on the same machine with Vectric Vcarve Pro and Cambam - so I am hoping its as simple as a unticked checkbox somewhere 😉

Lastly would someone be kind enough to direct me to a document that explains the post process proeprties as shown below and if perhaps the defaults set there are incorrect for GRBL based CNC machines?

Thanks in advance for the help 🙂

[HughesTooling]

The g code looks ok so I think it down to how fast the control can process the code. Looking at the g code you don't have arcs where it's slowing down, in the back plot below line moves are blue and arcs green.

Have you tried using smoothing so you get arc moves.

Does the control have a setting for constant contoring?.

Mark

[mslatem]

Hi there Mark, thanks for the reply.

I tried enabling smoothing for all the toolpaths, although it did considerably cut down the lines of gcode by 50% the problem is still there with significant slowdowns in those trouble spots.

In regards to your question about "constant contouring" I am not sure exactly what this means but GRBL controller does have built in "Constant accelaration management / look-ahead planner" Snippet from the website below: https://github.com/grbl/grbl/wiki

---------------

Acceleration management

In the early days, Arduino-based CNC controllers did not have acceleration planning and couldn't run at full speed without some kind of easing. Grbl’s constant acceleration-management with look ahead planner solved this issue and has been replicated everywhere in the micro controller CNC world, from Marlin to TinyG. Grbl intentionally uses a simpler constant acceleration model, which is more than adequate for home CNC use. Because of this, we were able to invest our time optimizing our planning algorithms and making sure motions are solid and reliable. When the installation of all the feature sets we think are critical are complete and no longer requires us to modify our planner to accommodate them, we intend to research and implement more-advanced motion control algorithms, which are usually reserved for machines only with very high feed rates (i.e. pick-and-place) or in production environments. Lastly, here's a link describing the basis of our high speed cornering algorithm so motions ease into the fastest feed rates and brake before sharp corners for fast yet jerk free operation.

--------------

The GRBL is generally pretty performant - It is written in optimized C to achieve precise timing and asynchronous operation. It is able to maintain more than 30kHz step rate and delivers a clean, jitter free stream of control pulses.

Any other suggestions?

[mslatem]

Btw I had a look at some previously generated GCODE from Cambam and Vectric vcarve pro and noticed that the post processor they are using for grbl outputs code entirely devoid of any use of G28 could this be the issue?

Sample file attached.

[HughesTooling]

The G28 shouldn't make any difference. Can you test the same part using Cambam and Fusion, it would be interesting to see if there are any obvious differences.

Here's a couple of screen shots of what I think is the problem area, the first shows a very short helical move, the next image show a line move. All around the ramp you have the same short helical move then a line, this might be whats causing your control problems.

The feed in the g code is constant so it must be the way the control is processing the g code. I don't know if there's a setting that will give all line moves for the ramp, that might be better than the short arcs and lines.

Mark

[mslatem]

hmmm very interesting - I really like your screenshots especially the ones where you have drilled down into the toolpaths and can click on each segment and get a label - what program are you using to view the toolpaths in such detail?

I would have to recreate the part in cambam to do a comparison - which I have not yet done. I have attached some gcode I made quickly from cambam cutting random shape toolpath at the same depth, feeds & speeds for comparison.

I have no idea why Fusion would be generating such an odd toolpath with very short helical move then a line move - it may indeed have something to do with the way I created the sketch or the settings for the toolpath - I have not deviated much from the defaults is there some other setting you reccomend I try?

I have now disabled the "ramp" and "lead in" moves which seems to make it considerably better. (gcode sample attached) 

Do you suggest I start playing with the high feedrate modes?

[HughesTooling]

Can you upload the Fusion file i'd like to experiment with it a bit, go to the model work space right click the top component and export as f3d file.

The viewer I'm using is called NC Corrector you can download it here

Mark.

[mslatem]

Sure - file attached

Thanks a ton

Mark

[HughesTooling]

There's something odd with the 2d contouring toolpath, without smoothing Fusion usually fits arc to 2d fillets but in your file that's not happening.  Some rads are there like this.

But the other corners are made of lots of small arcs and lines.

Constantly changing from arcs to lines might be what's slowing your feed rates.

I did a quick test on some simple rounded rectangles, one made adding fillets to a box the other by filleting a 2d sketch and extruding. Both of these converted to 1 arc for each corner, this is with smoothing off.

I don't know what's wrong in your file, perhaps someone from Autodesk should take a look.

All the way around you part you seem to get 1 short line move the 1 very short arc. Arc move shown in the red circle.

Perhaps  jeff.walters could take a look.

Mark

[HughesTooling]

How did you make the curve in the picture below. I edited your sketch and replaced part of the curve with lines, in the areas where I used lines the corner fillets came out as a single arc.

Mark.

[mslatem]

Hmmm - If I recall correctly I made that arc with the 3 point arc command namely: Sketch --> Arc --> 3 point Arc

Is there a better way to do this? How did you create the lines when you tried to emulate?

Thanks

Mark

[HughesTooling]

OK I figured out what's going on, when Fusion converts that curve into line segments it's trying to fit a rad to all the corners, like it would if you machine around the outside of a 90°  corner. If you turn off corner rounding and set it to Keep sharp corner then set you tolerance and smoothing to 0.015 you get a lot nicer toolpath.

The area where you where getting problems now looks like this.

I've had another look at you sketch and I think the curve that's causing the problems is a conic curve, for some reason the CAM is not doing a good job converting it to lines. Definitely one for the CAM team to look at.

Mark

[mslatem]

Mark, thanks so much for digging into this. I am glad its a reproducible quirk/bug.

Should I log some type of trouble ticket to alert the Fusion CAM team or do they monitor these forums and will see this by default?

I also wanted to ask you about the correlation of "machining time" when running a simulation vs "actual machining time" when run on a physical machine. I have run the below job on a physcial machine "aircut" and on a part as well as to a seperate GRBL arduino controller connected to another computer - in all 3 instances including after adjusting the corner rounding and smoothing values as per your screenshot/findings the actual Job run time is still over 6 minutes or nearly 3X slower than it should be.

Here is the actual Job sent to GRBL controller via Universal Gcode Sender

[HughesTooling]

The machining time in Fusion doesn't take acceleration and deceleration into account, I guess the screen grab from your control is taking your machine parameters into account. Is your machine using steppers or servos by the way. Here's a screen grab from Nc Corrector, it shows pretty much the same time as Fusion.

Hopefully someone from Autodesk will read this far and pick up on the problem, I mentioned jeff.walters in one of my posts. If I've done that right he should get an email about this thread.

Mark.

[jeff.walters]

The issue is that the fillet isn’t an arc for some reason. If I measure a different fillet I get Length, Radius, Diameter, and so on. But if I measure the fillet in question all I get is length. For some reason Fusion is creating what seems to be a spine instead of an arc.

Ill see if i can get one of the CAD experts to comment on this. 

[HughesTooling]

The fillets don't show as a rad if they are filleting the conic curve. I edited the file and replaced this part of the curve with a line and re-filleted then that part came out as one arc for each corner.

[joel.palioca]

Hello,

I have gone ahead and logged an issue to track the fillet issue, we will continue to look into what is happening.  As mentioned above it looks like recreating aspects of the line with the line command, or other sketch commands other than conic curve will provide the correct fillet results.

Cheers,

[mslatem]

Ok thank you very much 🙂

[Anonymous]

That looks like an awesome tool, but windows only?
do you know if there is a good Mac equivalent anywhere?

[scottmoyse]

---

@Anonymous wrote:
That looks like an awesome tool, but windows only?
do you know if there is a good Mac equivalent anywhere?

---

@Anonymous were you referring to the back plotter or Universal G Code sender? The back plotter is windows only, UGS is available on both platforms. Check out this post for details on a Mac tool for looking at posted code: http://nicholscornercam.blogspot.co.nz/2016/10/nc-editor-for-mac-users-currently-3.html