OK, I think I have a good grasp on G17, G18, G19. The question I have is that according to my test software, it appears that these only work right if I want the arcs to travel straight in the axis, like a channel in the Y axis (G18). If I want that channel to run at an angle, the depth of the cut gets shallow.. This gets worse the further I go toward the 45° mark. Is there a fix to this?
Arcs have to follow the plane to be true arcs, or you have to figure out the offsets yourself to create a true arc from untrue parameters (not sure this is possible), or the best yet, is to linearize the arc, ie chop it up into small linear segments, which is what happens in Fusion360. Segment length could/should be related to the bit diameter IIRC, so 100% of bit diameter will easily visible but 5% or 10% will not be, all depends on the material and bit diameter really. Larger segments for roughing, smaller for finishing, the usual stuff (-: Not an uncommon question, 10 years ago... new to G18 & G19 for Z-plane arc cutting (If Haas controllers cannot do it, then GRBL cannot do it)
Which is why I love SketchUcam. When I import a .dxf into SketchUp I go over all the arcs/circles and if they are not true arcs/circles, I redraw them so that they are.
Yep, but, SketchUcam will never try to do vertical arcs in G18 or G19 planes (-: Although the OB Fusion post allows for vertical arcs in the 'onCircular' handler, the allowed planes are limited to XY (G17) so all 'vertical' arcs are linearized (often seen in lead-in and lead-out segments). The reason is that Fusion does some weird things with vertical arcs that cause GRBL to complain about unequal radii where it really should not be happening, I suspect, but have not yet proven, that Fusion has some odd internal rounding algorithm that is messing up numbers with small differences. The defaults for lead-in arc radius are roughly (bitdiameter / 10) which gives you arcs of 0.3mm radius on a 3mm bit, at this size, small rounding glitches lead to large percentage differences in radii. Related to this is Sketchup's habit of comparing numbers to the nearest 0.001", which has caused more than one headache in getting SketchUcam to output the right stuff. BTW there is probably a plugin that can automatically find and convert segmented arcs into true arcs (-:
