LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Speed up daq counter

Solved!
Go to solution

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?

 

DAQ counter acquisition time.png

 

Regards Florian

0 Kudos
Message 1 of 7
(2,595 Views)

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.

 

 

>

"There is a God shaped vacuum in the heart of every man which cannot be filled by any created thing, but only by God, the Creator, made known through Jesus." - Blaise Pascal
0 Kudos
Message 2 of 7
(2,593 Views)

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

0 Kudos
Message 3 of 7
(2,584 Views)
Solution
Accepted by topic author Florian.Ludwig

Make sure you are doing continuous acquistion.

 

>

"There is a God shaped vacuum in the heart of every man which cannot be filled by any created thing, but only by God, the Creator, made known through Jesus." - Blaise Pascal
Message 4 of 7
(2,573 Views)

Duh!

Of course!

 

That's it. Speed is great error is gone.

 

Thank you very much

0 Kudos
Message 5 of 7
(2,568 Views)

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. 

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 6 of 7
(2,562 Views)

Thank you for assembling such a comprehensive answer nevertheless.

 

Regards Florian

0 Kudos
Message 7 of 7
(2,558 Views)