1Vpp Encoder to Mesa 7i33

I want to connect sin/cos 1Vpp encoder to Mesa 7i33 card. Since this card accepts just Quadrature encoders, I am kinda stucked.

The encoder I got provides 128ppr sin/cos therefore I need also some interpolation 16x ideally.

I am aware of aftermaket interpolation units e.g. from Heidenhain, but they are bit pricy to me.

Does exist some solution to this requirement?

We intend to make a little DSPIC interpolator but have not finished it yet

This chip will probably do if you are circuit board handy:

www.ichaus.de/product/iC-NV

Also Heidenhain interpolators show up on Ebay occasionally

Oh nice, the IC-NV chip looks very promising. Thank you. Costs €6.5 a piece. I can share my progress later with it.

Just wondering, the encoder also provides HIPERFACE 24-bit absolute prosiotion interface. Is there any use for it in LinuxCNC? Maybe for DRO or Homing?

As I plan to use a AC servo with this encoder to be driven by 8i20 I guess, that incremental pulse positioning its just fine.

To use those chips you will need an op-amp input to level shift the 1V signals to 2.5V (VCC/2) so not quite a single chip solution but almost

The Hiperface absolute interface could be used to get commutation started right but it may be a fair amount of trouble to implement

I just measured the encoder and he gives:

A+ : 2.0-3.0V
A- : 2.5V

So I think I dont need any extra op-amp if not misstaken.

On the other hand, the encoder needs 7-30V, so there will be charge-pump IC to feed him. MAX1680 mostlikely.

To be precise, the encoder is SKM36-HFAO (Sick/Stegmann) and AC motor Rexroth MSK-040C-0450.

pavel7890 wrote: I want to connect sin/cos 1Vpp encoder to Mesa 7i33 card. Since this card accepts just Quadrature encoders, I am kinda stucked.

One possibility might be to use an Arduino to measure the analogue voltages and convert them to a quadrature pulse stream.
Something _close_ to what is needed is here:
wiki.linuxcnc.org/cgi-bin/wiki.pl?ResolverToQuadratureConverter
You wouldn't need the PCB, just some of the Arduino code. (though you might want to consider changing the Vref)

Yep Andy, I already was considering this way as I have AT91SAM7S256 dev board. It can also incorporates Hiperface interface as absolute positioning. To be honest its a bit tricky and time consuming way compared to "offshelf" IC-VN chip.

There is just one open question for me regarding BLDC hal component and 8i20 driver card linked to need of absolute position.

8i20 should know rotor position by hall effect current sensing? If yes, how I get this information to BLDC to be synchronized where the rotor actualy is? Maybe I am lost in understanding of the principle, I am sorry for that.

pavel7890 wrote: 8i20 should know rotor position by hall effect current sensing? If yes, how I get this information to BLDC to be synchronized where the rotor actualy is? Maybe I am lost in understanding of the principle, I am sorry for that.

I think you may be confusing two uses if "Hall effect"
A typical brushless motor has Hall sensors in the motor to feed-back the absolute rotor position.
The bldc component watches these signals changing and uses the first transition that it sees as an absolute reference, and then switches to using the encoder value to give a more fine-grained position.
If your motors have a Hiperface encoder it is possible that they don't have Hall sensors, which may make getting an absolute position reference rather more difficult (Hiperface might be the _only_ way if the encoders have no index pulse.)

The blcd can do "bump" alignment, but that isn't very reliable under load.

The Hiperface documentation describes: motor shaft aligment with absolute position has to be stored just by manufacturer and never changed by user. I cant justify this by now, but if this is true, I can use absolute position from encoder to sync quadrature counter before BLDC.init and there should not be any bumb.

I just proceed with Hiperface encoder RS485 interface with positive results. Its in principal easy to understand and implement into HAL.

I am just curious about one interesting feature of the encoder. I tested absolute positioning by shaft turning after power off. I would expect that after power on, the encoder can provide shaft position within 360 deg, but he was even able to provide number of revolutions too!!

How this can be done? There might be a battery or some kind of different mechanism I do not know about.

Anyhow, this feature gives me perfect feedback not only for commutation but for machine positioning after power on.