Strange motion offsets in one direction on one axis

Not sure it's a LinuxCNC issue, but I figure the folks here are likely also 'up' on likely hardware/software causes that might be related.

I was machining a pocket this afternoon, and ran into some really weird behavior where everything came out great, EXCEPT the walls on the -Y side of the pocket are over-cut in various ways. The attached image is hopefully clearer than my words (green line shows expected cuts, red line shows actual), but:

• The wall seems to get progressively more over-cut the further down the wall it goes- stairstep effect shown, with "reverse taper". Hard to measure the depths of the steps but they're big- maybe 0.02"? The very top of the wall is fairly close to on-size.
• The "notch" out of the otherwise-rectangular pocket is grossly overcut, except at the very end where it joins the larger area, where it's more or less correct. Notably, that should be a straight line, but isn't. The wall is all scalloped from the adaptive roughing- the finish pass didn't even touch it.
• All the other walls/dimensions look good. The +y wall has about 2 tenths of taper down the ~1" wall, nice surface finish, and the wall thickness is correct. The +X wall similarly measures correctly.
• The pocket is ~1x5"

The machine is using a Mesa 7i76E card, with 5mm lead ballscrews direct-driven by Clearpath servos. The servos are controlled in quadrature mode. Feedback pins are connected, though I'd have to recheck the math for how far from commanded position they'd have to get before tripping an error. Either way this doesn't obviously scream following error. All axes use linear bearings.

Tool was a YG1 uncoated carbide 3/8" end mill with 1/2" LOC, extended reach with reduced shank and ~2.125 LBS. The cuts weren't super heavy- adaptive roughing with ~2mm stepover, ~8mm stepdown, 7000 RPM, 0.0014 IPT/~29 IPM, leaving 0.1mm for a finish pass. I used air blast + MQL, no signs of chip welding or anything like that.

LinuxCNC is 2.10 from Git, grabbed... 6 months or so ago- probably should have used the 2.9 release, but for whatever reason I didn't. Compiled from source on Arch Linux. Machine is offline, so no updates to have changed anything/messed things up.

I reviewed the gcode coordinates manually and also viewed it in multiple different viewers. It looks entirely correct.

Any thoughts? Has there been a known trajectory bug in LinuxCNC I haven't found reference to? Does this sound like some kind of Ethernet/Mesa comms/latency/disconnect issue? Hardware problem? Nothing I've come up with seems to fit the data. I'm perfectly happy to try running updates/move to LinuxCNC 2.9.x (and probably will), but I like to have assignable causes to problems.

Let me know if there's any more detail I can supply, and THANK YOU!

Must be the third time i am looking at this and can not figure out what is going on, and the picture is not helping.
Can you do some more details, like where the mill is cutting and what direction it is traveling, and just to be sure, that there is no undercut as it looks in the picture.
Or am i looking at it from the wrong perspective?

Its not clear it's just one axis with the error.

Random uncommanded moves suggest a hardware issue to me,
either in the drives (encoder feedback error?) or the step/dir
interface (cross talk? EMI? marginal levels? bad connection?)

I'll try to make a better model tomorrow, but maybe the attached shows the gist of it better in cross section. The desired end result is a rectangular pocket. The result is as shown with the undercuts. The tops of both walls are in the right spots and of the correct thickness. The +Y wall is fine all the way down, the -Y wall is not. The end mill was a YG1 E5G98910 (3/8" diameter, 2-1/8" LBS, and 1/2" LOC, with a 0.345" shank, so it is possible for it to make some degree of undercut without rubbing). I'll see if I can measure how extreme the undercuts are tomorrow.

Cutting an internal pocket, climb cuts. The original material was a solid piece.

Possible multiple axes have errors, but I'm not seeing evidence of it. The one dimension in X I can measure is correct and shows no signs of misalignment between Z passes.


I agree this smells like a hardware issue- if so, it'll probably be a bear to track down. The motors are ClearPath servos, driven in quadrature mode. I believe the signals are 5V from the Mesa board, but would have to double check that. If there's some kind of encoder error, it's internal to the motor.

The cables are as provided from Teknic: motor -> cable -> soldered joint to circular connector -> connector -> soldered joint on other end of connector -> ferrule to 7i76E screw terminal. X and Y cables do run adjacent to one another (and power cables) for a few feet, and they're not shielded- though Teknic also sells 55' unshielded cables, so one might infer they don't believe it's important.

What's really hanging me up is that it seems to return to the correct place in +Y, despite apparently cutting incorrectly a variable amount in -Y.


Either way, I'll double check nothing is mechanically loose tomorrow (that would be the nicest answer) and put a scope on the Y axis signals while jogging X around, see what kind of cross-talk I get. I already got LinuxCNC 2.9.3 installed.

ETA: Mechanics appear fine- I can lean/pull on the Y axis and it'll move maybe 0.001", then springs back when I release it. Leadscrew retention nut appears tight.

Do let me know if things are still unclear.

Some debugging. Per update above, mechanically things seem fine- I can shove the Y axis around and it's definitely not moving as much as the undercuts previously mentioned. I measured those, and the deepest is maybe ~0.01"/10 mil/0.25mm. Not as bad as I thought, still entirely unacceptable.

See attached pictures for some scope traces of one of the Y axis quadrature phases. Note that the measurement setup wasn't great for this, so there might be more noise represented here than is present in normal use- scope leads were dangling from jumper wires wedged into the cable ends, so... yeah.

With nothing moving, the signal idles at 5V +/- ~1.2V. Moving the X axis doesn't seem to influence this at all. Enabling the spindle adds some noise, dropping the signal as low as 2.3V. That's quite possibly enough to create false motion- minimum input to the servo is listed at 4V, but it also says it has digital filtering against noise, so... who knows. I should look at both A and B phases at once, but ran out of time. The fourth picture shows the Y axis moving- it's pseudo-differential, which in this case I don't think is actually buying anything, since the motor inputs are opto-isolated.

All of the above seems suboptimal, but I'm not seeing how it would somehow create extra steps in -Y, then somehow seemingly exactly recover them when going to +Y. Unless I want to level-shift, I'm not aware of a way to get the 7i76E to output > 5V on the motor control pins.

Anything else I should check? I'll plan on getting traces of both A and B phases simultaneously. Is a 3D model of  the issue still helpful, or is the cross-section sketch sufficient?

Without a differential probe it's pretty hard so see,
but position recovery really seems like a drive or mechanical stall issue.

Can you set the drive following error limits tighter?

If it's possibly a drive strength issue, you could try single ended wiring.
(Since the drives have optoccoupler inputs this should have little effect on noise immunity)