Homing open loop steppers on encoder index pulse

Chatgpt and I have been working on this for quite a few hours now and I don't quite understand why this doesn't work with the out-of-the-box options... but I've learned a few things. If there is some easy way to fix this, please don't tell me. I don't want to know I've wasted all of this time.

JK, please do tell.

Here's what led me down this road:
1. Want precise homing.
2. Want to monitor for lost steps.
3. Full closed loop seems to be a no-go with the drive/motor/encoder combo I'm using. I may explore this more later.


Adding HOME_USE_INDEX = YES to the ini with stepgen it does a variety of very strange things. I can't give much detail on exactly what is happening because I've had some widely varying outcomes and it has been hard to track the exact cause and effect. It seems related to an issue with resetting the joint.x.motor-offset value at the wrong time. That's my best guess. I tried adjusting everything under the sun to get it working as expected and no luck.

SO. I think I have a solid solution. I'm typing it here to organize my thoughts before writing the hal and to share with anyone attempting the same thing.

The idea is to swap in the home switch input with the encoder's index-enable at the right moment. (When the index-enable is set high, it stays high until the next index pulse). For example with my X axis, the axis homes on the negative (left) side. The no-encoder homing procedure is to move left until switch trips, then move right until it releases and set 0 at that point. If I swap the home switch input over to the encoder's index-enable, see example below, after the first trip of the home switch the motor will continue to the right until the index pulse occurs and set 0 at that point.

From this: net min-home-x  hm2_5i25.0.7i76.0.0.input-xx  =>  joint.0.home-sw-in (normally low)
To this: net min-home-x  hm2_5i25.0.encoder.00.index-enable  =>  joint.0.home-sw-in (normally high)

The idea:

1. joint.0.home-sw-in needs to be connected to the home switch unless we're homing with the z pulse.
2. encoder.00.index-enable needs to be set (but not held) high at the moment the home switch goes high, and only while homing.
3. joint.0.home-sw-in must be swapped from the home switch over to encoder.00.index-enable.
4. after encoder.00.index-enable goes low, joint.0.home-sw-in must be swapped back to the home switch.

Logic layout (shorthand) tested and working:

home-switch > and2.in0
is-currently-homing > and2.in1
and2.out > toggle.0.in
toggle.out <=> encoder-index-enable
encoder-index-enable > or2.in0
home-switch > or2.in1
or2.out > joint.0.home-sw-in

This works although there are some issues when it comes to the feedback. Using encoder feedback (not with a closed loop PID) with joint.x.motor-pos-fb throughout the homing process doesn't work. Something about the timing causes a following error... if your following error is set reasonably tight anyway. SO. I found two options to solve this and they both have caveats.

Option 1:  Use stepgen-pos-fb only while homing, and the encoder the rest of the time. Gives you following error protection unless the axis is currently homing. Caveat is that if you estop and the axis moves afterwards, more than your allowable following error, linuxcnc will pop the following error and it won't go away until you restart.

Option 2: Use stepgen-pos-fb unless the axis has been homed. If homed, use encoder feedback. Using this in conjunction with "VOLATILE_HOME = 1". This keeps linuxcnc from popping a following error after returning from estop, because the machine will be unhomed after an estop which puts it back into stepgen feedback. Caveat is that you won't have following error protection until the axis is homed. This also requires an extra hal component (tof) to deal with the timing issue that has plagued me with following errors.

Logic layout (shorthand) for swapping the feedback, both tested and working:

Option 1-
stepgen-pos-fb > mux2.in1
encoder-pos-fb > mux2.in0
mux2.out > joint.x.motor-pos-fb
joint.0.homing > mux2.sel

Option 2-
stepgen-pos-fb > mux2.in0
encoder-pos-fb > mux2.in1
mux2.out > joint.x.motor-pos-fb
joint.0.homed > tof.in
tof.out > mux2.sel


Here is the actual tested and working code:
INI



Hal



Custom Hal, Option 2 shown


For reference and context:
This particular machine has a single limit switch on either side of each axis. One side doubles as a home switch with "HOME_IGNORE_LIMITS = YES" in the ini. 3 axis router, axis GUI, LinuxCNC 2.9.6, Mesa 5i25, 7i76u on P3 and 7i89 on P2.

The easiest solution for Mesa hardware is to use firmware that
includes stepgen index, then the stepgen hardware mimics encoder
behaviour at index detection.