usb-6009 high-speed continuous acquisition for slow control loop application

[Patrick_Lu]

Hi,

After watching a few Youtube videos, I successfully built a control loop in LabVIEW using my USB-6009. Currently, this loop is limited by the speed my actuator can take and respond to commands, topping out at 200 Hz. This is completely sufficient for my application. My question is more regarding the wasted potential of the USB-6009 to acquire samples at a much higher rate than what would be obtained if I used a simple single sample-on-demand during every iteration of the loop.

It seems to me that having the USB-6009 continuously acquire samples and having my control loop periodically check in for the latest data when it is ready to execute would have the advantage of allowing me to average groups of samples together to lower the overall noise associated with the measurement process (I am reading voltages from an amplified photodiode).

1) Does anyone know how I would instruct the USB-6009 to continuously acquire at say 10 kHz, so that on each loop I will have 50 or so samples that can be averaged together for a more accurate measurement of my control variable? Unfortunately, I'm new to this and not too familiar with DAQmx Timing.vi.

2) I've heard that reading into a buffer can increase latency for moving data into the computer. Given the low speed of my control loop, I don't foresee this as being a problem. Is this a correct assumption? I can probably live with an extra millisecond of latency.

3) I goofed around briefly with DAQmx Timing and managed to see a buffer overflow error. Certain rare events will by necessity cause my control loop to take much longer to execute, so I cannot guarantee that occasionally during normal operation I will not overflow the buffer. Can I suppress this error so that the dialog box does not pop up and the program continues to run uninterrupted? If the buffer overflows and old data gets overwritten it isn't a big deal for me since the control loop is only concerned with the latest data anyway.

Thanks for any info!

[Patrick_Lu]

Upon further deliberation, I thought of a slightly modified approach and was hoping for some feedback since this is all very new to me. If I am running my control loop at 200 Hz, as before, and sampling at 10 kHz, I will have 50 samples ready on each iteration of the loop. The earlier samples within the batch are stale--they are essentially as old as the previous loop iteration. What if I deliberately used a buffer size smaller than the number of samples that I would acquire before my next buffer read event? For instance, if the buffer could only hold 10 values, I am guaranteed that at any point the buffer will be filled with the 10 newest values. The 40 older values would be discarded. To implement this, I would need to find a way to suppress the buffer overflow error, which I asked about earlier.

Thanks again for your knowledge.

[Dan_K]

Hello Patrick,

Take a look at the attached code for some example code that demonstrates what you are looking at doing. You can use the DAQmx Read Property Node to change your read pointer to the most recent sample and set the offest back the same number of samples you want to read on each iteration.

[Patrick_Lu]

Dan,

Thanks for the reply! A bit embarrassing to ask, but can you re-save the vi in an older format? Over here we're still stuck in the stone age (using LabVIEW 7.1).

Best,
Patrick

[The_Red_Barron]

Howdy Patrick!

Here is a picture of the front panel:

Here is the block diagram:

And I've attached a copy of the VI saved for LabVIEW 7.1.

Regards,

[Patrick_Lu]

Dan and Barron, thanks for your help thus far and sorry to resurrect an old topic. I did what you guys said and it seems to work for a few minutes. Eventually, however, I start getting zero data returned on each iteration of the loop that reads the buffer. I think it has to do with trying to read more samples from the buffer than are actually in the buffer. This happens because, depending on what toggles have been activated on my front panel, my loop can run quickly or slowly. When the loop runs quickly, the number of samples I'm asking for hasn't arrived yet.

As I understand it, the VI is supposed to block until the requisite number of samples is there? But reading with an offset that takes the read pointer to before the first sample in the buffer seems to screw things up. Is there a way to count the number of samples residing inside the buffer? That way I can have a dynamically adjusted read size.

Also, is there an "off-by-one" issue with the code you sent me? If you set the number of samples of read to 1, that makes the offset -1 relative to the most recent sample. Doesn't that mean you'll get back both the previous sample and the current sample (i.e. 2 samples returned)? 

Thanks for your help!

[The_Red_Barron]

What values were you using for sample rate, samples to read, and delay when this occured?  Can you give exact steps to reproduce the behavior?  Thanks.

Regards,

[Patrick_Lu]

Hi Barron,

That fact that the buffer is running dry is no mystery to me. I'm sampling at 10 kHz and using a collection loop that grabs the latest 25 samples. So when the loop runs faster than 400 Hz, I'm asking for more samples than are in the buffer. The thing is, when I do this, it seems like all I get from then on out is a bunch of zeros, ie no new samples are obtained, even if the loop speed drops back under 200 Hz. The only way to recover is to restart the program (well, I'm guessing that stopping and starting the task will also do the trick, but I have yet to try it).

It sounds like the thing to do is for me to look at the status in the read property node for the number of samples available, and to use a case structure to define the read size that doesn't exceed it. Hopefully this sounds reasonable!