DAQmx Apparent Memory Leak

[JÞB]

---

@crossrulz wrote:

---

@Kevin_Price wrote:  I've been used to creating them programmatically at run time for so long that I don't even give it a second thought.

---

Same here.  I just keep a library floating around to build up the task from a configuration file.  I have also had to do too many dynamic setups, hence the configuration file.

---

Tim! Why Why Why create your own configuration file when LabVIEW does it for you?  We've had this discussion before,  I'll put it in the nugget

[MichaelBalzer]

Just reporting that I also ran into this exact issue recently on a (very) legacy system. The code base is big and old, having gone through updates from LV7.1 to LV8.5, then a large update to LV2010 with updates from Traditional DAQ to DAQmx (including a loop creating and clearing tasks). This version has been in place and running for years without any memory leaks or crashes.

The newest update to LV2018 + DAQmx 18.1.0 began seeing crashes after 3-4 days, and was eventually traced back to repeated calls to DAQmx create task and clear task. The fix was to create tasks, then start and stop them as necessary rather than clearing them.

FWIW, the help on DAQmx task creation and clearing mentions memory usage:

"To use the DAQmx Create Virtual Channel VI or DAQmx Create Task VI in a loop without allocating additional memory on each iteration, use the DAQmx Clear Task VI in the same loop after you are finished with the task."

Hopefully the bug is fixed soon.

[mcduff]

My issue also appeared after an update to DAQmx 18.

mcduff

[hwilterdink]

Wanted to circle back around to two of Jeff's points. He suggested two ideas for fixes, which I tested on our systems which have been showing this issue (these are quick modifications to the code I posted originally; see attached screenshots). The test here is letting the code run for about 30 minutes, at which point the apparent memory leak (if present) is easily visible in Windows Task Manager (RAM usage increasing by about 4 kB/s).

(1) Decrease Timeout input on the DAQmx Read VI, ideally so that (DAQmx Read Timeout) < (LabVIEW Event Timeout = 5 ms). The lowest DAQmx Read Timeout is zero, which tells the VI to try reading once and return an error if unable to. The whole sequence (create task, read DIO, clear task) may still more than 5 ms, but that has already been noted in other comments. Anyway, setting the DAQmx Read Timeout to zero has no effect--that is, the apparent memory leak is still present. The null result here seems best explained by crossrulz's description of the LabVIEW Event Structure timing earlier in the thread.

(2) Name the DAQmx task, so that DAQmx somehow "knows" that the new task you're asking it to create is really an old task, and therefore deal with it more intelligently (?...not 100% sure on my understanding of Jeff's comment here). Anyway, naming the DAQmx task also has no effect--the apparent memory leak is still present.

MORAL OF THE STORY: The ONLY fix so far has been to re-use DAQmx tasks (rather than repeatedly creating and destroying them, as noted in several responses to this thread)! This is suggested practice anyway, and is a win-win scenario for this particular code example (avoiding the apparent memory leak while likely enjoying faster execution speed).

Thanks for the continued contributions. I am certainly still open to any other insights from the DAQmx experts in the community 🙂

[mcduff]

Please feel free to add to this list:

Places where DAQmx Tasks can be reused (AI tasks here, no real experience with other ones):

1. Changing the sampling rate, number of samples
2. Changing the gain of the input channel
3. When using the logging API, changing the file name, save or not save
4. Adding channels to the task

Places where DAQmx Tasks cannot be reused (AI tasks here, no real experience with other ones):

1. Removing channels from a task
2. Changing from log only to log and read with the logging API, some properties do not transfer
3. Changing the names of the virtual channels

mcduff

PS @hwilterdink Have not had a chance to try it, but does running the "Create Task vi" in a loop cause memory leaks. I wonder if it is the creation of "reference" or some sort of reserving of resources that creates the memory leak.