Precision automatic homing using an independent DRO scale index

My goal is to use an independent DRO scale to precisely refer the axis home, including in the automatic homing process. While LinuxCNC features a homing method based on an index pulse, I've concluded that method prohibits the index signal coming from a second independent encoder like a DRO scale, versus the index of the axis motor. I could not find by experiment any HOME_USE_INDEX method that would work with the DRO scale. Although the setup would initially scan for and validly detect the home position, the LinuxCNC hard-coded homing logic seems to apply some magic to the primary encoder state to make the final moves, which winds up leaving the axis at the random starting location instead of the newfound home.

My solution was to HAL-synthesize a homing switch out of the DRO's index pulses. The HAL plumbing converts the momentary pulse into a switch-like characteristic, which turns on and off on either side of the index position. The vanilla .ini configuration for autohoming with HOME_SEARCH_VEL and HOME_LATCH_VEL then works.

The DRO index pulse signal is netted to the clock input of a "flipflop" HAL component. The flipflop output is netted into a "not" HAL component, the output of which is netted into the flipflop data input, creating a divider function. The divider outputs a rising edge event for the first input rising edge, a falling edge for the next, and repeats. The flipflop output thus detects a even (off) or odd (on) number of visits-to (not necessarily crossings-of) of the index rising-edge location. This mimics the action of a home switch, including a hysteresis (dead band) amounting to the index pulse width geometry. The visit-certainty versus crossing-uncertainty is due to the possibility that the motion stop and reversal is too "lucky" (that is, the stop occurs precisely within the few microns of index-true range), resulting in an index falling edge occurring during a return motion instead of full crossing. True crossing detection is not possible because the index signal is only single-phase, not two-phase like the A/B position signals. This crossing/non-crossing uncertainty is removed by simply programming the motion to not stop too abruptly at the index rising-edge, which certifies that any subsequent trailing-edge signal must be the result of a full crossing. Stopping "too abruptly" in this situation means within the index pulse spatial width, which typically being 5 microns on DRO scale, is not a worry for typical machines.

Here's the relevant HAL configuration:

And the relevant .ini configuration:

You an home using Index
see homing sequence on the ini Documentation Chart

> You can home using Index

Are you following my point that you cannot home on any index signal that is not the axis motor encoder component? This severe limitation appears to me to be hard-coded into the method LinuxCNC employs for HOME_USE_INDEX, where the process involves resetting the axis encoder state. Hence the HOME_USE_INDEX logic cannot use the signals from a second encoder.

LinuxCNC is missing some theoretical logic. The homing signal should be configurable as a switch (step function) or index (impulse function). This factor should be independently configurable from the configuration of the signal source.

The current LinuxCNC logic restricts these possibilities, requiring homing switches to be step functions. To accept an impulse function, LinuxCNC requires it to be the index signal from the motor encoder.

My workaround is to add HAL logic that turns an impulse into a step.

My goal is to use an independent DRO scale to precisely refer the axis home, including in the automatic homing process. While LinuxCNC features a homing method based on an index pulse, I've concluded that method prohibits the index signal coming from a second independent encoder like a DRO scale, versus the index of the axis motor. I could not find by experiment any HOME_USE_INDEX method that would work with the DRO scale. Although the setup would initially scan for and validly detect the home position, the LinuxCNC hard-coded homing logic seems to apply some magic to the primary encoder state to make the final moves, which winds up leaving the axis at the random starting location instead of the newfound home.

I'm not fully following why you can't use a DRO scale to accurately home? The homing sequence with index needs a home switch that is configured to be triggered 1st then linuxcnc looks for the index signal. You can specify the final home position. It shouldn't be random.
linuxcnc.org/docs/html/config/ini-homing.html#_home_use_index

Why not use the index signal off the scale and use that as a home signal? No need for index homing. Unless you have repeating index along the linear encoder.
The index homing as I understand it is for improving accuracy in homing sequence if you have a rotary encoder with index on the motor or screw and a lower accuracy mechanical home switch such as roller micro switch. Why would you want to read in both the motor index and the linear scale index?

I'm not fully following why you can't use a DRO scale to accurately home?

Because LinuxCNC's logic about homing is not properly designed. LinuxCNC requires the home sensor to provide a step function of the home position, not an impulse. LinuxCNC's HOME_* configuration variables are both overloaded and incomplete. LinuxCNC's model of homing logic is faulty, and it only works for certain special cases of hardware. Of course the project effort proceeded from having to cover whatever machines the developers had in hand.

Bless the LinuxCNC authors for implementing homing, but the design is not a general theoretical model of homing. Another aspect of this deficiency is that homing is just a special case of probing, yet homing and probing are separate features in the code. I suppose the design could be done over properly, but it's embedded deep in the core of the realtime motion code, and that makes it fragile to improvements.

Why not use the index signal off the scale and use that as a home signal? No need for index homing.

Yes, that's what I have achieved. My post is propounding that it can't be done without a workaround, because of the step function vs impulse function misfeature of LinuxCNC. My post is a HOWTO for the workaround (trick of turning the DRO index impulse into a step, using HAL hackery).

Do the linear scales output index and quadrature? If so you could use them for the axis position feedback in to LinuxCNC (with index-reset homing) and use the motor encoders for the position PID. (I think this would work, but it's late here....)

No, the DRO scales can't supply any PID feedback due to hysteresis in the table position (what the DRO reads) versus the motor position (what the motor encoder reads). PID feedback is necessarily unstable around the magnitude of hysteresis (both mechanical and discrete Nyquist). If the magnitude of mechanical hysteresis (such as backlash) is, say, a few thousandths, then PID will bang around (dither) for some multiple of that magnitude. Thus another type of control loop must be stacked above the PID loop, one that is one-sided with retry, basically an inverse characteristic function of the discontinuous hysteresis function.

Homing is a theoretical concept, basically stacking another layer of feedback loop (single-sided, low-bandwidth, with retry) temporarily on top of the PID loop. It is all rational and logical if the control theory is understood, but the problem is that LinuxCNC treats PID motion with proper theory, but the homing model and implementation are an ad-hoc mess instead of following the hysteresis-loop theory. Fortunately, HAL hacking provides a means to work around the logical deficiencies; one hack fixes another hack, making the DRO-homing objective feasible.

The LinuxCNC "two-encoder problem" is another manifestation of the missing theory.

Because LinuxCNC's logic about homing is not properly designed. LinuxCNC requires the home sensor to provide a step function of the home position, not an impulse. LinuxCNC's HOME_* configuration variables are both overloaded and incomplete. LinuxCNC's model of homing logic is faulty, and it only works for certain special cases of hardware. Of course the project effort proceeded from having to cover whatever machines the developers had in hand.

Treating index as an impulse that's reliably visible to HAL works in the parallel port /GPIO model with a high frequency base thread but fails when high resolution encoders and hardware encoder counters are needed, Its standard for hardware encoder counters to either reset or latch a count at index and provide a flag indicating this occurrence.

Since LinuxCNC was designed around actual encoder hardware, the latch/reset + flag detection scheme seems
like a reasonable design decision.
Support of PC parallel port hardware/base thread configurations occurred later in LinuxCNC (well EMC) development.

I was not suggesting using the scales to close the servo PID loop, I was suggesting using them for the position feedback to the LinuxCNC feedback pins used for actual position display and for homing calculations.

That's indeed my strategy. It doesn't work to simply connect the DRO index signal to the axis.N.home-sw-in as one would expect to work. The impulse-to-step divider workaround is required.

This does involve using two encoder counters, one for the motor encoders closing the servo loop, and the other (with index reset) used for homing.

No encoder is involved or required (other than whatever makes the motor move). An ordinary homing switch doesn't involve a encoder, and synthesizing a switch action by dividing the DRO index pulse, likewise.

A DRO scale is really two independent devices, one that senses motion, and a second that senses absolute position. The motion sensing doesn't play in homing. The system homes to the DRO index even when the A/B phases are disconnected. Which I have to do because of scarce parport input pins!

You can get by with one pin sharing all the indexes of the DROs and the spindle, similar to wiring homing switches in series to one pin. It just takes logic gates instead of series wiring to hook it up.