Homing To Index Following Error

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.

 

Yes, thread order issues might not be noticed except that with
the step in position on the first index, a 1 servo thread delay
in position causes a huge spike.

It is arguable that this position step should not be present in the basic
motion hal pins, but is needed for compatibility with encoder counter
hardware that clears the count on index.