MPG count going mad

The FPGA SSLBP code is the same (but is the same for all sserial devices and the code doesn't know anything about types, just data sizes)

I would expect after some usage that the rawcounts and position to be at some arbitrary larger number
so how they get to +-127 is perhaps a bit odd since the8 bit --> 32 bit extension logic could not get there easily
regardless of the raw sserial data (assuming it started at some big number)

The sserial data from the MPG is an 8-bit signed value (s far as I recall)
It gets extended to 64 bit by this code here:
github.com/LinuxCNC/linuxcnc/blob/master...mot2/sserial.c#L2040

I am starting to wonder if pin->accum is being used uninitialised. (and if that matters)

If you do see this behaviour occasionally perhaps you could add a "enable_raw"
token to the hostmot2 config string so the actual sserial registers could be checked
this would determine if the error is in the FPGA/SSerial remote or higher up

Okay so this problem returned yesterday. I took a quick video. Seems to be more random this time. First half of vid is with smaller units and second half with faster travel, larger increments selected. Next time what should I load or do that may be of better help?

TIA

What are the signal levels on the MPG lines in both states?

Sorry, which signal levels from the MPG are you inquiring about?

On the X axis I was switching between:
setp mux4.0.in2 0.0000010
setp mux4.0.in3 0.0000100

low pass scale is at:
setp ilowpass.0.scale 1000
setp ilowpass.0.gain 0.02

The quadrature pins on the 7I77 since this could possibly be a noise issue

Okay I will look at them the next time this happens again although I don't think it's noise. I restarted linuxcnc and the problem went away just like the 1st time. It was reversing in a similar fashion as before. Just not repeatedly at the 127 count. It's not the clearest video as I possibly was reversing the handwheel to get it to trigger at a specific number. Sorry for not pointing that out.
So far this has been noticed only on start up when I'm moving the X away from the home position. It's never happened randomly or after running the machine for a while. I also payed attention to not move the cord on the MPG to rule out a broken wire.

I logged the counts while turning the MPG slowly clockwise.

www.filedropper.com/7i73

And it appears that the pattern is exactly what you get if you gray-decode something that is actually straight binary.

codepad.org/djo4SJse

So it seems that either the 7i73 is wrongly claiming to be graycode, or a driver bug is wrongly deciding to treat it as graycode.

And it won't be the 7i73 claiming to be graycode because smart-serial knows nothing of graycode.

What I think is happening is that I am failing to set the graycode and no-wrap flags to zero in smart-serial. Those flags exist for absolute encoders, which re-use the same code for their runtime-confgurable pins.