HAL for open-loop encoder homing

 Thanks for a firmware. I will try. And this firmware will work with option of use of the encoder for use of feedback by situation? This assembly now so works for me but it is not possible to configure well PID - when there is a processing on three coordinates not the really good surface of processing at once. If there is a processing at the same time on two coordinates purity of processing acceptable. On the milling machine a heavy table. Earlier I managed this Mach 3 machine and at small speeds the processing on three coordinates gave at once a good surface.  I want to try to make also and in Linuxcnc with exact search of the house by encoders.

I should note that a closed loop linear encoder feedback system will be difficult
to make stable unless you can remove the backlash mechanically...

Thanks for the help!
Actually, ChatGPT helped me find an error in the INI file for my closed-loop system (which I attached earlier).
There is a line for initial settings: `RS274NGC_STARTUP_CODE = G21 G40 G90 G94 G97 G64 P0.025`. By adjusting the `P` value within the `G64` command, you can fine-tune the surface quality. I achieved the best surface quality with `P0.005`. I haven’t tried your firmware, as I’m currently satisfied with the surface quality I’m getting. Thanks again for your help!

I've got a very similar setup on my lathe, and while that's not a milling machine, the setup has a lot in common.

I have a Chinese glass encoder on the Z axis and a magnetic encoder buried in the X axis (under the cross slide). The Z axis has an inductive (technically eddy current) proximity switch for homing and the X axis has a microswitch.

Those both work in closed loop. I don't use backlash compensation but the axes used NOS, Japanese ground ballscrews.

I spent several hours recently implementing "index mark" homing on both axes, using the synthesised encoder outputs from the servo drives and perhaps surprisingly there was no obvious benefit, so in the end I simply reverted to using the limit switches.

This is partly due to the way the index pulses are read by the 7i85, but then subsequently processed by Linuxcnc. I also suspect that some of the remaining variation is in the mechanism between the servo motors and the actual axis ie toothed belt, ballscrew, bearings, mechanical slop etc.

When you look at it that way, it doesn't seem obvious that moving the servo motor to a particular angular position after homing to the switch would necessarily deliver any obvious benefit. Either way, repeated testing with a decent DTI showed clearly that while the system was working, it didn't improve the homing repeatability or accuracy in my case.

This outcome may differ with your machine. Mine can only resolve / achieve 5um repeatability due to the encoder resolution and although I have good ballscrews and the machine is well adjusted, it wasn't built as a CNC machine, so is perhaps not the optimal choice.

For reference, here are some results showing a comparison between the original proximity switch homing and the "index gated" implementation.
 
The "optimisation" process produced the biggest improvements which were the result of finessing the PID values and slightly reducing the homing speed to minimise the delay between reading the index pulse and processing the data. Both methods were significantly improved this way but the end results were almost identical.
For the test setup, I repeatedly homed the machine (typically 20 times, as shown), with the absolute position automatically logged and plotted.

It sounds like you are not using the index hardware at all.
There should be no effect of LinuxCNC timing or PID tuning
on the index position homing precision, if the index hardware is
actually used.

That is, the precision of position capture at the index position is
independent of the motion accuracy, though of course motion accuracy
after the index position is captured _is_ dependent on PID etc.