Retriggering AI and Counting the trigger pulses

[Fenderman]

I'm using DAQmx 8.0, with a 6011 "E" series board.   The application: Trigger a series of AI reads (to get an average) on an encoder pulse, and continuously count the encoder pulses.   The goal is to end up with an array of voltages and encoder counts, so I know what the average voltage was at each encoder pulse.   The encoder is maxed out at about 600Hz.  I can't miss any encoder pulses.

The "simple" approach does not seem to be fast enough.  "Simple" meaning:

1)  Set up edge triggered counter and Analog In with external digital trigger (both triggers are PFI3)

2)  START counter task, COMMIT analog task

3)  Loop:

        start analog task

        read analog value

        read counter value

        stop analog task

        print analog and counter value to console window

 4)  end

I have to slow down the encoder to about 300Hz to stop missing encoder pulses.

It doesn't look like the retriggerable counter method will work either since that uses two counters, and therefore I loose my continuous encoder count.

It just hit me that printing to the console window won't be happening in the real application, but the printing overhead might not be too different than the overhead due to averaging the analog samples and stuffing everything into the final array.

Am I missing something in my approach?   Is there a (better) way to do this with my hardware?

Thanks,

Jim 

[Tom_W_[DE]]

Hi Jim-

It sounds like you are trying to take one analog reading at each time you read the counter value.  Have you considered the use of a buffered counter operation to perform the same task?  This would allow you to clock the analog input task rather than resetting the task for a single point each time, and you could also be assured that the counter and analog readings were taken at exactly the same time.

This entails setting up an analog input task with sample clock timing.  I'll assume you are using VC++.  The example "C:\Program Files\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Analog In\Measure Voltage\Cont Acq-Int Clk" shows how to set up an analog input hardware-time acquisition.  The example "C:\Program Files\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Counter\Count Digital Events\Cnt-Buf-Cont-ExtClk" shows how to run a continuous buffer counting task and use an external clock to dictate when a sample should be buffered.

The "external" clock source for the Counter task setup should be the analog input sample clock or "/Dev1/ai/SampleClock".  By combining these two examples you should be able to not only run your AI task continuously to avoid the overhead associated with starting and stopping the task, but you will also see much better phase relationship between the two measurements of interest.

Hopefully this helps- let me know if you have any additional questions.  Thanks-

[Fenderman]

Thanks for the response, Tom, but I don't understand.

The intent is to trigger a series of readings, say 50 for example every time I get a pulse from the encoder.  My C++ application will then average these 10 readings, take that average and pair it up with the value of the encoder count at the time the readings were triggered.  I will end up with about 30k of these (Ave volts, count) pairs that will later be analysed.   The only time I need to take a series of quick readings is when that encoder pulse happens.

What I understand you to say is: Take readings of both counter and AI continuously, syncronize them by using the AI sample clock for both the counter task and the AI task.  But I don't understand how to coorelate the two buffers.   If I do a readcounter buffer of 200 readings, and immediately follow that by a readAI buffer of 200 readings, those readings will coorelate?   So I need to scan through the counter buffer looking for a change of state, then find the cooresponding reading in the AI buffer?

Thanks again for your help!

Jim

[Tom_W_[DE]]

Hi Jim-

Yes, the beauty of sharing a sample clock is that you don't have to actually go back and mess with correlating the readings as they're taken.  The easiest way to accomplish what you're going for is to just continuously acquire the analog signal and then read buffer backlogs to find where a counter change occurred.  The absolutely ideal situation would be to use a counter as a retriggerable sample clock for analog since the analog timing engine doesn't support this directly, but as you mentioned before this would eat up both of the counters on your card.

You could consider using a second card, perhaps a PCI-6601 that would allow you to provide the retriggerable sample clock for your multifunction card.  If this isn't an option then you should be able to accomplish it with your single-card solution using a bit of post-processing as we have been discussing.

Please let me know if you have any additional questions.  Thanks-