Lead-screw Compensation

You are properly right in a general sense with your statement.
But the drift of the a ball screw on a C7 ball screw is considerably high and some people like to improve the accuracy of the traveled distance therefore use the "lead screw compensation".
This function is usually not used for backlash comp.

agree
if you buy a Liniar Scaler at the max travel size
you may ad it permanent to one axis and go for a ENCoder in to REAL DRO

www.ebay.de/itm/2-3-Achsen-Digitalanzeig...Encoder/192754839016

silden wrote:

I started LinuxCNC and tested the compensation with my dial gauge.
This revealed that the compensation is not active.

If you're not getting the results you expect, then that does not necessarily mean that the compensation feature is not active. It could be that it is active but various other requirements have not been satisfied: a proper and valid compensation file based on the correct procedure and technique of measurements, correctly understanding how compensation works, and knowing that the physical mechanisms are candidates for fixed compensation. These are complex, critical factors that have to be right or the compensation will be ineffective, or even worse than no compensation.

The LinuxCNC documentation only explains how to specify the compensation file. The documentation does not explain anything about how compensation works in theory or practice. The concept is full of thorny complications.

The documentation doesn't explain whether the compensation is applied forward or inverse. That is, do the table values represent the axis position required to achieve a true position, or the true position resulting for a given axis position? This is fundamental to the compensation concept, and you can't succeed without knowing and applying this functional distinction in your measurements. If I'm measuring with a dial indicator, am I supposed to target the dial and write down the axis value, or target the axis and write down the dial reading? Likewise the sign convention is not stated. So that makes four incompatible ways right there of how to measure and specify compensation, and who knows which one LinuxCNC takes.

You need a precise, repeatable, consistent homing on the axis, applied when generating the compensation values "one time", and when applying them at every subsequent startup. Without this, the compensation values are meaningless, and typically make things worse. To the extent home differs across measurement sessions and operational sessions, the compensation table is phase-shifted and nothing is right. You must measure leadscrew error with the same backlash condition as homing takes ... more thorns in these configuration variables.

Leadscrews have both periodic and global errors. You can only correct them to the extent that you can guarantee physical repeatability of the error. If you think the machine is some degree of imprecise, but consistently so, then it's because you haven't looked micrometrically, or kept watch over time. If anything changes slightly in the machine, this immediately voids the compensation measurements. Consider that some of what we think of as leadscrew error is actually error in the fixed angular contact or thrust bearings fixing the end of the screw. Those bearings can rotate or shift during operations, then you can't possibly compensate. Bearings, belts, pulleys, couplers, ... are all sources of error contribution, systematic, periodic, random, and time-changing.

A valid compensation table requires taking a thousand measurements. It is not practical to do that manually. Even if you labored through it, it is all wasted the first time anything slight changes in the machine. This is similar to tool offsets for a quick-change tool post, where if the post budges, the offset table is trash, and all the hard work of measuring offsets is wasted and has to be done over. That's a grief with a few tool measurements; imagine a leadscrew error characteristic with 512 values.

Look at my charts in my post Possible error in logic of LinuxCNC homing with leadscrew compensation . This will give you an idea of how difficult compensation is to achieve and maintain. I suspect it doesn't even work correctly in LinuxCNC currently, because of the suspected bug described in my post. You can work around the bug by taking care to generate a compensation table with value zero at the home position, so the feature is still usable, despite the documentation puzzles. The software can't help with the practical problems of metrology and maintenance.

LinuxCNC also has no feedback signals on the compensation performance; it is essentially an open-loop process. If compensation is not working, or is making things worse, there's no way for the software to detect that condition. At the highest level, compensation is a manual task, something you have to watch yourself all the time, because automatic open-loop systems always fall into mischief sooner or later. This spoils a lot of the benefits motivating CNC to start with. You can't ever turn out the lights.

Mere backlash compensation is a simpler problem. But of course it's not compensating periodic or systemic error at all, it is just a crude compensation for hysteresis. Hysteresis and non-linearity are two different beasts, and they should not be handled in the same theoretical feature.

"Buy better leadscrews" is not an answer. Compensation, if it can be made to work, is a useful improvement to any translation mechanism that is less than perfect, and they are all such. Crummy leadscrews can be made to work decently, and good leadscrews can be made to perform significantly better than without compensation.

ok you are wright with the documentation
lets have it that way
is the PIN Visible
axis.N.backlash−corr

is the Full path set to the INI

COMP_FILE=./myZ.comp