Issues with consecutive arc motion

Hello all, I picked up a machine from someone else with axis 2.7.15 and am trying to make a countersink by ramping down in a spiral. For clarity, I am using an end mill and going in a CCW helical spiral. Sample code is as follows:

G03 R0.168 X0.168 Y0.000 Z0.0043
G03 R0.168 X0.000 Y0.168 Z0.0035
G03 R0.168 X-0.168 Y0.000 Z0.0028
G03 R0.168 X0.000 Y-0.168 Z0.0020...

The issue is as follows. The first arc will look correct, the second arc will drive more left before driver down so the arc will be incorrect (it's almost as if the Y is lagging), the third arc will be correct, the fourth arc will drive in the x first and the y seems to drive late like it's lagging. I've used halscope to look at some outputs and these are them: ibb.co/b5WTfCH3

The secondary issue is that the machine stops or slows between arcs and I don't want that to happen.

For the life of me I can't figure out why it's happening. 
Previously I changed the .ini file to increase the lookahead and the arc blending because the segments were stopping between every arc and I wanted a more continuous motion. I get the R is slightly off if the Z is included BUT then I would expect all four arcs to have the issue not just two of them.

(I don't need any help with the gcode as that is not the problem I am having - also I am well aware that *technically* ramping down each line will produce a slight inaccuracy in the machined dim - but that is within the req tolerance of the feature I am machining) 

Thanks for your help

First thing I'd do is run a test program with just the arc moves, and add an M1 between each line.  Maybe slow the feedrate down, too.

Point of this is to see if the DRO matches your expectations at the end of each arc segment.

If the DRO matches what you expect, then possibly you have a mechanical issue - coupling, ballscrew/nut bearings, some sort of lost motion.  Possibly a tuning issue during decel for one of the drives.  Might explain why it's only on two opposite arc segments.

If the DRO does not match what you expect, then you can (probably) rule out a mechanical cause - LCNC is deviating from the path - and it's time to look for config or g-code issues.

I'd also suggest reviewing the LCNC manual on G2/G3.  I know you said you don't need help with the g-code, but the manual is pretty clear that center-point arcs are more accurate than radius arcs and that rounding errors may lead to problems.

NOTE: I just spotted a warning in the manual about G2/G3:

linuxcnc.org/docs/stable/html/gcode/g-code.html#gcode:g2-g3

Your Z-pitch is pretty small, and you may be experiencing some aspect of the bug reported above. Possibly fiddling with the P64 Q-value (see bug report) might help.

2.7 is a very old version now given 2.8 was released about 10 years ago when I first started with linuxcnc. If its not mechanical and not your gcode if linuxcnc is the cause, it may have been fixed in subsequent releases.

Also be very careful when reading the docs that you are reading the ones for your version. I got caught with this a lot when I started. The docs spumco shared are for version 2.9. The warning he found is not in the 2.7 docs. Not saying it does not apply, but it could be different today.

rodw wrote:

Also be very careful when reading the docs that you are reading the ones for your version. I got caught with this a lot when I started. The docs spumco shared are for version 2.9. The warning he found is not in the 2.7 docs. Not saying it does not apply, but it could be different today.

Always sound advice.

In this case the bug was found under 2.7.8:

And the 2.8 docs were updated with the warning, but not 2.7.