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.
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.
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.”
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
@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”
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)
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 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
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.
@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?
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.
