Arc output looks very promising for making it easier to get better results faster, and much more stable in 4.6 than 4.5.
So then I’ve learned a couple of things about grbl’s handling of g2/g3 arcs and have a couple of feature requests.
1/2: enforce minimum precision for g2/g3 which may override a smaller “DECIMALS” value.
Grbl & LinuxCNC require 3 digits precision for mm and 4 digits precision for inches to avoid rejecting some g2/g3 commands due to rounding sometimes going beyond tolerance for valid arc math. Maybe others, I don’t know. Reference: “When programming arcs an error due to rounding can result from using a precision of less than 4 decimal places (0.0000) for inch and less than 3 decimal places (0.000) for millimeters.“ found via a grbl user’s report with a worked example.
But microns are noise to my machine, and finite bandwidth to the controller is sometimes a problem. So I would rather set DECIMALS=2 (mm) for output. (are there any <10 micron precision machines here?)
That sounds “easy’“ but I fear it may be a trap. It sounds “easy” to enforce a minimum precision when processing a g2/g3 command for output. But then only the end and center positions get enforced precision while the start precision is inherited from the preceding end position which may have been lower precision. Without looking at the math: that smells like a probable problem. Enforcing minimum precision when the current or next XY move is an arc seems like it should work, but I don’t know if the relevant bit of code can look ahead. And the next XY move might be many lines ahead. Alternatively KM could look back to add precision to the end position of the previous XY move, but I’ll be a little surprised if that isn’t harder. Or insert a g1 to the last XY position with extra precision, which would move <10 microns, which seems like it would be “easy” if a bit clunky. Write thru a FIFO that holds XY moves until the next one comes in?
(for completeness: the LinuxCNC doc suggests the issue is specific to center format arcs, and I’ve assumed KM assumes all arcs are horizontal)
2/2: limit, or allow limiting, arcs to half circles. I’ve found that sometimes full circles do nothing, apparently going the zero-degrees way around from start to start. Flipping the g[23] direction fixes that, but I have to run the job to find failed circles because running in grbl is the only time they fail. People On The Internet say grbl is supposed to handle full circles, and often does, but not reliably so, so don’t expect that it will (example).
As it is, I’m reluctant to use Arc Output for anything that includes circles and isn’t very short, because the only way I know to find failed circles is to let grbl execute them. For very short jobs I can watch an air cut, but that’s not practical when it requires hyper-vigilance over more than a short period of time, or single-stepping thousands of steps.
I’m suspicious grbl may occasionally go the wrong way around half < arcs < full too, but without information that it does.
To avoid UI clutter, generally splitting arcs > 180deg into two arcs seems like maybe not much penalty even where not necessary.
(edit: typo)
(edit: add…)
NC Viewer (ncviewer.com) also misses some full circles. But different ones than grbl. i.e. NCV does not draw some circles that grbl will cut and draws some circles that grbl won’t cut.
So:
NC Viewer is even more not a useful pre-check for grbl, and
NC Viewer is a more general tool than grbl, which makes defaulting to 180* max arcs less of a special case.