Y axis movement on X axis straight line move, related to backlash comp?

I get a strange Y movement on most of the parts I run with a squarish contour. It's always at the same side of the parts along the X axis feed. Halfway through the X movement, the Y will step out probably near .010". It's not slop or anything, on a multipass contouring op It will make the movement at the exact same place every time, and I can see the Y motor move at this point. I don't think it's a CAM issue because when the Y moves the DRO does not register this movement. Come to think of it I get this on large interpolated holes as well, I didn't think too much of it on a round hole because that's a coordinated movement with more room for error. On a straight line move it's a more obvious issue.

The only thing I can think of is that it's related to backlash compensation or something but that's a strange way of doing it. I assumed backlash comp would only make an extra movement at the initial direction change of that axis, as you would with a handwheel on a manual machine. Backlash comp is set at up to .008" at the moment, until I get some preloading set up. Dimensions turn up pretty good other than this weird facet that's left with this strange Y movement. .ini file and G-code of an affected part.

I see the same behavior on my z-axis, which has a small backlash correction (about 0.002").

Probably some quirk in the trajectory planner that somehow sees a change in direction for the idle (backlash corrected) axis, even though the commanded position has not changed.

Now that you mention it I do get an odd finish blemish when I run a facemill along longer parts on the X as well, same spot every time. I don't think it's the Z because there doesn't seem to be an "edge" to it. Probablt the Y again. Is there any fix for this, other than turning backlash comp down to 0? Assuming this is due to BC.

I dug into this a bit further, and I believe there is a bit of a bug in the "control.c" module.

During the backlash correction computation there are numerous checks to see if the joint velocity is positive, negative, or zero. However, these checks are done on floating point numbers with no tolerance. Therefore it is possible for a floating point math uncertainty to change the movement from positive to negative with only a change in the LSB of the double precision number. Even if the commanded velocity is zero, there are several additions and subtractions of positions, calibrations, etc, that could change the LSB.

Comparisons on floating point numbers are always risky for this reason.

I checked the source from both version 2.7.14 and 2.8 master. There appears to be no difference in the backlash sections.

GeneRF wrote:

I dug into this a bit further, and I believe there is a bit of a bug in the "control.c" module.

During the backlash correction computation there are numerous checks to see if the joint velocity is positive, negative, or zero. However, these checks are done on floating point numbers with no tolerance. Therefore it is possible for a floating point math uncertainty to change the movement from positive to negative with only a change in the LSB of the double precision number. Even if the commanded velocity is zero, there are several additions and subtractions of positions, calibrations, etc, that could change the LSB.

Comparisons on floating point numbers are always risky for this reason.

I checked the source from both version 2.7.14 and 2.8 master. There appears to be no difference in the backlash sections.

Well that's slightly over my head lol. I'm running 2.8 compiled from master with 7i96. This machine is using a 7i76e but I have another machine using a 7i96 and I wanted to be running the same version on both.

Is there any fix to this? I'm not doing aerospace work but I know LinuxCNC is used in serious applications and even OEM like Tormach, I can't imagine it would be tolerable in those situations. So I assume this is a rare-ish case.

If my guess is correct, the only fix would be to tweak the code a bit.

An easy test would be to put in an intentional very slight ramp in the y-axis, say 0.0001 inch, and then see if the jump still occurs. If it does then I am out of ideas. If there is no jump then the floating point zero check is a likely suspect.

BigJohnT wrote:

The only way to fix this is to remove the backlash from your system. You can't expect perfect milling on a machine with backlash.

JT

I completely disagree with that. I don't disagree that 0 backlash is ideal. But I didn't ask anyone to fix my backlash, I asked if there was a way to fix backlash compensation. It's in LinuxCNC, it has a bug, I can't fix it.....I'm sure somebody can or will. Backlash comp actually seems to work fairly well. for it's intended purpose, this unintended side effect (that happens when it's not actually compensating for anything) is the issue.

On a side note I bought the mill to prototype some parts. I made the CNC conversion parts on the mill (and a 1944 Sheldon Iathe) that I had to keep taking apart for measurements and to actually make the parts. Now that it's under NC control it's not a big deal to redesign the parts and lower backlash. It's just not something I have time to do at the moment

GeneRF wrote:

If my guess is correct, the only fix would be to tweak the code a bit.

An easy test would be to put in an intentional very slight ramp in the y-axis, say 0.0001 inch, and then see if the jump still occurs. If it does then I am out of ideas. If there is no jump then the floating point zero check is a likely suspect.

I can try that when I get a chance to test it. Do you think entering a different value for backlash comp would help with whatever calculation errors exist? I can deal with the results of a couple thou uncorrected backlash. I don't rely on interpolated holes for bearing fits or anything anyway.