DAQmx Buffer Overflow?

[faustina]

We are trying to acquire data and display it in real-time both in tabular and graphical formats. We think we have a buffering problem because there is a delay between where the signal is at and what the display outputs that increases over time.

For example, when we apply a sinusoidal voltage with a known frequency as our input signal, the values on the display show the values changing at a much lower frequency than it is in reality. When we turn off the signal source, the displays continue to show data for a certain period of time instead of immediately stopping.

We are programmatically building our tasks in the following order:
1) create tasks
2) add channels to task
3) set sampling clock for each task
4) read each task

Please see included screenshot and and code that shows the VI that reads each task.

Each task has its own sampling rate. We are not noticing any errors when building the tasks, but after collecting and displaying data for a few minutes, the displays stop updating. Increasing the buffer size seems to delay this, but the display always stops at some point regardless of what the size is set to.

We discovered that the value of CurrReadPos of the read process continuously increases, and the stop occurs when it reaches the value of TotalSampPerChanAcquired.

Any ideas on what our problem might be? Any guidance on mitigating this would be greatly appreciated.

We are using Labview 2016 32-bit, and the devices being read are :

Chassis: PXIe-1065
Cards: NI PXI-6133 (4x)
4 tasks:
- 7, 8, 8, 8 channels --> 31 channels total

Chassis: NI SCXI-1001
Cards: SCXI-1102C (2x)
1 task (2 modules)
- 21, 28 channels --> 49 channels total

In all there 5 tasks being run with 80 channels in total.

[Kevin_Price]

Not enough info to tell.  I'd especially want to see the calls to DAQmx Timing for sample rates, Finite vs Continuous sampling, buffer sizes.  Also, do you ever explicitly call DAQmx Start for the tasks?  Note: DAQmx Timing defaults to Finite Sampling with a 1000 sample buffer if you don't wire values explicitly.   

Your calls to DAQmx Read do not specify a # samples to read.  DAQmx Read defaults to the "magic number" -1 if you don't wire a value for # samples to read.  The resulting behavior will be *very* different depending on whether you configured for Finite vs. Continuous sampling.

Your problem is likely solvable, but more info is needed.

-Kevin P

[faustina]

Timing is split between two applications.  I've enclosed 2 PNG files.  SetupChannelsMOD VI shows how the channels are added to the tasks.  Acquire Data VI shows how the tasks/channels are read.  It is Continuous sampling and DAQmx Start is never explicitly called.

[Kevin_Price]

I'm afraid the latest things you posted still aren't enough to go on, but I also can't commit to the time it would take to dive in and understand all the things you didn't post yet.  Comments in the code show that this code has been in the works for more than 7 years.  I'm not going to be able to absorb it all in the few minutes I can give it.  So I'll limit myself to the limited comments I *can* make.

Your "Acquire Data.vi" does not specify the # samples to read.  So DAQmx will use the default and value -1 which has a special meaning.  Under Continuous Sampling, DAQmx Read will give you whatever # of samples are already waiting for you in the task buffer (because they've been delivered by the driver since your previous call to DAQmx Read).  So each time you get data back from DAQmx Read, you should be pretty well caught up with real time.  Consequently, I don't think that "Acquire Data.vi" is the source of the lagging behavior you see.

More likely, the higher level code (which you didn't post) that *calls* Acquire Data.vi is probably bogging down for some reason such that it can't call Acquire Data.vi nearly as often as you'd like.  Even though each call catches you up to the present tense, there's probably something causing a growing and perceptible extra delay between such calls.  And hence the sense of lag.

One fairly common culprit is an infinitely-growing dataset that keeps getting re-graphed each iteration.  Or a growing output file that gets rewritten every iteration.

-Kevin P

[faustina]

To help diagnosis the bottleneck, what functions or properties could I use to examine the amount of memory used in the FIFO of the card(s), the PC Buffer in RAM, and the ADE memory?

[Kevin_Price]

- I think it's quite unlikely that the cards' FIFO(s) are contributing to this

- As to the task buffers in PC RAM, you could do the same query for "Available Samples" *before* the call to DAQmx Read.   You may as well leave the post-read query in place too, though it should only be giving you small #'s since your Reads would have just retrieved all available samples an instant earlier.    The new pre-read values you get, combined with the tasks' respective sample rates, should let you know how frequently "Acquire.vi" gets called.   Time between calls should be (available_samples / sample_rate) and should agree pretty well among all the tasks.

- I've had a considerably worse experience evaluating memory or CPU usage with LabVIEW's profiling tool than others seem to.  The times I was inclined to use it for clues almost never yielded anything useful.  Same goes for Windows tools like Task Manager.  i suppose certain glaring problems might show up such as loops with no sleep time or constantly growing memory usage.

    Others seem to point to the profiler fairly regularly though, so you may as well give it a shot.  Maybe it's best at catching things I don't happen to do.

-Kevin P