Elumatec SBZ 130/01 retrofit

HI Andy,
Yes that is what i get, and i can see the pulses with halscope, tested for 3 hours today to get something useful out of it but no luck.
This is with the spimdle encoder, same typea are on all axis except the long X, but different revolution counts. Not to be mistaken for counts per revolution.
Axis encoders are 4096 counts per revolution and can count up to 4096 rotations.
Spindle encoder is 4096 counts per revolution but can count only one rotation.
Long X axis is 4096x4096 but has another wire fro direction.
Found the above attached pdf, so they are SSI and grey code, also the frequency is recomended to be at 200kHz. Nothing on the pulse train info.
Tested all i could think off but no matter what, it gives fuzzy readings, and at a certain point in rotation, it just stops sending pulses, so i gues it must be lower/upper type.
I did find another thread on this forum today explaining some other SSI encoders that had a different way of functioning in hal, active users were PCW, you, and another member. At first glance it looked way more complicated than the hal settings i am using, so i might give that a try in a day or two.
Thank you,
Tom

What is your config string at the moment?

And is it possible that the data is bit-reversed?

Well as PCW so nicely put it, i am in the dark, bumping into walls, nose first!
I am having a coffe now so using the phone, i will attach the hal file, basicaly i used a section on the SSI encoders something something thread, started by Tero ( forum name Terkaa ).
There is a loadtr section with the ssi.1=xencoder%32ge and setings for clock rate etc and the fedback part in the X axis section.

xencoder%24gexpfb%1b

I think. 24 data bits, one fault bit.

PCW, i did try 12ge with the spindle encoder, got nothing back, with 24ge i get random readings, with 32ge still random but less jumping on the dro.
I did not test the axis encoders, i have to do that tomorrow. i did connect them today to the configured port but i got no response from any of them, more investigation is in order.
I did all testing on the spindle encoder, i testet changing rawcounts to count> no noticable difference, changed clock frequency>100 kHz not good, 200 up to 800kHz works as noted above.
added ssi.countsperrevolution no noticable change,
tested with added "s, l, f, u" etc as per hostmot2 manual, some noticable change in halscope, not usable
under some combination of the above, got the dro to count UP regardless of the direction of the spindle.

If i am not making much sense, sorry, i did not sleep from yesterday 11AM, so running on fumes now.

p.s.
at some angle the dro starts to go up slowly to a certain point then just shoots up to sky high values, and sometimes only sometimes could go back before reaching the shooting point.

andypugh wrote:

xencoder%24gexpfb%1b

I think. 24 data bits, one fault bit.

Will try that tomorrow for sure.
I did try error%1xencoder%32ge linuxcnc would not start
removing e from encoder line hangs some part of linuxcnc so must restart the computer.

PCW wrote:

If the spindle encoder is 4096 counts, it pretty much has to be 12 bits (perhaps with a fault/pad bit)
I would try %12ge on the spindle and try both clock polarities first and then data polarities

(by swapping the CLK+ and CLK- wires and the DATA+ and DATA- wires)

Asking 32 bits from a 12 bit encoder is just going to give you bit-hash

I did change the wires, but i had it set at 32 bit when i did. More fun!!!
Will test tomorrow and report back.
Thank you very much.