Getting started with 6i25+7i75+7i85s

If you can jog Z faster than 150 mm/m the likely culprit
is the spindle encoder or spindle encoder interface.
(that is, it's probably not Z that has the issue but
encoder mis-counting above a certain RPM)

The lack of spindle sync also suggests encoder issues.

You might do some basic encoder checks:

Is the encoder RPM correct at all speeds?

If you enable quadrature error checking, do you ever get errors?

if you check the index, does it always zero the position and the index location?
 

Spindle speed feedback is correct for any rpm, though erratic, as seen in the screenshot. (100 rpm)
What's quadrature error checking? I did try adding FERROR to to the spindle, but that does seem to do anything, even if the spindle gets stalled.
Which pins exactly should it zero? It does not zero spindle.0.revs at least.
In the second screenshot, you can see the perhaps relevant signals when the photogate is a the index position. When moved, hm2_5i25.0.encoder.02.input-index changes, but the other ones do not.

I do have

net spindle-index-enable     <=>  hm2_5i25.0.encoder.02.index-enable
net spindle-index-enable      <=>  spindle.0.index-enable

In the hal file, but clearly it does not nothing since hm2_5i25.0.encoder.02.index-enable does not change state when the index is active. Is this where my problem lies?

Found the problem now lol. My encoder and spindle index are connected through an original pcb within the spindle housing, and I got my wires crossed and read the index coming from the encoder, which is connected with a 3:1 ratio, giving me 3 index pulses per spindle revolution.
That's that mystery. I will see if fixing that also takes care of the low maximum speed.

OK glad that's at least partially sorted out.

Note that the index signal does nothing unless index enable is set true
(LinuxCNC sets index enable true when it wants to search for index)

You can test index operation by hand running LinuxCNC, and

halcmd sets spindle-index-enable true

Then rotating the spindle by hand. When the index is detected, 2 things should happen:

1. spindle-index-enable should change to false

2. the spindle position should be set to 0

I connected the correct index and the machine threads beautifully with no problems when restarting a program or running at higher speed.

I still have another complication with the encoder, though. As it has quite a high resolution for the application (I don't know why they used such a high-resolution encoder and made it even higher with the 3:1 transmission), the pulse frequency maxes out at about 2200 rpm, after which no signal is sent. This of course means that linuxcnc stops feeding motions, since it reads the spindle speed at 0.
The problem would be easily solved if I could tell linuxcnc that beyond, say, 2000 prm of commanded spindle speed, it would switch to reading the speed from the index.

But I am also considering removing the encoder and installing an encoder disk directly on the spindle. The belt does not track too well anyway and makes some extra noise. A couple hundred ppr should be plenty for threading, so I'm not really losing anything by lowering the resolution, right? I doubt I would ever be doing indexing on the machine, as there is no spindle brake and it is driven by a pretty flimsy v-belt.

If the index had a high enough duty cycle that you could use the software encoder
you could use a little hal magic to switch the RPM source from hardware encoder to
index only software encoder at some specific commanded RPM.

I played around with an oscilloscope, and it turns out the encoder outputs pulses just fine regardless of exceeding the maximum frequency described by the datasheet.
So I set the encoder filter to 0, and now it reads the rpm correctly.