Data aquisition with USB-6363: Buffer overflow due to high sampling rate

[pegli]

Hi,

I would like to aquire data from a USB-6363 device using LabVIEW. The waveform I'd like to aquire consists of multiple frequency components and I would like to monitor how the magnitude of a Fourier component at a specified frequency changes over time. Therefore, I though to read-in data and Fourier transform it afterwards. However, I encounter already problems while reading-in the data. Attached you see my block diagram. The application starts to run, but after several runs, no data is anymore aquired and I encounter an -200361 error inidcating that I have a memory overflow. It seems that the USB connection is not capable to "remove" the data fast enough from the DAQ device. How can I prevent that without reducing my sample rate? I need to sample at 500 kHz since my singals have frequency components up to the region of 100 kHz. However, I don't need to track time change over time with such a high rate. In principle, I would like to aquire a fixed amount of samples (e.g. 6000) with 500 kHz sampling rate, Fourier transform this, determine the power magnitude of my observed frequency and then capture the next chunk of samples. The time tracking resolution (determined by the time between the samples) can be much lower and should be at maximum 1 kHz. So, have you any ideas how to achieve this?

Peter

[mcduff]

You will need to switch to a producer consumer to architecture. Look in the example finder.

Basically it looks like you are acquiring data about every 10ms, that means your FFT and display need to to finish before the next data comes through.

You are probably better off acquiring data every 100ms, your eye is not much faster than that. If you have a really fast computer you might be able to get away without splitting up your loops, but in the long run you are better off splitting up your loops:

1. Acquire data in one loop (producer)
2. Send to the consumer loop (FFT and Display)

mcduff

Hint look at queues, channel wires, user events, notifiers, to send the data between loops.

[pegli]

Thanks for your reply. Your architecture propose is very helpful and I will take a look at the example library. However, my main question at the moment is how I achieve the acquisition for that task. I‘m rather new to LabView and unfortunately I‘m a little lost. So do I need to go from continuous acquisition to a finite N sampling? If so, how do I constantly repeat the measurement of the given number of samples without too much overhead?

Concerning my application: The update of the FFT is not only for display. This extracted time signal of the FFT component intensity is the measurement signal I‘m interested in. The waveform plot of the FFT was just for the initial test. Finally, I am heading for a plot like FFT magnitude against time with a resolution of a couple ms. However, that is at the moment not so important since I really need to get the data acquisition done first...

Peter

[mcduff]

Attached is a LabVIEW 2015  version of the png you attached with some modifications. Change the number of points to a set value not -1.

It is a starting point and not a finished product. There are lots of improvements you can make, and should, in order to learn LabVIEW. (I am leaving the office now and won't have access to LabVIEW, so good luck.) Also, you should attach your VI in the future.

mcduff

[pegli]

So I tried your VI with hardware this morning. I still encounter the problem that I get immediately get an onboard memory overflow error (-200361) after some data acquisitions (typically 9) of 6000 points each. Afterwards, I must restart the USB-6363 to continue (otherwise I get always the memory overflow error). It seems really that the problem is that I cannot continuously sample with 500 kHz over USB. Therefore, I thought about switching to finite sampling. Attached you find my new VI. My problem is that the waiting in the loop needs to be in the order of couple 100 ms to not crash the VI with the memory overflow error. In addition, this seems to be a very unstable solution.

So, are there any ideas how to mitigate this problem?

What I thought about is to have a solution where I acquire 6000 samples with a sample rate of 500 kHz. This, I want to do in a single shot so the DAQ takes the 6000 samples, stores them and then I transfer them to the computer. Afterwards, I start over and acquire the next 6000 samples. The rate with which this repetition occurs, should be “automatically” throttled such that I prevent this mysterious onboard memory overflow error. It should just repeat the data acquisition as fast as possible due to hardware or bus limitations. If this process jitters, this should not be a problem as long as I can get time tags for this.

So, do you have any hints for a Labview newbie how to achieve this?

Peter

[mcduff]

I'll be in the office later to check out your VI, but 500kSa/s should not overwhelm the USB. Here are some suggestions:

1. Grab data every 100ms, so 50k points. I think you are trying to read the data too often. The read takes time.
2. Make sure your DAQ is on its own USB port. Do not share the port with anything. 

mcduff

[mcduff]

Looking at your VI, I think the real problem when acquiring continuously is small sample size you are trying to download. 6000 points at 50kSa/s is 12ms, try with 60000 points,  120 ms. I have downloaded multiple channels at 2MSa/s over USB with a 100ms delay in between downloads and it works.

mcduff

PS Make sure you are using a dedicated USB port, not one attached to your keyboard, etc.

[pegli]

mcduff thank you so much for your answers!

All the problems of the Buffer overflow errors were gone after I transferred the VI from my laptop to the lab computer with a clean install of LabVIEW. So, it seemed that the problem was relate tot the USB or the operating system infrastructure.

In addition, thank you for introducing me into the concept of separate producer and consumer threads by using a queue. This concept is much cleaner than my approach and I am really gratefully to you to point that out!

Peter