NI-5133 Measurement slow

[Wolley]

Trying to measure a signal that will be pulsing every ms. Right now I am measuring and triggering off of a pulse-generator to simulate that signal; the generator is pulsing at very close to 1kHz, so that's fine. I noticed how slowly the program was operating, so in efforts to find the source I have bit-by-bit erased nearly everything else aside from just measuring and showing the waveform, and it's still too slow. If it is hard to tell at first, watch the "pulse" counter - taking 40 measurements at 100MS/s will take 400ns. Obviously repeating this measurement should still take considerably less than 1 ms, then. However watching the counter, it takes well over a second to get through the 128 measurements. Any idea why this is the case? I've attached the VI which is clearly quite bare-bones. With the .2 trigger threshold there are no instances where the scope misses a signal, as no errors are thrown, and so I can really come up with no reason aside from computational speed for why this program can't keep up.

Thanks,

Wolley

[Joshua-B]

Hi Wolley,

I would recommend pulling everything out of the For Loops that does not have to be there.  I would pull all configuration VIs out of the loops including the Configure Trigger Edge.vi.  This should be placed in-line before the loops start.  

In addition, the Initiate Acquisition and the Abort VIs should be placed before and after the loops respectively.  We probably don't need to continually abort and then restart our acquisition.  Removing these from the loops should reduce the overhead in each loop.

Another thing we can remove from the loops to improve loop speed is the graphing.  Updating displays can be very processor intensive.  Consider placing the graph in a separate parallel loop and passing the data to the parallel loop via a queue structure.

Hopefully some of this information is useful!

[Wolley]

If I pull the Initiate and Abort Acquisition VI's outside of the loops, can I still do the triggering and data collection as I have it set up here? The goal is to average the 128 records to reduce any noise, and to have 32 different data-sets as  I'm sampling 32 different lines that are being tested. The sampling needs to be externally triggered by a pulse signal that should be coming at approximately 1kHz but it won't be exact, so I can't just go off of timing - it has to trigger from every individual pulse. 

Thanks,

Wolley

[Joshua-B]

Hi Wolley,

According to the State Diagram for the USB-5133 in the NI High-Speed Digitizers Help file, the device will transition to the Done state after acquiring all post reference trigger samples.  It then says that you can transition out of the Done state by calling a Fetch function.  I do not believe that you will need to explicitly Abort and Initiate every iteration of your loop.

[Wolley]

I tried pulling the Initiate and Abort Acquisition vi's outside of the loop, and as I'd suspected only one sample was collected. I think the Trigger, Initiate and Abort all have to be repeated.

[Wolley]

I pulled the trigger to the outside of the loops and replaced the initiate, fetch and abort with a Read hoping it might be faster since the three vi's are compiled as one that way. Also used a wait timer to make sure the loop lasted 1ms, in case it happened to actually be fast enough now - it still isn't.

Is there a way that I can trigger it and initialize it outside of the loop and repeatedly fetch different samples off of the one initialization? Then when it finishes off the loops, it can be aborted?
Thanks,

Wolley

[Joshua-B]

Hi Wolley,

What happened on the second call of the Fetch VI when you pulled the Initiate and Abort VIs outside the loop?  Did the Fetch VI timeout?

[Wolley]

It didn't time out, but it didn't collect new data. The waveform graph showed the first signal that was collected, and never changed throughout the rest of the collection.

Thanks

Wolley

[Joshua-B]

Hi Wolley,

The Fetch VI shouldn't allow the program to move on until either the data has been collected or the timeout value has been reached.  Could you replace the Waveform Graph with a Waveform Chart so that we could see if multiple data sets are being recorded?

[Wolley]

I did so and it seems you're right - it is collecting all of the data. This does seem to effectively most of the time constraint, as now the VI completes in just a matter of seconds whereas it had been taking over a second per iteration of just the nested loop.

This brings me to a question about waveform chart that while it is not necessarily completely pertinent, it did spark my interest.

I've never used waveform chart, is probably why I don't understand it - but what appeared on the chart looked like roughly 6 plots all being plotted at once, when I only have a signal coming from a 2-channel reading of doubles - where on earth were all of the plots coming from?

Thanks,

Wolley.