Easel vs UGS (Easel non-support of Arcs)

This is no secret, just isn’t obvious or relevant to everyone.

I want to showcase this behaviour as I was doing a carve yesterday where this would have impact on surface trueness to design.

Easel do not support arcs so every curved line will be broken up into small straight segments
I made two blanks yesterday with an OD of 65mm, design in F360 and exported with a post processor for Easel and another for UGS.
Blanks are 3mm thick each (1/8")

For most projects this difference in handling dont matter, but in those cases where ultimate surface fidelity is desired, choosing the proper gcode sender do affect final result. UGS isn’t the only one that do support arc, but it is the only one I ran for comparison.



Easel will not generate Arc commands (G2 and G3). Easel considers G2 and G3 to be invalid G-code statements and will raise an error if you try to send a G-code file that contains G2 or G3 commands.

Arc support is controlled by the Post Processor of your CAM program (in your case Fusion 360).

If your Post Processor supports Arcs then your CAM program will generate G2 and G3 G-code commands and grbl will translate the Arc into straight line segments using the $12 grbl parameter to determine the Arc tolerance.

If your Post Processor does not support Arcs then the CAM program will translate the Arc to straight line segments with Arc tolerance determined by the Arc settings within that program and will send G1 commands to grbl to send the straight line segments to grbl.

1 Like

You know your stuff Larry so I am intrigued, inquiring mind want to know :slight_smile:

I have attached 3 gcode files, one Easel only (E2E) and the other two with Easel.cps (F360-Easel) and one that work well or me with UGS (F3609UGS).
All carves are set to full depth only for code simplicity.

Easel2Easel and F360-Easel will both only have G1 commands obviously.
F360-UGS accept G2/G3. All three carve the same part.

Will my UGS decode the G2/G3 into straight sections, based on $12 before machine output?
Why would it then be different than default Easel?

OD65mm_6mm_F360-UGS.nc (677 Bytes)
OD65mm6F_Easel2Easel.nc (1.8 KB)
OD65mm_6F_F360-Easel.nc (2.6 KB)

UGCS does not decode. Decode is done by grbl.

The 3 different .nc files are using 3 different post processors.

(OD65mm_6mm_F360-Easel.nc contains an error.)


Academic paper on this listed at: https://wiki.shapeoko.com/index.php/Books


1 Like

Okay, if each file gets decoded by GRBL why is the output (physical output) different?
If GRBL $12 define this level of resolution, it would apply to all?

Same shape, 3 files, 3PP’s was my intent / focus of my curiousity.
I am obviously missing something simple :wink:

As an analogy there are usually many different roads from one place to another. Depending on which roads you select, you have different routes to get to the same place.

When you generate the G-code via a CAM program there are many solutions to carve a design. It is the CAM program’s function to select a path to carve and it is usually affected by the Post Processor and the CAM program’s options that the user selects.

The only way to get matching G-code files for a particular design, you have to use the same CAM program with the same options and Post Processor.

$12 only comes into play if your CAM program produces G-code with G2 or G3 commands. When the sender program sends the G2 and/or G3 commands to grbl, $12 applies to all of them the same.

1 Like

well, I’m confused.

How, so?

Maybe I can say it a different way to clear things up.

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: