7i77-ISOL in Master RT is, Well... Acting Skewy

FYI, there appears to be a bug in master-rt related to setting the encoder mux skew. You can set it in your HAL, only to check and see the value disappear. It also seems to get nibbled away when you do a homing sequence. As a result, I wrote a quick userspace component, appropriately called skewy, to keep tabs on the value of hm2_5i25.0.encoder.muxed-skew and reset it to the configured value whenever it wanders off.

Disclaimer: The attached file is a total hack job workaround and I make no guarantees that it won't cause your machine to implode and the world to end, so use it at your own risk. Hopefully its usefulness will be very, very short-lived and the bugs causing this value to be overwritten on startup and decremented during homing will get fixed quickly. It appears to decrement when you trip a home switch. Its a runaway issue just waiting to happen. Thank goodness my machine was already past PID tuning and I have tight f-error limits or I would have learned that the hard way.

Can you post yout hal/ini files?

A temporary workaround is to just lower the encoder sample rate rather than set the skew

Sure thing. INI and HAL attached. I can't really lower the frequency because at 4mhz, I end up having to either clamp feedrates or dial back my encoder resolution or else I get into runaway territory on that front.

One quick observation is that the thread order is wrong
it should normally be:

hm2_5i25.0.read
everything else
hm2_5i25.0.write

If you turn off the encoder filter bits you should be able to lower the encoder sample frequency to about 1/5
of what's required with the filter on (filter on = 15 clock filter, off = 3 clock filter)

Good catch. I wasn't even thinking about execution order. That stackup would set back the execution order for an entire cycle, allowing for error to build. While I doubt its the culprit, that definitely needed corrected. Thank you

Given some of the other noise, do you think having the lower clock frequency without a filter would be preferable to the faster sampling with the filter enabled? I'm used to thinking in terms of sampling bandwidth on a scope, where if you get the sample frequency too close to the signal frequency, dithering starts to come into play. I know i'm thinking of it in analog terms versus the digital, differential signal here, but figured it worth asking. I'm used to following the 10x sampling bandwidth rule.

There is a digital filter in both cases the filter bit really just changes the filter time constant from 3 clocks to 15 clocks when set. Digital encoder signals really only need to be sampled at greater than 2X the _count_ frequency

On the skew setting bug, I cannot duplicate this on Master with an Ethernet connected card.

It's normal for the setting to be truncated to integer clock cycles (its arguable that it should be rounded instead)
This is why your setting will be truncated to multiples of 30 ns ( a 5I25s 33.333 MHZ clocklow sets the skew setting resolution)

It may be that the Ethernet cards higher clocklow (100 MHz) and 10 ns settability makes a difference, I will try this on a
5I25 tomorrow

Here's the behaviour i noticed

setp hm2_7i76e.0.encoder.muxed-skew 135
(pin show 130)

change some other encoder setting (like index enable) to simulate encoder updates as homing would

(pin still shows 130)

The behavior I was seeing is that I would set the pin value in the HAL and upon starting linuxcnc, halmeter shows the skew at 0. I would then set it through a halcmd via the terminal. In my case, 109 results in a set value of 90. Since 120 is closer to my target, i actually ended up setting it to 121 (odd that setting to 120 yields 90 as well) I would then start my homing routine and upon hitting the Z axis home, the value dropped to 90. It then dropped again when it backed off. when it tried to home x, it made it to the initial touch of the home switch, dropped to 30 and then tripped out on f-error, presumably because the skew had gotten to the point where the encoder signals were out of whack.

I'm running the latest build available through the apt repository. 1.2.8.0-pre1,3493.ge1f42bf
Would it be beneficial to put out a 6i25 version of the bitfile to bump up the clock to 66mhz on the bridge and provide some additional resolution?