trigger rearm

[caz]

I'm using a PCI-6115 S series device on a Dell Pentium4 (2GHz processor, 2GB RAM) running LV 7.1 with NI-Daq 8.0 to do some triggered finite aquisitions.  I have a 8kHz square wave (50% duty cycle) to use as the trigger signal.  What I am trying to do is record ~500 samples on the rising edge of the trigger signal for half the period and then repeat on the next rising edge.  This works out to roughly a sample rate of 10MHz for 62.5 microseconds.  I may not need as many points but the 62.5 microseconds is important.  The problem I am having is that I miss triggers.  If I called each acquisition a frame then the frame rate I get is about 1kHz.  I am using DAQmx and the block diagram basically is a channel config, timing config, trigger config, task control (committ to hardware), a for loop, start, read, and stop in the loop, and finally a clear task outside the loop (see attached .vi).  Currently I am doing continuous acquisitions and then post processing to get the frames but a triggered finite application would really save on the amount of data written to file.  My best guess is the 1kHz frame rate is limited by how fast the for loop can iterate and hence a windows limitation.  Any suggestions for improvement or at least a heads up that this is the best that can be done would be appreciated.

[Thaison_V]

Hi DC@ERC,

I'm not quite sure if this will meet your 62.5 microsecond requirement, but I do have a suggestion on how to speed up the rate at which you can retrigger your analog input.  With the method you are using in your VI, the retriggering rate is somewhat dependant on your software execution, but ideally, we would want to use hardware retriggering.  Although analog input is not hardware retriggerable directly, the counters on our cards are.  We can set up a counter to do a retriggerable finite pulse train generation (say to output 500 pulses as you requested), and then have a continuous analog input acquisition clock itself off of the generated pulse train.  The example here shows you how to implement this with the DAQmx drivers in LabVIEW.  At the very least, this should give you a faster retriggering rate.  I hope this helps!

Thaison V

[caz]

Thanks Thaison for the idea.  I had looked at something similar to this a while back and it didn't stick out at the time as a method of doing what I want but now that you described it so well I think it may be something useful.  I have one quick reply question, you mention analog signals not being directly hardware retriggerable and I am wondering what type of signal would be?  The trigger signal I am using comes from a resonant mirror driver board and I believe it is a TTL type signal.  Looking at it on the scope it goes from 2V to 6V instead of the 0-5 but I could condition it or use a programmable function generator to output a TTL.  Would a digital trigger increase my measurment bandwidth?

Drew

[Thaison_V]

Drew,

I guess I should be more specific by saying that an analog input task is not hardware retriggerable.  Regardless of whether you are using an analog or digital trigger to start your analog input task, the retriggering for the analog input is still done in software rather than hardware.  The counters are hardware retriggerable, and the example I referenced earlier uses a digital TTL signal as it's trigger.

Thaison V

[thayles]

In order to hardware retrigger off an analog signal, it is necessary to use the analog trigger circuit's output signal (AnalogComparisonEvent) as the digital edge start trigger for your retriggerable Counter Output task (which in turn is supplying the Sample Clock for your analog input task). Either configure the analog (start) trigger on your analog input task, or create a 'throw-away' analog output task in order to configure the trigger circuit. If you use the latter, you will have to connect your analog trigger signal to the PFI 0 pin I believe. As long as the task to which the analog trigger is assigned is not cleared, the analog trigger circuit will continue to recognize triggers and emit digital pulses when they occur.

[caz]

Thanks Thaison V and Thayles.  I had played with this before in trying to do a simultaneous triggered analog input and output.  I think I will revisit it and see if it solves my Daq problem.  Earlier I was trying to do something much harder in that I would aquire a triggered finite aquisition for one period, measure the period using a counter, and then on the next rising edge input again but also output a pulse train based on the period measurement.  In essence, I was trying to correct for a variable frequency signal that was coming from my measurement system.  I think I still have the codes so maybe I can patch them up to do what you both suggest.  I'll let you know how it goes.

Drew