08-23-2012 08:04 AM
Hi,
I'm trying to determine the pulse width of a signal by using the counter of a NI USB 6216. This works reasonably well, except the acquisition is too slow for my needs.
Below you can see a stripped down version of my acquisition vi. In the version depicted stage 2 of the loop takes 3ms to execute. This is the time expected to count the appropriate number of low times (20) in the signal I'm measuring. The whole loop takes 30ms however (measured beginning to end of loop - not beginning to beginning of next iteration).
If I remove start task and stop task vis the loop time doesn't change, the whole time apparently taken up by the read vi.
I'd like the loop to run with less overhead (ideally none :-). Can anyone with more experience shed some light on how to speed up this vi?
Regards Florian
Solved! Go to Solution.
08-23-2012 08:10 AM - edited 08-23-2012 08:14 AM
Are you missing data between iterations? I think if you move the start/stop outside the loop you will get all of your data in succession. You will need to concanenate the data at each iteration.
Something like this? The build array primitive is not normally recommended, but I put it there for simplicity.
08-23-2012 08:25 AM
Thanks for the quick response!
I am missing data. That wouldn't even bug me if it wasn't that much data. Getting only ten percent of the available data is far from enough.
Moving start and stop outside the loop yields error 200278. Roughly translated from the german version of the possible cause: tried to read a value after the last available value.
Don't worry about the handling of the data - this vi is just to show the code I'm having trouble with.
Regards Florian
08-23-2012 09:33 AM - edited 08-23-2012 09:36 AM
Make sure you are doing continuous acquistion.
08-23-2012 09:38 AM
Duh!
Of course!
That's it. Speed is great error is gone.
Thank you very much
08-23-2012 10:01 AM - edited 08-23-2012 10:04 AM
Partially puzzled by two things that seem in conflict:
1. you're doing a finite triggered task that intentionally misses some pulses while it stops and restarts
2. you're expressing some concern about those missing pulses
One idea to make the stop and restart faster is to use DAQmx Control Task to "commit" the task before starting.
When you do that, cycles of stop and restart can occur much faster than they would otherwise. An example and
some benchmark results can be found here.
Another idea is to perform continuous acquisition of the pulse measurements so you won't miss any. Depending
on your app, that may leave you with the job of timestamping the trigger signals with another counter, and
working a scheme to correlate particular pulse measurement subsets with particular trigger events. Not a trivial
job, but a do-able one.
-Kevin P
P.S. Just re-checked and noticed you're using a USB board. I suspect that's a significant part of the problem.
There's more latency & overhead with USB acquisition, and the effect is stronger when you request small packets
at a high rate than if you requested large packets at a lower rate.
P.P.S. Looks like you alread got an answer before I hit send -- I was just typing a minute here, a minute there
while do some other testing.
08-23-2012 10:06 AM
Thank you for assembling such a comprehensive answer nevertheless.
Regards Florian