Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

NI DAQ card for SinCos encoder?

Solved!
Go to solution

We have a heidenhain RON285 encoder which uses the 1Vpp signaliing for "infinite precision."  Essentially it outputs two differential Sin/Cos signals and the phase angle between them allows you to get extreme precision for the encoder angle.    You still need to send the two signals through a comparator with hysteresis to essentially convert it to a quadrature encoder signal and count the pulses.  The phase angle calculation gives you the fractional precision.  

1) Has anybody ever used an NI DAQ card to read in the raw voltages and do the necessary calculations to convert the SinCos singal to a high-precision angle? If so, are you willing to share the code?

 

2) Can I do the SinCos --> Quadrature conversion on the card itself by forking off the two SinCos singals into two other channels and specify that those two channels are quadrature encoded singals or must I have external hardware do the comparator + hysteresis before inputting it into the card?

 

P.S.

I just found this piece of hardware which does exactly what I was describing in #2 above, can I get this same functionality by just using the DAQ card itself?  http://www.motrona.com/sincos.html


0 Kudos
Message 1 of 9
(7,010 Views)

Do you know the interface electronics from Heidenhain ?

For example IBV 101 and 102.

  • In = 1Vpp
  • Out = quadrature with 5 to 100-fold interpolation
Message 2 of 9
(6,986 Views)

1. Yeah, I tried doing my own Sin/Cos interpolation.  I'd call the end result "adequate, but kinda fragile."   It was probably 15 years ago though and back at another company so I don't have the code.  There wasn't really that much to the primary calculations, just the 4-quadrant arctan and a little care to hop over the discontinuities at +/- 90 deg.  I had a bigger challenge getting decent results from taking the derivative to find velocity.

 

2. In later years, I would just buy the interpolator from the encoder mfgr.  They'll have invested a lot of engineering into their packaged solution, surely more than I was gonna improve upon.  

 

I'd recommend spending a little more money to buy the interpolator rather than the time it takes to develop one. 

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 3 of 9
(6,948 Views)

So we currently have a Heidenhain IK220 PCI card that does the interpolation but the problem is this is the only card that is outboard of the PXI chassis.  All other data aquisition is done within the PXI chassis and we need to time-correlate the data.  We just realized that having the IK220 PCI card run at "1kHz" using its own on-board oscillator is not the best idea as it's going to have some clock drift with respect to the PXIe-4300 DAQ cards also running at "1kHz."  

 

The IK220 does allow for an external clock but no start trigger.  I'd much rather have the encoder position be aquired with a card in the PXI chassis so I can set up all cards using the same backplane source for the sample clock as well as a start trigger.

 

Unfortnately NI does not have a timer/counter card that supports SinCos 1Vpp input signals *but* based on JB's post I see they have a "plug type" adapter interface cable with 5/10/20/25/50/100x multiplication.

 

If i'm correct this adapter cable seems to be an ideal solution as it will allow me to use an NI timer/counter card (PXIe-6612) so that all my data is comming in to the same PXI chassis and time correlation will be a breeze.

 

If you don't mind I'd like to run some numbers through you guys to make sure I'm making sound decisions:

  • The RON285 encoder has 18000 signal periods/revolution (0.02 Degrees / signal period)
  • The RON285 has a system accuracy of 5 arc-seconds or 0.00138889 Degrees
  • We move the stepper motor that the encoder is attached to at a max rate of 40 steps/sec across 180 Degrees
  • If I set the multipication factor to 20, that puts our accuracy just about at the system accuracy (0.02 / 20 = 0.001)
  • Am I correct that it makes no sense to put the multiplication factor any higher than 20?
  • Does a factor of 20 means the quadrature frequency into the PXIe-6612 will be 800Hz (40 * 20) ?
  • Do I just create an encoder task and set the periods/revolution to 360,000 (18k * 20) and the task will do the math to give me the right position?

0 Kudos
Message 4 of 9
(6,940 Views)
  • We move the stepper motor that the encoder is attached to at a max rate of 40 steps/sec across 180 Degrees
  • Does a factor of 20 means the quadrature frequency into the PXIe-6612 will be 800Hz (40 * 20) ?

I just realized the above two bullet points dont really correlate since I didn't say what a 'step' was in terms of degrees

Our motor moves no faster than 9 Degrees / second.  With 18000 signal periods/rev that means 50 pulses / degree  (18k/360) or 450 Hz (50 pulses/degree * 9 degrees/sec).

  • So, if I use a multiplication factor of 20x that should mean the quadrature input frequency into the PXIe-6612 is 9000Hz (450 * 20), is this correct?
  • That seems to be well within the capability of the PXIe-6612, so I should be good; right?

0 Kudos
Message 5 of 9
(6,929 Views)
Solution
Accepted by topic author SeanDonner

The Heidenhain inline interpolator JB pointed to is exactly the kind of thing I've used from other vendors.  Yes, you can bring the digital quadrature channels into a counter and sync to the other DAQ cards in your PXI chassis.   The 9 kHz quadrature frequency is easily handled by the board.

 

Setting 'pulses per rev' to 360000 and choosing degrees for units should cause the task to do the math for you, i.e., when you call DAQmx Read the values should already be scaled to degrees.   Personally, I always do some sanity checking on this scaling value to make sure there isn't a factor of 4 discrepancy due to differing terminology between encoder spec sheets and DAQmx tasks.

 

As to limiting yourself to 20x interpolation, I mostly agree.  If the encoder error was distributed randomly, I'd fully agree.  But because much of it is probably more systematic than random, there's a *chance* that some further fractional resolution could be helpful.  Probably a pretty small gain at best though.  Unless it was pretty similar cost & lead time I probably wouldn't bother for > 20x.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 6 of 9
(6,896 Views)

Thank you very much for the confirmation.

I just noticed in the spec sheet for the inline interpolator (linked in my 2nd post) that there is a Matrix of Multiplication Factor vs Input Frequency. Other than a possible price increase, is there a benefit to getting the input frequency range as close as possible to what we will be sending in?

For example they have a 50x with 2.5kHz all the way up to 40kHz. If my input frequency is in the 500Hz range, do I get better accuracy getting the lowest 2.5kHz model at the sacrifice of flexibility of reading higher rates?


0 Kudos
Message 7 of 9
(6,886 Views)

I would expect those specs to be a maximum rated input frequency (of the input-side analog Sin/Cos signals).  I wouldn't expect an accuracy benefit from choosing a lower frequency rating, just a wallet benefit.  But I'm just guessing, you'd need to investigate with their docs or tech/sales support to be sure.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 8 of 9
(6,879 Views)

Will do.  Thanks Kevin


0 Kudos
Message 9 of 9
(6,874 Views)