BIG speed problem with DAQ

[Yves]

Hi,
I have seen that are already some postings about the following theme but none of them really helped me.
My program is built to acquire 100 in a second (10 samples each scan). But after a while the data retrieving gets slower. but it is important to me that I have a defined number a acquired data. Even when I'm acquiring during 600 seconds!
The odd thing is also that the timing is to fast a the beginning (x-y<100)
What can I do?

thanks for any help
Yves


LV7.1, Win2k

[Dennis_Knutson]

The first thing to understand is that the DAQ Assistant is designed to quickly get you acquiring data. It is not however, designed to acquire data quickly. Since you converted it to a VI, you can look inside and see what I mean. Every time it's called, it does a Create Channel, Timing, Start Task, Read, Stop Task. Everything except the Read should only be done once. Look at the shipping examples for DAQmx on how to do an acquisition more effeciently. The most pertinent one may be Cont Acq&Graph Voltage-Int Clk.

Second, using the build array can be very ineffecient. With each iteration, your array gets bigger and bigger. The longer it runs, the bigger it gets and the more time that the LabVIEW compiler takes to allocate more memory. If you know how long the VI will run, you can allocate the size of the array before your start and do a Replace Array Subset function. For a fixed number of acquisitions, you could also use a for loop and just wire the data out of the for loop. The auto-indexing feature of a for loop will automatically create an array of all acquisitions. A while loop also can be made to auto-index. Since it appears that you want to save the data, you could also save each acquisition as it occurs. Look at the example called Cont Acq&Graph Voltage-To File(Binary). At the rate you're acquiring, that should not be a problem.

Lastly, if you want to control how often the acquisition occurs, you need to put a wait statement in your program. This can be either Wait (ms) or Wait Until Next ms Multiple.

[Yves]

Thanks for your quick answer.

>Lastly, if you want to control how often the acquisition occurs, you need to put a wait statement in your program. This can be either Wait (ms) or Wait >Until Next ms Multiple.
But how can I insert a "wait until next ms multiple" of for examle 10ms if I have a data acquisition of 1000 samples/channel/second? (1 sample each millisecond)

>The auto-indexing feature of a for loop will automatically create an array of all acquisitions. A while loop also can be made to auto-index.
If doing so I get a 3-dimensional array! Am I right?

>Look at the example called Cont Acq&Graph Voltage-To File(Binary). At the rate you're acquiring, that should not be a problem.
I tought that saving should be done after the acquisition because this might take some time. And I want to make some modification to the collected data before I save them.

[Yves]

Another explanation:
The reason why I'm using the adapted DAQ Assisant vi is that I have several channels to acquire. And I don't know why but with the "Cont Acq&Graph Voltage-Int Clk" I just couldn't make the acquisition with more than one channel. Even when placing a "For loop" around the "DAQmx Create channel..." function.???

>The longer it runs, the bigger it gets and the more time that the LabVIEW compiler takes to allocate more memory. If you know how long the VI will run, you can allocate the size of the array before your start

I have read this in another post but didn't expected this to be such a big problem. And unfortunately I dont know how long the acquisition will run.

[Dennis_Knutson]

The easiest way to add multiple channels in DAQmx Create Channel is Dev0\ai0:n where n is the last channel number in a list of consecutive channels.

[Yves]

To Dennis Knudson: Thanks for your answer. Unfortunately I have different Voltage settings and limits.

To all other: does anybody has some answers about my other problems?

Thanks for any help

[Stuart_G]

I just wanted to comment on one thing Dennis said:

"The first thing to understand is that the DAQ Assistant is designed to quickly get you acquiring data. It is not however, designed to acquire data quickly. Since you converted it to a VI, you can look inside and see what I mean. Every time it's called, it does a Create Channel, Timing, Start Task, Read, Stop Task. Everything except the Read should only be done once. Look at the shipping examples for DAQmx on how to do an acquisition more efficiently. The most pertinent one may be Cont Acq&Graph Voltage-Int Clk. "

While he is correct that if you want to 100% optimize your application then use the DAQmx examples, the assistant is not the best for you, but not necessarily for the reasons Dennis mentions.  For a continuous app if you look at the VI which is created you will notice there is a First Call primitive wired to a case structure which calls the Create Channel, Timing, etc only the first time the Express VI is called.  On subsequent calls those VIs are not called and therefore that is not what is slowing down your program.  In fact it looks just like a DAQ example.  One of the slowdowns is the conversion of waveform data to the LV dynamic data type, but this is not a huge slowdown.  I would look at the building of the array in your program as Dennis points out as the major culprit.

[IanW]

If you have several channels at different settings why not create global channels and a measurment Task in Max Explorer.

I've recently been using a system which reads about 60 channels at 500 scans  a second, I read 100 scans (or more if there's a backlog) 5 times a second. The 100 scans are averaged for each channel and saved in a slow log file. Ten of the channels are saved at the full scan rate of 500 scans/s, writing the data to a fast log file each 0.2 s, both the fast and slow logs are csv files. But as stated earlier don't use a build array, this will definately slow down the system.

Ian S

[Dennis_Knutson]

You're right!For some reason, i missed the first call function when I first looked at the Assistant VI and my mistake was stuck in my head ever since. I'll now keep the Assistant in mind.