Inventables Community Forum

Easel vs UGS (Easel non-support of Arcs)

I have noticed the faceted bends with my machine. At the moment I’m using Easel to send the g-code, but Fusion 360 and Aspire to generate. I’m curious if switching to UGS would improve this. I’ve never had Easel complain about G2 and G3, so I’m confused. I had been intending to switch to UGS for some time, just never got around to it.

Then you are probably not using any G2/G3 commands.

Use this post processor with Aspire and see if you get better results. Scroll down to the post processors.

ah, okay, maybe I should give it a try. I also see some Grbl updates. Does the X-controller need to have manual updates for grbl?

Depends on what you want to do. What version are you running now and does it do all that you want it to do?

I’m not sure, to be honest. It’s the latest version that would update through Easel. What can you gain from updates? I’d love to get a DRO of some kind. I’m just not sure if grbl is even capable of that.

I was under the impression that Easel as a gcode sender does not support arcs, so the Easel post processor for Fusion 360 does not generate arcs. I had looked at the Easel Local source code and it looked like every gcode that it can send is populated on the fly from the Inventables server. But I thought if you switched to UGS then you could switch to the generic GRBL post processor for Fusion 360 which would then generate using arcs.



If you know how to access grbl (machine inspector -> advanced, or UGCS) do a $I command to find the version number.

I’m just not in front of my machine at the moment.

I’m assuming the Vectric GRBL post processor posted above by Haldor also supports arcs?

Don’t know, but this one does. Scroll down to the post processors.

That is correct. Faceted X/Y coordinates only.

I use a PP provided by @Strooom to which result in arc commands from F360:

This is the entire output from my test file:

I understand that but what I haven’t grasped yet is why do a certain workflow provide a smoother drive.
So far I have only observed the difference. I´ll sleep on it, hope my head hurts less in the morning :wink:

GRBL’s default arc tolerance ($12), when fed a G2 or G3, is a 0.002mm chord length. The f360-easel.cps has a tolerance of 0.01mm.

1 Like

After all the comments, I’m still confused on how to get Easel to cut arcs using Fusion 360.

It’s really very simple Easel will not do anything with G2 and/or G3 (if in Easel design mode then Easel will generate straight line segments to approximate the curve) except return an error if it is asked to send a G2 and/or G3 command.

If you want to use Easel as your sending program the CAM program has to break arcs up into straight line segments. Controlling this behavior is in the realm of Fusion 360. Most CAM programs have to be told not to use G2 or G3 commands. This is done by choosing the correct post processor when you ask Fusion 360 to generate a toolpath (G-code file).

If you use UGCS you don’t have to worry about it you can just send the file. If grbl receives a G2 and/or G3 it will handle it. If the CAM program does not generate G2 and/or G3 then the CAM program will send straight line segments and grbl will handle it.

I understand why some people want to use Easel as their G-code sender, but I don’t really recommend it.

If you are still confused, speak up, I’ll try again.

What’s not working? Regardless of most of the above comments, your arc should still cut just fine whether you’re using Easel or not. You might get a smoother arc without Easel, but that will depend on your CAM settings as well.

When I create an object with arcs in F360 the machine creates a faceted curve. What postprocessor should I select to get a smooth curve?

@KenSmith - I think the confusing point here is even if you get a post processor to produce G2/G3 (arcs), the underlying software controlling the machine (grbl) does not support true arcs. Arcs will be turned into small line segments using $12 tolerance.

I’ve been using the “Open Hardware Desktop CNC” post processor with Fusion recently and it seems to generates arcs (though you can set the minimum chord length). However, I have had UGS return errors (assuming they are from grbl) saying the machine does not understand an arc command. It didn’t seem to affect the outcome, but not reassuring having the machine pause for no reason in the middle of an op. I have a screen shot on another computer I can upload for the curious souls.


You must be running a very old version of grbl. From version 0.9 forward grbl fully supports G2 and G3 commands and will draw an approximation of an arc when asked to do so.

If you should have a very large arc you will see some delay while grbl segments the arc into very short line segments to approximate the arc. One command to grbl.

If you let your CAM program break the arc up into hundreds and sometimes thousands of line segments which the sender must process then it becomes a matter of where you want your machine to spend its time.

Either wait for the G2/G3 to draw the entire arc with one command, or wait for the sender to send a huge number of line segments. It is selectable by the user with the Post Processor configuration.

I don’t know of any Cartesian co-ordinate machine that produces a true arc. Do you?

1 Like

Thank you for your research and help. When I get back into the shop after Thanksgiving I’ll try the Open Hardware post proc.