ABS Encoder Posital 7i92T bit file help

You need a real scope to check the clock and data
(halscope can only sample at the servo or base thread,
way too slow for 500 KHz signals)

Tom , you’re racking up points all the time with me. The most recent was the other day, you helped another member some years ago with a SSERIAL board not communicating. “try another cable” you said. It saved him and you saved me probably hour(s) of troubleshooting the wrong areas. I swapped cords and my sserial board suddenly worked. I don’t know why I had not questioned cat5 cables before. I always question every other connector -cable. So, A Big thanks on that!

PCW wrote:

You need a real scope to check the clock and data
(halscope can only sample at the servo or base thread,
way too slow for 500 KHz signals)

The clock seems to be working correctly, but the data signal doesn’t anything like a data stream.    I tried inverting both clock & datad but it didn't seem to help.  I’m thinking the encoder is configurable and maybe its last configuration was set at a different clock frequency.   Maybe its not registering the clock pulses.   I’ll contact the distributor to see if there’s a config setting for the clock.   I know they sell a db9 – usb module for configuring and troubleshooting these things.  I might need to get one.

 

PCW wrote:

Comment out this line:

...
Also the 49 ms latency is _really_ bad so suggests a real time issue with the host
(maybe you don't have

force_turbo=1  in config.txt )

Disabling the base thread in the latency-histogram may give you better results:

latency-histogram --nobase --sbinsize 1000

 

I included the force_turbo=1  in the config.txt file and ran the latency-histogram with the parameters you provided.I loaded several other apps on the totally bare system evanlo  created.  Mabe I need to go back to bare bones once I finish development.  Do you think it will help Latency?I plan to use servo based systems no steppers.
-Doug

 

The latency looks fine.

SSI encoders should not be sensitive to clock rates
(as long as they are not too fast for the interface)

It looks like the data output it not being driven
which is not normal for a SSI interface. Is it possible
that there is a wiring error or the encoder is set into a
non-SSI mode?

EDIT:

Also your format string does not match the PDF you posted.
The PDF shows a total data length of 41 bits but your format
string only has 16:

ssi_chan_0=xpositol%16me

I would expect something more like:

ssi_chan_0=xpositol%33me%8p

(the 33 bits are 17 bits per turn + 16 bits of turn counts
and 8 pad bits for a total of 41)

 

Sorry for the delayed response I had an emergency troubleshoot / repair job that took over.Update on this effort-->Success!Yes, lots of opportunities for a wiring debacle.  Surprisingly, the wiring wasn’t the problem. It was the config string.I remember agonizing over what to put in it.  Knowing that “all bits need to be accounted for” and seeing the 33 bits in the documentation, but I just could not reconcile that against the 16bit resolution and padding bits…well... I just picked one of the two numbers to see if anything would work.  I’m pretty sure I was “channeling” tommylight at that point.   Then after L.cnc came alive I forgot to look back at that decision…very much a me thing.Peter, once again you saved the day.   You make this all possible for us non-computer science guys.  Thank you very much.Tom,   thanks to you too.   The work you have done and shared through the years for us to all see is inspiring. I’ve posted the chopped single axis hal file and some photos of the data channel on the o-scope.  I also confirmed these abs encoders don’t need power to remember their position,  I powered off for 5 minutes then made a 360 deg rotation then powered up and the counts increased accordingly.  Turning the shaft makes enough power to compute and save the position internally,  the “wiegand effect”.I’m going to get some of these on order, currently they have a long(ish) lead time.
-Doug