Homing To Index Following Error

I have a 4 axis router with step/dir servos using a 7i76EU+7i85 to command the servos and read the encoder feedback.  I have the servos reasonably tuned running closed loop.  But I'm seeing a following error spike on homing to index for the W axis (XYZW) on the first attempt at homing the machine after power up.  After the initial encoder position reset on the homing index it will home fine the 2nd try and works after that. If the machine was parked at the W-zero location when Linuxcnc is turned off and started it does not do the following error.  For some reason it seems like Linuxcnc is not ignoring the F-eror on the encoder index reset for the W-axis like it should.  Any Ideas how to fix this?

Here are my main hal and ini config files.
 

Here's a Halscope shot of it.
 

Here's another Halshow screen shot showing the index input.
 

What LinuxCNC version is being run?

There was an encoder index bug fixed Nov 2022:

github.com/LinuxCNC/linuxcnc/commit/6bf6...afbf95c84f4fbb44f138
 

It's the current release 2.9.7

(Edit)
Had to go look at what was actually on the machine, and it's 2.9.8 running on Debian Trixi.

Looking more carefully at the HAL  file I suspect that it has to do with the offset component
or offset thread order.

EDIT:

Don't the mux components need to be addf'ed  before the offset component?
(since their outputs are used by the offset component)

This is also suggested by the fact that this only happens on the joint with offset applied.

I understand that is a potential problem, but it was doing it before I added the offset comp.

The offset, is used for my temporary slaving set up, so that I can run files that only have Z axis code with both the Z and W spindles.

Can you remove all intermediate joint 3  hal code and see if the problem remains?

Because of the stepwise change in encoder feedback at index any thread order problem
will cause a large following error spike with any pipeline delay on feedback or command.

I'm making myself a liar. Just went and commented out everything for the slaving and reconnected the old command and feedback signals and I tried power cycling and homing twice and it didn't error.

So, maybe it is because of that. I really did think that I was having these errors before I started adding the stuff for the slaving. Unfortunately I'm not sure that it is going to be possible to prevent what I need to do to slave the axis temporarily without causing either the position command or feedback data from becoming one or more thread cycles old.

Do you think simply rearranging the thread order could work? Any suggestions for a better order to addf the components?

I re-examined the flow of the commands through the components I'm using for temporarily slaving the W to the Z axis.  Then I reshuffled the addf order a little more appropriately and now it seems to be working.  

Thanks.

Here is the hal file that is working better.