One problem is that the arc center has to be calculated based on the
start and end points. Generally we round the g-code coordinates to 3 or
4 decimal places so there is often a tiny rounding error in these
points. In most cases the error is very small and can be ignored. The
big issue is when you have an arc that is nearly a circle. Now any error
on the start and end points is massively magnified by the arc center
calculations. It's a bit of an edge case but if you get caught by it,
the results can be ugly. This is not a fault of the code, it is simply
the way the geometry works. You cannot specify a circle using R instead
of I,J. In this case there is not enough information to even attempt to
guess at the arc center.
Another issue occurs at 180 degrees. Again due to rounding errors it is
possible for the distance between the start and end points is slightly
more than twice the arc radius. In that case the radius need to be
fudged a little to get the arc to fit.
Some CAM packages have an option to break up big arcs to avoid these
problems.
Les
On 08/02/2022 01:53, dave engvall wrote:
Hi,
I've read the assertion many times that ijk is better than radius and
always assumed it to be correct; but by how much.
Few of us run machines and are 'new' tigjht ;-) Maybe I've not looked
in the right place(s)
for an analysis or for demonstrated interp of circles with some kind
of error band. Any proof and or experimental evidence?
Just poking the bear. ;-).
Dave
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
