Precision automatic homing using an independent DRO scale index

Since LinuxCNC was designed around actual encoder hardware, the latch/reset + flag detection scheme seems
like a reasonable design decision.

You're correct and I agree, the concept is proper, but LinuxCNC is an unnecessarily narrow implementation. When homing to an index, LinuxCNC assumes zero hysteresis between the index signal and the position signal, as a function of position. Thus LinuxCNC cannot close the loop on finding reality, just the motor's reflection of reality, where reality = the physical position of the table, not the imperfectly reflected position of the motor.

A better theoretical understanding of homing is to view it as sampling the inverse of the motor-input/true-position-output response function. Homing on the motor index ignores that function altogether, and can't find an absolute output home, just a repeatable relative home input. But home is a certain state of the joint output, not an arbitrary position of the joint motor input. The input-output response function is not perfectly linear, and hysteresis is never zero. That function has to be inverted to find the input value for the home output value. The function can be quite sloppy in linearity and hysteresis, but that doesn't matter because you can invert it as long as it is monotonic. Then your DRO scale is reflected back through the inverse function to reveal the motor input that stops on a dime, a 5-micron dime at that.

LinuxCNC treats homing by-switch (as opposed to by index) differently. The by-switch code does invert the response function. It samples the response function with a slow-velocity move to find the inverse, that is, the motor position that happens to close the switch. It's an misfeature that LinuxCNC requires a homing switch to be a step function instead of an index pulse, but that can be worked around as I've explained. Microswitches or Hall sensors are OK, but they're not precise like DRO scales.

Is your criticism addressed if you wire A and B from the motor encoder to the encoder counter, but wire the index of the scale to that counter?

Astute concept, but:

(1) The motor encoders aren't even connected to the PC (the servo motors have their own servo controller with step/dir connection only to the PC).

(2) I suspect the same no-hysteresis assumption hard-coded into LinuxCNC will defeat your idea the same way it defeated my experiment with HAL-ifying the DRO index directly into the axis.N input. Your suggestion might even be circling back to my criticism in my original post, "LinuxCNC hard-coded homing logic seems to apply some magic to the primary encoder state to make the final moves". I gather this magic was a reasonable shortcut to get homing-on-index implemented at all, but the hard-coded premise of no-hysteresis absolutely prevents the direct use of an independent index signal. Homing-on-index assumes the motor encoder phases and index are on the same wheel. You can't have a imperfect transfer function interposed between the phases and the index sources.

My workaround performs perfectly. The AXIS GUI "Home all" now homes all axes automatically and precisely on the DRO indexes, by having HAL mimic switches. This avoids the home-on-index hard-coded trouble, which trouble I suspect is insoluble short of a rewrite that would risk breaking other things.

With some additional HAL works, I have also succeeded in performing G38 probing on the DRO position, kind of an introspective probe. Then G-code can locate to a given DRO position, instead of the imperfect leadscrew transfer function of the motor position, automatically interpolating the leadscrew inverse transfer function on the fly. Thus I can hit 5 micron accuracy on table positions, regardless of major non-linearity and backlash in the leadscrews.

Why dont you just use the linear scale position and home to index as most real machines with linear scales do?

Expecting LinuxCNC to support your idiosyncratic homing scheme natively is unrealistic. Homing to index via clearing the hardware count in index _is_ the standard.

(Though higher end machines typically use absolute linear scales)

Why dont you just use the linear scale position and home to index as most real machines with linear scales do?

Because the fundamental stability and granularity of any axis is limited by Nyquist weakest-link to no better than twice the total hysteresis of the feedback signal to the position command. You can't position to the precision of the optical scales because they are the strong link to absolute position, while it is the weakest-link that governs and limits the dynamic performance. A "real machine" that is closed loop must therefore use zero-backlash perfectly-rigid non-stiction mechanical elements entirely. Of course backlash is never zero and rigidity is never perfect and stiction is ever present, but if the practical values in a "real machine" ($1000s per axis for ground ballscrews, etc) amount to, say 0.0005in, then the real machine potentially achieves only 0.001in positioning accuracy. The optical scale precision of 0.0002in is wasted and of no benefit in the ultimate performance.

If you don't have the luxury of massive iron pushed by ground ballscrews on Turcite ways, then you are in a predicament, despite all due-diligence, of say 0.004in of hysteresis (backlash), plus non-linearity errors. Your machine is only good to +/- 0.004in positioning precision dynamically, on top of an equal magnitude homing error. No good for a machine tool! But you can still achieve static precision of twice the optical scale steps (like, 5 microns for $100) on $50 leadscrew sloppiness. The homing theory must be theoretically general enough to support that mode, and not idiosyncratic about the homing device model.

Expecting LinuxCNC to support your idiosyncratic homing scheme natively is unrealistic. Homing to index via clearing the hardware count in index _is_ the standard.

Are you saying one limited model of homing specification and logic is the standard, but that is not itself an idiosyncrasy?

I'm advocating that LinuxCNC should be decently general in it's model of these devices and their application.

Take a homing switch, for example. It takes about a dozen values to fully specify the performance characteristics of such a switch, for characteristics that are material to homing (width of hysteresis both positive- and negative-going, location of hysteresis, polarity of hysteresis is make-before-break or vice versa, etc). Yet LinuxCNC ignores these critical factors. Thus homing is a dodgy feature in LinuxCNC: it's hard to get it to work at all, and it isn't precise absolutely to the available device, just an open-loop relative position. It only works as being a repeatable relative position, not an absolute position. You just need the HAL workaround to use an independent DRO to home. No need for an idiosyncratic zero-backlash "real machine" that is DRO dependent for axis feedback.

Because the fundamental stability and granularity of any axis is limited by Nyquist weakest-link to no better than twice the total hysteresis of the feedback signal to the position command. You can't position to the precision of the optical scales because they are the strong link to absolute position, while it is the weakest-link that governs and limits the dynamic performance. A "real machine" that is closed loop must therefore use zero-backlash perfectly-rigid non-stiction mechanical elements entirely. Of course backlash is never zero and rigidity is never perfect and stiction is ever present, but if the practical values in a "real machine" ($1000s per axis for ground ballscrews, etc) amount to, say 0.0005in, then the real machine potentially achieves only 0.001in positioning accuracy. The optical scale precision of 0.0002in is wasted and of no benefit in the ultimate performance.

Not entirely, the optical scale also provides position feedback independent of ball screw expansion, screw errors, screw wear, and stiction. Scale feedback can provide static/low frequency/low load position control better than the backlash if the backlash is removed from the joint by feed-forward. On dovetail way machines with significant stiction, considerably higher accuracy is possible with linear scale feedback since it can correct for stiction which is notoriously difficult to correct for with modeling/feedforward.

Here's a real world example with modest hardware:

forum.linuxcnc.org/49-basic-configuratio...etup?start=40#126232

Notice the large improvement in static position accuracy despite large (too large because the gibbs were accidentally too tight) stiction

If you don't have the luxury of massive iron pushed by ground ballscrews on Turcite ways, then you are in a predicament, despite all due-diligence, of say 0.004in of hysteresis (backlash), plus non-linearity errors. Your machine is only good to +/- 0.004in positioning precision dynamically, on top of an equal magnitude homing error. No good for a machine tool! But you can still achieve static precision of twice the optical scale steps (like, 5 microns for $100) on $50 leadscrew sloppiness. The homing theory must be theoretically general enough to support that mode, and not idiosyncratic about the homing device model.

Well that static precision will only be at the temperature you measured the ball screws, (with a 10C temperature change and 10 inch ballscrew you are already 1 mill off at the end), and if you ignore stiction. Which are reasons a "home to index pulse but throw away the positon count" homing scheme is uncommon/idiosyncratic

Take a homing switch, for example. It takes about a dozen values to fully specify the performance characteristics of such a switch, for characteristics that are material to homing (width of hysteresis both positive- and negative-going, location of hysteresis, polarity of hysteresis is make-before-break or vice versa, etc). Yet LinuxCNC ignores these critical factors. Thus homing is a dodgy feature in LinuxCNC: it's hard to get it to work at all, and it isn't precise absolutely to the available device, just an open-loop relative position. It only works as being a repeatable relative position, not an absolute position. You just need the HAL workaround to use an independent DRO to home. No need for an idiosyncratic zero-backlash "real machine" that is DRO dependent for axis feedback.

What hysteresis? homing always approaches the final move from the same direction at the same speed

Scale feedback can provide static/low frequency/low load position control better than the backlash if the backlash is removed from the joint by feed-forward.

"Static" interpolation being the limitation of that. You can't traject the machine bidirectionally via a hysteric transfer function. Path operation requires PID and PID dithers at +/- total hysteresis. Interpolation consumes the trajectory freedom before PID gets a chance to play.

And it doesn't solve the predicament that HOME_USE_INDEX is hard-coded for zero hysteresis in the transfer function.

What hysteresis? homing always approaches the final move from the same direction at the same speed

That's my point. The homing device exhibits hysteresis in a dozen possible factors, but LinuxCNC's homing model is agnostic and therefore its homing logic is not configurable to any but one factor. It models the switch as non-hysteric, and can only operate the switch with one logical method (one-way/one-direction/one-time, only one of some large number of useful possibilities) that doesn't cross any hysteric ordinates but the one ordinate it knows.

The model is what is idiosyncratic as to switch characteristics; it ought to cover and configure to the general domain of switching characteristics, and provide a configurable general state-machine for operating on that domain. This would be both simpler and more general than the hard-coded inputs and idiosyncratic state-machine. For example, the {turn-on,turn-off,make-before-break,break-before-make} x powerset{positions,direction,widths,statistical repeatability} domain. Orthogonalizing the truth table would make this comprehensible to whoever has to do the configuring, because you just have to enter the few elements that differ from defaults. As it is the logic diagrams at linuxcnc.org/docs/html/config/ini-homing.html are meaningful and correct about what is available, but incomprehensible. It would also be cleaner code instead of ad hoc, and common code to implement G38 probing operations and static interpolation which are identical to homing.

Doesn't the fact that the homing direction and velocity are more or less constant (with in reason) remove the home switches hysteresis from (or at least minimize it's effect on) the equation of the repeatable accuracy of the homing cycle? .

And what is the difference if home is a repeatable relative or absolute position. Every thing is relative. In this case you are setting the home position relative to the homing switch (and/or index). Of course it is relative, absolute has nothing to do with it and never did and it shouldn't matter so long as it's repeatable.

There is always the sampling error from the servo thread speed plus jitter and the velocity of the probing cycle, but with hardware encoder reading that greatly reduced because the encoder count is reset at the hardware encoder counters sampling rate, not in Linuxcnc's servo thread.

Maybe i'm just not really understanding the question.

There that's my 2 cents for what little that's worth.

Doesn't the fact that the homing direction and velocity are more or less constant (with in reason) remove the home switches hysteresis from (or at least minimize it's effect on) the equation of the repeatable accuracy of the homing cycle?

Yes. That is my point. The LinuxCNC theoretical model of switch character is strict, not general or universal, and therefore the application space cannot be general. It works that one way with a narrow option of devices, and you have no freedom to configure another homing process or device.

For example, the homing switch model in current LinuxCNC assumes the response is a step function which can be sensed in one going direction. It also makes a precautionary assumption (not necessarily valid, but timid) that crawling past the on-ordinate will damage the device or the machine (thus allowing the hack of overloading limit switches into poor-man's home detectors). Thus the model conceives but one characteristic, assumes that the characteristic value is zero, and provides only a one-sided sampling direction. A decent switch model would express eight ordinates, the turn-on vs turn-off position vs going, relative to some defined switch origin. Travel-damage limits should also be theoretical ordinates. Current LinuxCNC is agnostic to most of those characteristics, and arbitrarily imposes fixed-strict values on the few it does acknowledge:

{turn-on,positive-going} = origin+0.0
{turn-on,negative-going} = agnostic
{turn-off,positive-going} = origin+infinity
{turn-off,negative-going} = don't-know-don't-care
{travel-damage,positive-going} = {turn-on,positive-going} + who-knows-keep-it-small-and-hope
{travel-damage,negative-going} = -infinity or the opposing limit switch, whichever comes first

Each associated pair of hysteresis ordinates divides travel space into 3 regions. Traveling the universe of 2 going-directions thus yields 3**2 = 9 possible classes of switch response. Currently LinuxCNC restricts you to one certain class. This is not general, and prevents configuring homing to work with anything but a certain class of switch detector (namely, a step function ... that gets damaged for certain inputs!). For example, LinuxCNC homing won't work with DRO indexes which are impulse functions, because that class can't be expressed in the two numbers I listed above.

A general model could also include a statistical dimensions to the switch characteristics, and multiple generalized signal phases. This would permit multiple detections with signal filtering to improve the precision. There is no reason to restrict the detection to one experiment. You should be able to use, say, an RMS average of multiple samples. That benefit would cost one for-loop integration in the source code. There is no reason to assume the switch provides only one step signal and no other phases. You could take a baseline from a DRO index, and then sample several phases around it to statistically improve the Nyquist error from (error > 2) granules to (2 > error > 1) granules. A few slow passes thus gathers dozens of samples that when integrated resolve much better than taking one sample and hoping for the best. This also improves reliability and fault detection.

And what is the difference if home is a repeatable relative or absolute position. Every thing is relative. In this case you are setting the home position relative to the homing switch (and/or index). Of course it is relative, absolute has nothing to do with it and never did and it shouldn't matter so long as it's repeatable.

It's a huge difference because of the consequences to feature capacity.

The complete homing theory and model must provide for another characteristic: rough-relative vs precise-absolute. The rough-relative capacity is all you need to boot the machine roughly inside a known operating envelope (itself an inside-out hysteric characteristic), so you're not crashing afterwards (forbidden to cross into the hysteric region). Current LinuxCNC automatic homing is about rough-relative. The problem with a rough-relative home is that precision work requires manually touching off every fixture, toolholder, and workpiece, on every {cold start,workpiece change,fixture change}. The rough-relative homing may be automatic, but that still requires a tedious manual touch-off to refine into precise-absolute, so the total process is not automatic. In theory touching-off should only be necessary for items that change unpredictably, like rough workpieces. But with rough-relative homing, you only have a rough fix on the G53 joint range, and no precise fix on where the machine features are located on the G53 joints, since the absolute precision is limited by the rough home switch error. The rough fix is fine for sane motion limits, since you just shrink the G53 envelope by the degree of roughness.

Precise-absolute homing is a finer principle. The automatic precise-absolute home gives you {precise,absolute,repeatable,cold-restartable,readily-calibratable,statistically reliable,fault-detectable}x{automatic} referencing to the machine business-end features in G53 terms. Instead of manually touching-off to gain those references for every feature to be used, you have them automatically and effortlessly. Touching-off is eliminated for anything predictable, and only required for random items like uncalibrated fixtures, rough workpieces with non-wasting constraints.

It's critical to have a precise-absolute homing in G53 at cold-start. The {G54..59.3,G92,tool-table} offsets cannot be logistically overloaded with the conflated duty of correcting a rough-relative home to a touched-off precise-relative home nonce. Those offsets have important independent purposes, and conflating them into a run-time synthesis of precise-absolute homing consumes their facility.

This may be obscure if you're using a mill, where all the workpiece axes normally have to be touched-off in conventional operations anyway, so there's less motivation for a precise-absolute home.

The motivation is clearer on a lathe, where you wish the cross-slide to precise-absolute home itself automatically, so you calibrate once-per-epoch to the spindle axis, calibrate the tool table, and then automatically get repeatable results across cold-starts to the precision of the DRO index, instead of having to do trial-cuts and touch-offs after every cold-start or volatile-start. Then you have automatic diametric precision and session/restart repeatability to a few DRO granules, instead of to the weakest-link of the home imprecision against the open-loop compensated leadscrew transfer function error, which will amount to an order of magnitude worse. This follows from the different machine logic of a lathe, which cuts relative to the spindle axis, rather than a mill's relative cutting to a touch-off. Ultimately the logical foundation is whether the machine turns the tool (mill) vs turns the workpiece (lathe). The value of automatic precise-absolute homing derives from the turning-the-work factor. You also gain, for free, cancellation of sloppy leadscrews, since you're inverting the sloppy/hysteric leadscrew transfer function in real time on orthogonal moves. Sloppy lathe leadscrews with solid DROs can perform orthogonally at DRO precision; this is essentially a CNC mimic of the music of a manual operator watching the DRO instead of the handwheels.

Another bonus of precise-absolute homing is that it permits the machine to be used inversely as an automatic measuring device, or for precision automatic-refixturing for second operations. You don't have to manually touch-off and find-on dial indicators. Fixtures then can be absolute instead of relative with respect to multiple-operation parts. A G38 probing tool upgrades to being absolute in G53.