Fusion post processor YZ and XZ arcs

it is not hard to allow XZ and YZ arcs in the post, but the big question is how big are the arcs.
They were turned off because Fusion likes to generate very small arcs in those planes since it usually does them as lead-in and lead-out moves and the defaults are 0.1 x the bit diameter, so for small bits
the arcs are too small to be accurate enough and GRBL reports significant radius errors (radius to start and end of arc differ by too much - the numbers from Fusion are 'wrong', not a bug in the post).

so, open the .cps file in Notepad and edit the line

Code:

allowedCircularPlanes = (1 << PLANE_XY);// | (1 << PLANE_ZX) | (1 << PLANE_YZ); // only XY, ZX, and YZ planes

to be

Code:

allowedCircularPlanes = (1 << PLANE_XY)  | (1 << PLANE_ZX) | (1 << PLANE_YZ);

this will allow arcs in those planes BUT note that if 'linearizesmallarcs' is true, arcs with radius < bitradius will still be linearized.
You DO want this becasue those small arcs will have radius errors (because of the data coming from Fusion, not a post bug, I have spent hours/days trying to solve this!)
OR
you will have to run EVERY file through the controller in check mode ($C in serial console) before the cut if you want to avoid stoppages due to radius errors.
If check mode shows a radius error just convert the relevant line to a linear move and try again.

Another thing you can try is changing the 'tolerance' value from 0.01mm to 0.001mm but then you must turn smoothing off else it will have no effect on the moves generated.
Try this on a small job since such a low tolerance way make the code have such small moves it will take longer to run since the machine can never get up to the given feedrate.

and of course you can reduce the smoothing tolerance so the segments it generates are shorter.
note that a tolerance (linearization or smoothing) that is less than the minimum step distance of the machine is pointless. (usually 0.01mm for leadscrew machines)

if you send me your fusion file I will have a fiddle to see if these a arcs can be solved

 

I think I have a solution up my sleeve, will work on it over the weekend.

 

wow.

so, go and grab the master.zip from GitHub - OpenBuilds/OpenBuilds-Fusion360-Postprocessor: Post Processor for Fusion 360 for use with OpenBuilds Machines running Grbl 1.1 ...
green 'code' button, then 'download zip' (NOT the release!)
This is a beta of my latest solution to the arcs problem.
In this one

• all arc planes are allowed
• linearizesmallarcs still defaults to ON, you want it OFF for your case
• when linearizing is off, arcs with significantly different start and end radii will have a new center calculated which will be used for the Gcode.
• some additional stuff is also done, like making sure the center point Z lies between the start.Z and end.Z for helical moves (on XY plane, similarly for other planes), for some crazy reason Fusion does not give the center point as being midway between the start and end point in the helix direction, and when it is incorrect the radii are made MORE different giving false positives.

Let us know if it works for you.
If it doesn't, I need your Fusion drawing file, just export it as an f3d and upload it here or direct message it to me if you want it private.

 

@Jeffrey A Melius
have you had a chance to try it out?