Homing on Linear Scale Index

And, also, the system is likely to move some significant distance after the index before the servo thread can act on the information. For this reason LinuxCNC expects the index to be detected by an encoder counter (typically in the hardware of an interface card, potentially a base-thread software counter if the speed and index pulse size allow).

This is the crux that shouldn't be a crux. Thread rates are always finite and limited, but should not constrain feasibility. Spatial resolution is all that counts. The motion step size must be 1/2 or less of the index width. Then the leading edge is detectable by motion. The speed limit of that motion derives from the thread rate. A slow thread rate just makes it take longer, but does not affect feasibility. It will operate as fast as the thread rate vs spatial resolution factors will allow.

The deficiency in the current implementation is the unnecessary conflation of stopping with detection, "before the servo thread can act" as you say. The code should not insist that the index signal be true when the stopped condition is achieved. The leading edge is all that matters, why does the current implementation depend on the trailing edge at all? But the current code does, and you need a high-speed encoder, or a higher-speed base-thread encoding or pulse divider, to work around this stopping non-problem. It might be a one-line source fix, except that this behavior might be a legacy dependency, and hence my propounding a theoretical expansion to a general adaptive positioning feature. An adaptive positioning feature is the identical basis of homing, limiting, probing, and closing the loop on hysteric mechanisms with non-hysteric scales (the "two encoder" problem), so it would sweep all those tasks into common code that has a chance of eliminating the unnecessary peculiarities.

I have adaptive positioing working now in NGC with a smattering of Python, so I believe my analysis and solutions are correct. I plan to post my code, and maybe then the idea will be clearer.

You can still home to an index but you don't need to crawl to find it. ... Have you actually tried this?

Yes, the exercise of that was what got me involved. You don't need to crawl if you have hardware counters (or base-thread HAL) to do the watching, but the stopping conflation is what (1) makes them mandatory and (2) prohibits different scale devices for counting versus indexing. The code was written, I suppose, to handle certain cases, and won't fit the case of a linear scale's index being a different device than the motor's rotary scale. HOME_USE_INDEX=1 relies on the MOTION component which in turn requires the scale and the index be the same device. Configuring by switch (HOME_USE_INDEX=0) handles two devices inherently (and the hardware motor encoder is not required, can be the STEPGEN synthesis), but then the stopping gets conflated, with the result that there's no logical coverage of the case of the second device being a spatially narrow impulse function instead of a step function switch. So there's a reasonable provision case lacking configuration coverage.

Homing sequence is first of all poor documented. What is home sequence 0 or home sequence -2 or -1?. It's that -2 is the last to home.
But who expect's a negative sequence for example "home both" on x1 and x2 axis?

I think the home sequence is written quite qruel. It has no option's to allow outside of the sequence axis to move freely. A dumpert for linuxcnc. But we can repair that soon if linuxcnc developper's finally listen to the "under" people who are at side using the application.

Richard. Are you a professor? It looks like for me.

The homing on linear index scale can be done in hal. But you need to know some things that are not very good documented.

Andy has told mr ds wanson he has tried to explain this to you without succes.
I have tried to explain how this is handled but you appear to not be willing to understand. I have to follow, but if you don't understand the meaning of the ansfer, don't hesitate to ask it again.

Wondering what the best way to do this may be, or if I am overlooking a simpler method.
Why latch search?.... Are you searching for a hamburger or something?

HOME_LATCH_VEL and USE_INDEX = YES.
Wow, man. Why don't try a home sequence for just one axis. Try first to home the x axis of your xyz config.
If that is working for x axis you are on the good way to make succes !!!

Try a simple homing config. Start with config wizzard first. After that, read in and change your hal section.
If you are using Mesa, they will tell you how to do it. If you are using ethercat, i will tell you how to do it.
Keep up the good work !!!

HOME_USE_INDEX=1 relies on the MOTION component which in turn requires the scale and the index be the same device.

I think its good there is an enquiring mind at work but normally, that 1 device would be the linear scale so you'd use that for your servo feedback as well. I think thats what Andy has been trying to tell you. eg. using the motor encoder feedback signal is complicating things for no reason.... use the linear scale signal not the motor encoder.

The discussion has been hopping around musical chairs on this. Various choices are available for solve elements of the problem independently. But no possible combination of those element solutions covers certain reasonable systems.

using the motor encoder feedback signal is complicating things for no reason.... use the linear scale signal not the motor encoder.

This will not work because (1) the linear scale response is hysteric with respect to the motor axis, being that the leadscrew is in between those two elements, and the leadscrew transfer function (LTF) is hysteric (non-zero backlash in any real mechanism). So it is ineligible for any PID feedback loop. I'm repeating what I explained in another thread.

And even if you had an ideal LTF, (2) the economy and minimal logic here is that only the linear scale index signal should have to be connected to be able to home on it. This should be the minimal requirement for upgrading an established system to perform precise-absolute homing. No motor hardware encoder or counter, no phases A/B from the linear scale, should be required. Just the scale itself and one pin on the parport. If parport pins are scarce, a single parport input can cover any number of axis index signals OR'ed into one parport pin if you accept the axes being homed one at a time. With this approach, if you happen to be upgrading a manual machine with a manual DRO, you don't need homing switches, you only require one parport pin and a jumper wire to the DRO, so you keep the manual DRO, get homing, and pay for nothing but a wire. If you can afford the pins to hook up the A/B signals, then you can also perform adaptive positioning, absolute fixturing, second operations, metrology, and more, to the 5 micron precision of an $100 optical scale on a parport-only system. This potential seems to me to be an exciting prospect!

Another problem with linear scale feedback is that it puts all the LTF hysteresis into the PID loop. The servo dither is twice the backlash of every mechanical component between the motor and scale and this overwhelms the 5 micron scale. Even with $$$$ ballscrew components you still end up with summary backlash on the order of 0.001in since the feedback loop then includes all the bearings, and belts/flex-couplers. Thus the 5 micron scale precision is lost in the larger hysterics. The low ballscrew backlash benefits rigidity and consistent milling chiploads in tangential or static plunge cuts, but the dither is still there. With the motor encoder servo feedback, the dither is reduced to the granularity of the motor encoder (8000/rev is cheap now) divided by the LTF slope, which brings it down potentially to ten millionths inch. In that case the 5 micron scale delivers its precision to adaptive positioning, and you still have the rigidity.

Inertia-vs-spring instability is another no-solution hazard with scale PID feedback. If timing belts are used, they're springs, and if the table is heavy, high-frequency PID will flap around in the low resonant frequency. You have to keep belts in the mechanism out of the feedback loop. CNC retrofitting manual machines typically requires belts for compactness and gearing leverage. I learned this the hard way thinking I would turn the lathe spindle with a PID position-mode servo; that is infeasible, and you have to retreat to speed-mode only. Another case of LinuxCNC doing one-sided adaptive positioning with special-case code that should be common: spindle positioning and synchro motion.

No, it doesn't. (It is quite common to use a scheme where the spindle encoder is on the motor shaft but the index is on the spindle shaft, for example)

Citing one reduced case that works does not disprove that the general case does not work. Your spindle case only succeeds because (1) the spindle is a primitive system with no leadscrew or hysteric LTF involved, and/or (2) the index pulse width is wide (Hall sensor, etc) enough to not fall into the stopping conflation bug trap. But I agree it works in that scenario, and indeed that is how my CNC lathe is set up. Of course I found another LinuxCNC configuration deficiency hidden in it: it won't do spindle indexing from the motor shaft index unless the pulley ratio is 1:1, while mine is not.

Richard. Are you a professor? It looks like for me.

Haha, no. I am a self-employed R&D electrical engineer with a background in computing and signal and control theory, and lately machining and CNC to make parts for my optical engineering business. I am a beneficiary of LinuxCNC's majestic work and versatility, and trying to analyze what is missing, mistaken, hacked, or unimplemented in its theoretical foundations so it will perform better things demanded by my livelihood, my equipment situation, and the general betterment of LinuxCNC.