Device Buffer Question

[jcannon]

Hi all,

I am attempting to revise/improve an old DAQmx project of mine by implementing a QMH and QSM producer/consumer design using three multiple parallel while loops (1. FP controls in an event structure, 2. DAQmx initialise/start/read/stop states, 3) waveform chart to data plot)... All is working well...

I am continuously sampling 5 x AI channels at 2kHz and reading 200 samples per iteration... All is working well after having the application run for 10 mins...

Having a deeper dive, I see that during the 10 mins of continuous DAQ, the device (USB 6218 BNC) during any single iteration has a max of 60 samples per channel on the buffer with a mean of 15 samples per channel per iteration across the entire 10 min period...

I understand how the device buffer works and why it is there... Could someone comment on if this number of samples per channel on the buffer is normal, good, bad etc? There is no buffer overflow or anything... I am just trying to get a handle on how this compares to other applications... I believe this device can handle up to 10k samples per channel on the buffer...However, I am using the application for real-time measurement in humans, however, a delay of 100ms (based on 15 or so samples from one iteration stored in the buffer, then removed and plotted in the next international 2kHz sample rate/200 samples read per iteration) isn't a problem for what I am doing... Saying that, no deal would be better...

Thanks...    

Thanks...       

[GerdW]

Hi Jack,

---

@jcannon wrote:

I am continuously sampling 5 x AI channels at 2kHz and reading 200 samples per iteration... All is working well after having the application run for 10 mins...

Having a deeper dive, I see that during the 10 mins of continuous DAQ, the device (USB 6218 BNC) during any single iteration has a max of 60 samples per channel on the buffer with a mean of 15 samples per channel per iteration across the entire 10 min period...

---

So you read 200 samples each 100ms, but after 10mins you only get 60 samples even though you request 200 samples?

I don't think I understand your problem correctly from your description…

Why don't you attach your VI?

[jcannon]

Hi GerdW,

My code is a bit of a mess while I am still working through it... I have attached a snippet of the segment I am referring to...

I am attempting to determine how many samples from each channel remain on the device buffer each iteration (i.e. how many samples out of the 200 read stay in the buffer until the next loop.

I hope this makes sense...

[GerdW]

Hi Jack,

---

@jcannon wrote:

I am attempting to determine how many samples from each channel remain on the device buffer each iteration (i.e. how many samples out of the 200 read stay in the buffer until the next loop.

I hope this makes sense...

---

When you read those 200 samples from your DAQ device then those samples are removed from the buffer.  When you read the "num of avail samples" after that than you see the number of samples that are acquired AFTER your read request…

Or to put it in other words: "no sample out of the 200 read stays in the buffer"!

[Kevin_Price]

The # remaining samples sounds a little higher than I'd expect, but if you didn't exceed 60 over the course of 10 minutes, you were never approaching problem territory.

What else is in the loop?  Hopefully you didn't overconstrain the timing by including some *other* 100 msec wait timer in parallel to the implied 100 msec timer you get from reading 200 DAQmx samples from a 2000 Hz task...

-Kevin P

[jcannon]

GerdW, thanks... That makes sense...

[jcannon]

Hi Kevin,

Nothing else is in the loop... Just the DAQmx Read... I use a queue to send the data as it is read to another loop for plotting/visualisation...

The 60 value is the max value detected within any single loop iteration during that 10-minute period...

[Kevin_Price]

Just thinking out loud...

Your 15 sample mean still seems a little high to me -- that's 7.5 msec at your sample rate.  Part of me wants to just chalk it up as one more confirmation of my bias against USB devices, but another part remains curious.

What is the median value of "available samples"?   Or better yet, can you post a histogram?  Have you done longer runs like an hour or two?   Nothing so far suggests a problem that needs solving, but longer runs can  sometimes reveal things not apparent in short or medium runs.

Note: I would consider an occasional max of ~60 samples (30 msec) to be not particularly surprising for an app-level software loop under Windows.

-Kevin P

[mcduff]

One major problem here is the code. It is extremely fragile and not well suited for your application. I am assuming you are using the code here

You have a QSM where the event timeout sending a command to do the DAQ read. You are queuing up multiple read events because your timeout is 0. This will not be successful in the long run.

You don't need a QSM for the DAQ acquire data; it can be done in a single loop and and state machine. You can then add a parallel loop to process the data. The example I modified for you earlier can easily be adapted to a single loop and state machine. Reads will only occur when triggered by the device, not some arbitrary timeout in an event loop.

Please rethink your code.