Timing features with DAQmx

[teslaaaa]

This is my first big labview programming endeavor and I am ready for the DAQ portion of the program.

I created the following code to acquire X-seconds of data @ sample rate. And display elapsed time and % fill bar.

I want the Channel indicators to refresh as data is acquired, so I setup DAQmx to acquire 1 sample in a timed while loop.

I set up the flat sequence structures so I could measure the actual test duration.

As is shown a 5 second test takes 5.057 sec’s.

100s=100.205

Eventually the time will be significant, and I’m worried when I start sampling more than 1 channel the time will be compounded.

Any suggestions for code improvement?

[John_P1]

Just a few observations (#1 is really the most important takeaway):

1.  Running your loop at 500 Hz (or beyond?) isn't what you really want.  Assuming you do want to sample at this rate, you'd be much better off using the N Samples variant of DAQmx Read.  N should be whatever makes your loop run at a reasonable rate (5-10 Hz should be plenty for the purposes of updating the few front panel indicators).  For example, at a 500 Hz sample rate, reading 100 samples per loop would make the loop run 5x per second.

1b.  With this change made, you'll find that the read now returns a 1D array of values that you will need to insert into a single longer 1D array.  It is optimal to pre-allocate this longer array rather than appending to it on every loop iteration (i.e. Initialize the longer array to the correct size outside the loop and use the Replace Array Subset inside the loop).

2.  You may take out the wait function--its purpose is to keep the loop from running unchecked and consuming CPU.  The DAQmx Read call blocks until data is available and already does this for you.  At best, the wait is redundant (if it is less than or equal to the time that the DAQmx Read blocks, it does nothing).  At worst, the wait will lead to a buffer overflow (if it prevents the read from executing at the speed it needs to).

3.  This probably won't even be noticeable, but... if possible use the front panel terminals themselves when updating indicators inside your loop (right now you are using value property nodes which forces an immediate redraw).  If not, use local variables instead of the value property nodes.

4.  You could pull some of the math outside your loop (division is pretty expensive) but it won't make any noticeable difference once your loop is running at a reasonable rate.

5.  This won't affect performance at all, but I found this portion of the block diagram's wiring to be very confusing:

Also, usually I try to create a DAQ task exactly one time in a program if possible (during an initialization routine)--here it looks like you're creating it every time you want to start recording.  If you create the task once and then start/stop it as necessary you'll shave some ms off of your benchmark (quite possibly not worth the trouble though, depending on what the rest of your applicaiton looks like).

Best Regards,

[Dennis_Knutson]

Using a timed loop is silly. Using 1 sample mode is silly. If you specify x number of samples (x>1), you will acquire those samples in exactly x/sample rate seconds. That is the whole purpose of using a DAQ card with clocked input. Your mode with 1 sample reverts to software timed acquisition and that is subject to a great deal of jitter and unknown timing in the loop.

[teslaaaa]

First let me say thanks for the the feedback.

"It is optimal to pre-allocate tis longer array rather than appending to it on every loop iteration (i.e. Initialize the longer array to the correct size outside the loop and use the Replace Array Subset inside the loop)."

I think this is what you were suggesting?

I already see a huge improvment when opening other background tasks on the cpu while recording. They have no impact on the test duration/timing.

Thanks,

Cody