Yaskawa incremental encoder and Mesa 7i48

I am in a process of retrofitting Biesse Rover cnc machine to LinuxCNC and now Iam up to getting encoder signals read directly by LinuxCNC via 7i48 board (so far I was using the original drives that output the encoder signal to cnc controls).I started with Y axis motor - Yaskawa USAGED-13A22 motor with UTOPH-81AWF encoder (it has 8192 CPR).
What I did was ordering a matching plug from ebay and soldered 8-leadwire to it while other end of the wire was connected to plug on 7i48 so the original wiring of encoder is intact and I can always plug it back in original drive.I am not totally sure that the wiring on 7i48 is 100% correct because the original documentation of the machine does not show meaning of pins: 


So I did some guestimate there according to servodrive manual that mentions channel A, channel B and channel C. 


Channels A and B seem to work exactly as expected - I get approximately 32K rawcounts per revolution (I did not measure very precisely start and end position) but supposed index channel is living its own life. I did some video:

I thought that my adapter wiring is wrong. Checked with multimeter butthere are no shorts between any 2 wires. Plugged back in original drive - everything works and I get nice index pulse once per turn so it seems that this is the way it is supposed to work.I also found this thread mentioning that Yaskawa 5V encoder has to be decoded. www.forum.linuxcnc.org/27-driver-boards/...coders-plug-and-play
I have yet to understand what is there to decode for incremental encoder (that is supposed to be incremental because of digit "2" right after letter "A" in the name of motor) if both phases have quadrature signal but that is rethorical question.

It seems strange that servodrive manual would name the third channel as "channel Z" for absolute encoder and "channel C" for incremental encoder given that standard designation for index pulse is letter Z. 


What are my options at this point? All I need is an index pulse for BLDC module to home the rotor and get the phase alignment right. I do not even need the index for homing joints, that is optional.

It seems mis-wired to me.

You might verify that you get a sensible voltage
(say about +4V or -4V) in both polarities  when
measured across the pairs (A to /A and B to /B and C to /C),
For all positions (and never a voltage close to 0)

A voltage across a pair close to 0 means a mis-wiring
 

Actually I had checked with multimeter - ALL pairs had 3,3V on one and 0,5V on the other wire. and vice versa when HalShow reported that the pin value has changed.
I googled for rs 422 voltage levels and this picture came up:
advcloudfiles.advantech.com/cms/2fde048f...ge-1540322331041.jpg

According to last line everything is correct at the moment, so I do not even understand where to start to look for miswire - all the pairs behave the same.
Am I missing something and is that picture wrong?

You really need to measure _across_ the pairs
to validate the wiring

A long time ago I tinkered with some Yaskawa drives and motor/encoders. What I THINK they do is change the phase between the A-B and C channels to indicate what quadrant the motor is in, and that allows them to detect the proper commutation to use to move from that position. So, the A and B are perfectly standard quadrature, but the C channel has transitions at the same rate as the A or B channel, but the phase gives additional information.
Jon

I vaguely remember seeing that one
The documentation I looked at had C=index
(and S = serial absolute position)
but that must be a different model

If that's the case, you will likely need
to use plain q mode (magnetic alignment)
rather than QI mode

    I recently had a terrible time trying to implement an older (90's) Yaskawa servo motor with "incremental" encoder UTOP1. It would run rough in one direction and smooth in the other with an AMC brushless drive and 7i77. I opened the encoder cover and found odd looking tracks (see 1st and 3rd encoder band on picture). I'm curious on the purpose of it? It's clearly not a standard incremental evenly spaced grating. The additional 3 sections that repeat 4x I assume are the commutation hall signals and the inner 2 are the index. Maybe open yours and see if the tracks are odd looking?  

I spent quite a few hours yesterday watching A, B and C lines (as well as rawcounts value) in HalScope and I found a nice pattern there. I have created excel spreadsheet where I tried to draw those graphs with cell boarders and also wrote the rawcounts values at which those transitions take place (basically only transitions are shown, everything in middle is ommited).
docs.google.com/spreadsheets/d/1M04yZmUE...2&rtpof=true&sd=true

I have plotted full revolution of motor shaft, there are 24 transitions (25th is the same as 1st). The pattern repeats 4 times (that is 8 pole motor - 4 electrical revolutions), so pattern is divided in 6 parts of similar length.I should note that difference of rawcounts between 1st and 25th transition is slightly more than expected for 8192 CPR encoder, but I was having realtime errors as I tried to use TightVNC to connect to the LinuxCNC PC from my laptop so that I could see the screen (most importantly - numbers there) while standing near the motor and turning it. But it was so slow on updating screen that I ended running back and forth to the PC anyway.

One more thing - there were several occasions where I noticed strange spikes in C graphs. At first I thought that those are glitches etc, but at one time when I saw it again I tried to catch that place again in HalScope. So I got 3 repetitions and all 3 attempts show a spike there so that makes me think that something similar to index pulse is integrated in C channel (I have attached all three log files for this spike, it is between rawcounts 33658 and 33659, I changed the extension from csv to txt, because adding csv files is not allowed).I did save log files for almost all other transitions as well if that helps (forgot to save 2 or 3 due to lack of concentration as it was around midnight).

Is there any chance to get anything meaningful out of this? I would like to think that this pattern can be used similarly to Hall sensor feedback.

And this thread alone shows that I am not the only one who would had liked to use Yaskawa motors (I have one more machine that will need replacement of at least 2 drives and one previous retrofit that also is not working anymore because of drive faults and would need to be reanimated).