DAQmx continuous acquisition question

[RobCole]

We work at slower speeds, but we regularly set up acquisition at 1 kS/s and then only read out the data from the buffer every 100ms. So we're acquiring 100 samples every loop and waiting in between. With a buffer of twice that long. Then we check thenumber of available samples and read all of those out. It's queued up and a separate loop stores the data to disk.

It is continuous data as long as you are reading out the data before you overflow your buffer. I like to set up the DAQmx acquisition to have a buffer at least twice as long as I expect my read time to be. Then just ensure that you are getting the data out of the queue fast enough to nt fill the memory as well.

     Rob

[noli]

Hi Rob thanks,

    So this means.. that if I decide to set up a 5M sample buffer, and read 1Ms per loop iteration, it should keep my data continuous once I queue it out to a seperate loop an concatenate it, right?  And as I understand it,defining a buffer allocates that much space on your host computer's RAM, so I should be able to allocate a decent size more or less up until my ram limit, right?  

   Also why do you check the number of samples available, and read that number out, as opposed to  specifically telling it to acquire X samples, and then read X samples?  Does it make a difference?

Thanks

[RobCole]

The problem comes when we work in Windoze. Newer versions are better, but still a background task from the operating system might delay your loop a bit. If you get delayed by a few samples every 20 loops, how long until you overrun the buffer? This is also the reason for the longer buffer.

Maybe I should have mentioned that we have built systems that have run 10,000 hour (> 14 months) test runs with no data loss. If you are doing short runs, then you shouldn't have to worry about it - just make sure that you empty the buffer after you stop the acquisition.

It's just a safer way of doing it without worrying too much about time constraints for getting stuff out of the buffer.

     Rob

[noli]

Wow..that is some impressive reliability!   From your previous comment, I noticed that the number Elements Remaining in my queue was steadily increasing as my program ran, so it looks like I was not dequeueing fast enough, as you said.  I tried replacing the dequeue vi with a flush queue vi, to make sure that I emptied it.  Now, it looks like the queue stays empty, but i'm still hitting a memory alllocation error.

When you say that you empty the buffer after stopping the acquisition, do you mean that you add one last Read vi after your acquisition loop with the number of samples to read as -1 so that it reads any samples that might be remaining, or is there another way to empty the buffer that i'm missing?

Here's my updated vi

 

[noli]

Wow..that is some impressive reliability!   From your previous comment, I noticed that the number Elements Remaining in my queue was steadily increasing as my program ran, so it looks like I was not dequeueing fast enough, as you said.  I tried replacing the dequeue vi with a flush queue vi, to make sure that I emptied it.  Now, it looks like the queue stays empty, but i'm still hitting a memory alllocation error.

When you say that you empty the buffer after stopping the acquisition, do you mean that you add one last Read vi after your acquisition loop with the number of samples to read as -1 so that it reads any samples that might be remaining, or is there another way to empty the buffer that i'm missing?

Here's my updated vi

 

[hecmar.arreola]

---

DianeS wrote:
--xsnipx--

 

As for your AI, it is definitely hogging up the entire CPU (at least, it does when I simulate it - I should specify that I added a loop delay when I ran it).  Can you try working at a lower sampling rate to start with?  I don't have time to delve farther into it now but will try to mess around with it later tonight.

Message Edited by DianeS on 11-11-2009 04:21 PM

---

You shouldn't add a loop delay to your AI thread.  The loop speed is determined by the acquisition rate and number of samples read per loop iteration.  The sampling frequency is 5MS/s and the number of samples to read per iteration is 1MS/iteration.  Therefore the speed of that loop will be about 1/5 second.  You don't want to make it artificially longer than that or else you will run into "samples no longer available in buffer" type errors.  The reason why it simulates to 100% CPU is because the original VI that the OP posted did not have the "Number of Samples" wired to the DAQmx Read VI.  

[RobCole]

I'm not sure why you would be getting a memory allocation error. 100% CPU usage since there are no delays in either loop (even a wait for 0ms will let the OS do what it needs to). Since you're reading all available samples and not waiting for a specific number of samples.

Is your maximum queue size changing? You might try setting some bounds on your queue. I do not see anything else in the code that could be taking up memory.

Your queue read will only stop after you exit the acquisition loop and destroy the queue, so this system that you use should work fine. Just be aware that if you destroy the queue while there are still items in the queue, those items are lost. But then, if you're stopping, you should already have what you need.

BTW, in your dequeue loop, you don't need to unbundle the error status. You can feed the error cluster straight into the conditional terminal. Not that it makes much difference, but it's a little cleaner.

     Rob

Message Edited by Robert Cole on 11-12-2009 09:22 AM