Lets talk about ARCs and Circles

Bringing this topic into it’s own thread as it may benefit others who working with plastics and metals.

What I know so far:
1F uses the Buildbotics open-source controller which does not support ARCs. ARCs are converted to line segments by the controller, which obviously have a “resolution” as opposed to a true curved tool path. Short of changing controller, 1F has no realistic avenue to address this other than hope for Buildbotics to include ARC support in a future firmware release.

In the Settings screen, The Max-Deviation number dictates the allowed deviation from the true path the controller is allowed to make when converting ARCs to line segments. My machine was set to 0.05 out of the box.

Below are some tests I’m doing to find the ideal settings for my needs. I cut plastics so will be interesting to see how these numbers look in metals which will likely be more demanding.

4" Diameter ARC on XY Axis:

My “Benchy” for testing ARCs on Z axis:

I’m currently testing ARCs on all axis, so far the results don’t seem to be as predictable as the above tests. I’ll post some pics later on.

I’m sure there are other ways to work around this limitation. I’d be curious to find an ARC-to-Lines software that could possibly provide more control over the conversion.

Please share your results and settings you’ve found to work best for you.

5 Likes

Can you also post your code file …want to make sure that g2/g3 codes are being generated

I don’t think this is a Buildbotics issue. Correct me if I’m wrong, but their website shows G2+G3 arcs are supported. CAMotics

Here is the 4" Diameter Circle GCODE:

%
T1 (MSG, Insert Tool 1)
G0 G17 G21 G90 G40 G49
G0 Z5.334
G0 X0.000 Y0.000 M03 S16000
M0(MSG, Click ‘Continue’ when the spindle is up to speed)
G0 X0.000 Y52.388 Z5.080
G1 Z-6.350 F381.0
G3 X-52.388 Y0.000 I0.000 J-52.388 F1016.0
G3 X0.000 Y-52.388 I52.388 J0.000
G3 X52.388 Y0.000 I0.000 J52.388
G3 X0.000 Y52.388 I-52.388 J0.000
G0 Z5.080
M5
G0 Z5.334
G0 X0.000 Y0.000
M2

I think that’s an interpretation of the word “support”… G2/G3 is indeed supported buy the controller, as in it converts it to line segments and then cuts it within a certain accuracy. At least that is how I interpreted that.

1F support stated:The Onefinity controller cannot do arcs, it changes them into line segments. You can adjust the segments using the max-deviation in the settings page.

Buildbotics Documentation States:The ‘max-deviation’ entry box sets the Path Accuracy. This defines how much the Buildbotics Controller is allowed to round off corners and defines the maximum allowable deviation when interpolating arcs. Setting this number too low will cause the machine to run slowly. The default value is 0.1mm. This value can be overriden in GCode programs using the G61, G61.1, and G64 GCode commands.

2 Likes

This was my first “surprise” as I transitioned from my DIY CNC to the Onefinity, you can clearly see the difference running the same GCODE on both: (This was with “out of the box” settings)

Left: MPCNC with Marlin Firmware
Right: Onefinity with Buildbotics Firmware

4 Likes

@Techrise I can also confirm from 1F support that true G2/G3 ARC movements are not supported. Quotation from emails…Sam-“Also does the Onefinity controller itself support G2 commands (asked by fusion 360 help)?” 1F support-“G2 is not”

1 Like

OK so here’s today’s comparison, very happy with the new results!!

OneFinity “Out of the box” settings:
Max-Deviation: 0.05
Microsteps: 16

OneFinity Custom Settings:
Max-Deviation: 0.0005
Microsteps: 32
Z-Motor Max Velocity: 1m/min (Doing this due to some chattering on Z axis, may be unrelated to obtained results)

MPCNC/Marlin cutting a true ARC: (You can actually see the polygon resolution of the STL I’m using)

Really happy with these results! Some notes to keep in mind:

  • The 1F controller resets the Max-Deviation setting to 0.05 at reboot.
  • The Max-Deviation setting must be set before loading the GCODE as this is when the ARC conversion occurs.
7 Likes

In Fusion when creating an NC program there is the “built in” menu on the bottom right of the post processor menu. At the bottom of this menu is tolerance, it is default set at .002. I just created some new programs and set it at .0005.

I have been running my micro steps to 64 on the X and Y. My Z is set at 32. Everything else is stock settings for the motors

You work with aluminum right? How have your results been so far?

Could you post a snippet of the GCODE? Is it still generating G2/G3 commands or actually converting to line segments?

@Tuvix72 here is a screen shot of some generated GCODE I processed last night. G2/G3 commands including the I and J coordinates all generated.

1 Like

I have also taken a screen shot of the .NC program, post properties screen. The lower right hand section has the “built-in” properties menu. I have only made a change to the tolerance field from 0.002 to 0.0005. I haven’t had a chance to run this program yet.

I was also testing the output GCODE file size of the stock built-in settings of 0.002 VS my adjusted 0.0005 and the file sizes are larger with the finer setting :+1:

I’m not sure what effect we will see in changing the Tolerance or Max-Deviation in the software used to generate the GCODE as it is still generating G2/G3 commands, meaning that when you load the file into the 1F, it will be re-processed using the 1F Max-Deviation setting. I would imagine running the same number may be something to try.

This is where I’m experimenting the most:

2 Likes

@Tuvix72 My thinking is that a finer (.0005) max deviation setting in the controller won’t up-convert the lower resolution file of the coarser, built-in .002 post processor. I am thinking the max deviation setting will only down-convert or limit finer resolution files as it is a minimum/maximum (however a person wants to view it) setting. ie. 0.0005 programmed in post and max.dev setting of .005 would down-convert the finer post processed file too the controllers setting of .005 as this control setting threshold is violated by the finer program. Conversely a coarser .005 programmed post would remain that resolution if the setting in the controller was set at .0005 as the coarser .005 programmed file doesn’t violate the settings of the minimum/maximum threshold.

“My thinking is that a finer (.0005) max deviation setting in the controller won’t up-convert the lower resolution file of the coarser, built-in .002 post processor.”

But the post-processor is still generating G2/G3 arcs in the GCODE. The 1F controller is then going to convert those arcs (think vectors) to line segments (think raster) at the resolution set in Max-Deviation.

So when it comes to arcs, that last conversion to line segments is where the problems are introduced. The 1F controller does not modify or re-process linear code, so that resolution remains true to what the post processor generated.

Any way you can set your post processor to convert arcs to lines and generate a GCODE that requires no conversion by the 1F?

1 Like

Ahhh gotcha. You make a point there.

1 Like

Started to hit some limits in my testing…

When working with a Max-Deviation between 0.0005 and 0.0001, small radius arcs seem to exceed the stepper motor resolution, resulting in what I believe is a loss of torque as can be seen in this “air cutting” test done at 0.0001 Max-Deviation:

The same file loaded at 0.005 Max-Deviation:

Larger radius cuts and 3D carvings at 0.0001 have worked well but you need to keep an eye on the work as a tight radius may cause this and throw off the position of the tool as it continue to cut.

2 Likes