LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

10s limit for DAQ assistant (express VI)

When using the DAQ assistant (express VI), the total acquisition time seems to be limited to 10 seconds. Is it a default limitation? Is it possible to change this VI setting?
0 Kudos
Message 1 of 8
(3,095 Views)
Jarda,

The default settings for the DAQ Assistant for most of our DAQ boards are a sample rate of 1kHz, Finite Acquisition, and 100 samples. This yields an acquisition time of 1/10th of a second. How are you settings configured? Most importantly, are you performing a Finite or Continuous Acquisition? Finite means that the DAQ Assistant will acquire a set number of samples, the duration depending on the sample rate. For a Continuous Acquisition, the card should acquire forever. Of course, if you do not read data from the Assistant quickly enough, you could get a buffer overrun. Please let us know a bit more about your application, and we'll happily help.

Regards,
Ryan Verret
Product Marketing Engineer
Signal Generators
National Instruments
0 Kudos
Message 2 of 8
(3,079 Views)

Ryan,

 

Thank you for your answer. I have already solved the problem. I passed over a new control parameter in DAQ Assistant2.vi, which is called timeout and is set by default to 10s. It is missing in the detailed help corresponding to this VI.

 

Regards,

Jarda T.

0 Kudos
Message 3 of 8
(3,061 Views)
Jarda,

I see your confusion now. Thanks for calling this to our attention. I have notified our documentation people, and hopefully this should be fixed soon.

Regards,

Ryan Verret
Product Marketing Engineer
Signal Generators
National Instruments
0 Kudos
Message 4 of 8
(3,042 Views)

I am having a similar problem. I am using DAQ assistant to acquire signals on demand. The loop is set to iterate at 25ms. This I thought would give me the required sample rate of 40 times per second. However, when I open the associated log file, it only gives me readings of 8 times per second. I have attached the VI. Can anyone see what is wrong here? In a previous post I was told to try a producer consumer architecture. I did this, but this did not improve my logging rate. I now have a feeling it has something to do with the DAQ assistant. If anyone has had similar problems and solved this, please shed some light.

Thanks.

0 Kudos
Message 5 of 8
(2,813 Views)
I changed the DAQ Assistant out and replaced with a random number generator, and got the sample rate I require. Therefore, the problem is with the DAQ assistant. I just don't know what. Any ideas?
0 Kudos
Message 6 of 8
(2,806 Views)
One problem with the DAQ Assistant is that it creates the task, runs it, and clears it every time its called.  So it's likely that the creating and clearing activities are taken longer than you want to achieve a 25 msec cycle time.  If you right click on the DAQ assistant and select Open Front Panel, it will turn the DAQ assistant into a subVI you can open and see what is going on.  (Do this in a copy of your VI to start as there is no undo operation to turn it back into an Express VI.)
 
So I would recommend setting up your DAQ tasks before the loop, read the task only inside the loop, and clear the task after the loop.  Look at the code generated by the DAQ assistant or look at DAQmx examples to see the proper ways of doing this.
 
One other tip.  You don't need to convert the boolean array coming out of the 2nd DAQ assistant to a cluster just to unbundle a few of the booleans.  Wire the array into an Index Array function.  You can expand the VI downwards to get multiple indices.  This will save time and memory in the conversion process.



EDIT:  I may be mistaken about the DAQ assistants creating and clearing the task on every iteration.  Looking closer at the subVI, I see it uses first call primitives to only execute those task the first time the subVI is called.  But I would still recommend converting the Express VI's to the basic DAQmx functions.

You may also want to put some get timer functions in your code with some sequence structures before and after different code parts such as the DAQ assistants and File writes to see where the code may be taking the longest.  I would have though the File Write might be taking longer than you want, but you said the problem went away when you removed the DAQ assistants and put in a random number generator implying that the File Write portions are okay.  If it turns out that is not the case, then it is probably a good idea to move the file writes into their own loop and pass the data by queue.  Look at the producer/consumer architecture for how to do this.



Message Edited by Ravens Fan on 03-26-2008 09:56 AM
0 Kudos
Message 7 of 8
(2,800 Views)

Thanks for the info. By breaking up the DAQ assistant and doing what you said :

"I would recommend setting up your DAQ tasks before the loop, read the task only inside the loop, and clear the task after the loop"

This has solved my problem. I am now logging at the rate I require.

0 Kudos
Message 8 of 8
(2,777 Views)