Yaskawa incremental encoder and Mesa 7i48

It is said in there that it takes 40 us to send that message and if I understand correctly it sends 15 pulses. so something around 3 us per pulse which is 300-400 kHz range?

If you are looking to drive this motor with a generic drive, in my case an AMC AB30A200I, I gave up on the UTOPI encoder and fitted a US digital EC35 that has digital hall with 8 pole option. It works smooth CW/CCW just past 3000 rpm but have possible torque ripple at very slow rpm. I was getting the same slow speed behavior with the stock encoder. Is this possibly due to trapezoidal commutation? Drive manufacturer couldn't enlighten me further...
The test setup uses another encoder in the video, disregard that. You can hear the clicking and I'd like to know if that's normal with trapezoidal commutation.
I wanted to share this in case you are thinking of going a similar route. I'm just not 100% happy with the outcome.

Yes, low speed cogging is almost certainly an issue with a 6-step drive, that's why the high-end drives use sinusoidal or at least trapezoidal schemes. The 6-step drives abruptly cut off current on one winding and jump to the next winding, and that causes a disruption in current as the commutation takes place. Motor inductance prevents the current from resuming right away. That click-click-click sounds to me like a 6-step drive. Most of the time, when coupled to a machine axis, these clicks have very little effect on position.
Jon

jmelson,

Thanks for that explanation. The AMC drive spec lists trapezoidal. Is it possible that it's more pronounced on a high inductance motor? 

Yes, I would expect so. More inductance means it takes longer for the last-used field to drop in current and the just activated field to ramp up the current.
Jon

Question for Peter Wallace - is it possible for 7i48 board (or more probably - the FPGA board to which the 7i48 is attached) to read that series of pulses on encoder startup and report it in some way? I have no idea how actually it is done but my idea is to hardcode that pattern and then make a comparison with actually received pulses and just tell which the 6 segments of that pattern is there.
Encoder power comes from 7i48 board and that gets powered with PC, so the pulses are sent way before LinuxCNC is started. Or should I introduce some "encoder power cut-off" relay to force it to resend the pulses when LinuxCNC is running?

Aciera do you have any idea if there is more detailed description available about the C channel patterns of Yaskawa encoders?