Multiple Buffered Inputs with Quadrature Encoders, and finding derivatives...

[Ixstala]

Hi.

I'm using the 6601 and VC++ with nidaqmx. My board has 4 counters.

I have 3 quadrature encoders on my device. I want them all to be synchronized by an external clock so I can take derivatives of the buffered measurements.

So far I configure one counter to generate a pulse train, then set that to the gate of each encoder channel. Here's the code:

DAQmxCreateCOPulseChanFreq(taskHandle,

"Dev2/ctr3","",DAQmx_Val_Hz,DAQmx_Val_Low,0.0,rate,0.50);

DAQmxCfgImplicitTiming(taskHandle,DAQmx_Val_ContSamps,1000));

DAQmxCreateCIAngEncoderChan(taskHandle1,

"Dev2/ctr0","",DAQmx_Val_X4,FALSE,0.0,DAQmx_Val_ALowBLow,DAQmx_Val_Radians,4000,0.0,"");

DAQmxCfgSampClkTiming(taskHandle1,

"/Dev2/PFI24",rate,DAQmx_Val_Rising,DAQmx_Val_ContSamps,NULL);

DAQmxCreateCIAngEncoderChan(taskHandle2,

"Dev2/ctr1","",DAQmx_Val_X4,FALSE,0.0,DAQmx_Val_ALowBLow,DAQmx_Val_Radians,2000,0.0,"");

DAQmxCfgSampClkTiming (taskHandle2,

"/Dev2/PFI24",rate,DAQmx_Val_Rising,DAQmx_Val_ContSamps,NULL);

DAQmxCreateCILinEncoderChan (taskHandle3,

"Dev2/ctr2","",DAQmx_Val_X4,FALSE,0.0,DAQmx_Val_ALowBLow,DAQmx_Val_Inches,0.00096,20.5,""); DAQmxCfgSampClkTiming (taskHandle3,"/Dev2/PFI24",rate,DAQmx_Val_Rising,DAQmx_Val_ContSamps,NULL);

This works if I only use one encoder, but if I use all three I get an error: "No DMA channels are available. Either shut down other tasks that might be using these channels or consider changing your data transfer mechanism to interrupts."

Do I need a seperate clock for each encoder? What am I doing wrong? I have two other DAQ boards in my computer, a 6071E and a 6229. They have extra counters but I don't know how to route their signals to the 6601.

Also, when I go to calculate my velocity and acceleration I'm having a hard time finding a good buffer size/sampling rate to yield a smooth-ish acceleration with quick response. Any tips?

Any advice on this would be great. Thank you!

[Ixstala]

Ok. I realized if I set this:

DAQmxSetCIDataXferMech(taskHandle1,

"Dev2/ctr0",DAQmx_Val_Interrupts);

for each counter then I can read everything just fine. I don't know what type of hit I'll take in terms of speed using IRQ instead of DMA (seems slower). Is there anyways to do this using DMA? I can read from three counters just fine without this timing issue...

Also I don't have the clock "physically" wired into the counter.

I still don't know how to get the acceleration with fast response and high accuracy.

warmest regards to anyone who can help.

[Ixstala]

I should also mention that I'm measuring low frequency inputs on the counters. So I would like to be able to retrieve low velocities.

[Ixstala]

Alright, more progress. Instead of using the buffered input I'm now using seperate counters to get the frequency of my encoder inputs. I then use that freq (pulse/s) times the resoultion (rad/pulse) of my encoder to get Velocity. I set the directionality by looking at the current and last positions.

Anyone know how to get acceleration from the frequency measurement?

Message Edited by Ixstala on 03-11-2007 11:46 PM

[Ixstala]

Here's how to calculate the acceleration from the frequency measurement. I should've thought of this earlier.

Accel=(freq1-freq2)/T2=(freq1-freq2)*freq2

where freq1 and freq2 are two sequential buffered frequency measurements from the encoder input.

This should be a very high accuracy method using the 20MHz timebase to collect pulses.

[Kevin_Price]

Looks like you've worked through your most pressing needs, just some brief comments:

1. The 6601 only has capability for 1 channel of DMA maximum.  That's why at least 2 of the 3 measurement must use interrupts.

2. To get the extra speed of all DMA-based data transfers, you can connect 2  of the encoders to the M-series 6229.

3. The sample clock generated by the 6601 can be easily shared if the boards are connected with a 34-pin ribbion RTSI cable.  It would also be possible to physically wire the terminal blocks if you don't have a RTSI cable.  I don't know any of the syntax for doing this with VC++ though.

4. Your accel calc is correct as far as it goes, but be aware that the finite difference you're performing is often not the best choice for numerical differentiation.  You'll probably find that the calculated accel appears very erratic.  A simple rule of thumb is that integration attenuates high freq noise while differentiation amplifies it.  If you need a smoother acceleration measurement, you'll need a more complex technique, involving one or more things like averaging, filtering, curve fitting.

5. Very much agreed that you will get better speed precision by performing freq measurement on the encoder edges rather than sampling position and doing a derivative.

6. Thanks for updating your progress as you went along -- will help others who come along and read the thread later.

-Kevin P.