From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx Slow Down after some Time Without Restart

Hi all,

I have an Issue with the DAQmx Labview API. I have a VI which creates a task for the DAQ, reads a Voltage and then deletes the task again. After a restart of LabView this works as expected and i can run the Task at several Hz. But after some time of LabView being open (1-2 Weeks) it suddenly gets slower in the sense, that if i run this VI in repeat, it will always run at normal speed for 5-10 iterations. But then it gets stuck at the dll call to nilvaiu.dll and the call takes 1-3s. Afterwards it runs moothely for 5-10 calls again. The only way to remedy this situation is to restart LabView, upon when it works again for some time.

This Problem only appeard after upgrading from LabView 2015 to 2021.0. Is this a LabView internal problem or has it to do with Windows searching for the API?

4KMRFM_0-1684146980243.png

 

0 Kudos
Message 1 of 2
(414 Views)

This is pretty speculative, but you used the phrase "if I run this VI in repeat".   Are you either:

 

A. using the Run Continuously toolbar button?   Kevin_Price_0-1684155492766.png

 

B. Repeatedly calling this subvi in a loop, with little to no delay between calls?

 

I've learned from experience that the whole process of clearing a task can continue for a short time in the background even after dataflow execution has returned from the call to DAQmx Clear.  My understanding is that some clearing processes get launched to take care of freeing up resources, but DAQmx Clear doesn't wait for them to confirm completion before returning.

 

This can lead to problems if you immediately attempt to re-reserve resources that are "just about to be free" but perhaps not truly all the way free yet.

 

I'm sure it's all system dependent but my recollection is that even 1/4 second seemed to be a sufficient delay.

 

I'd further recommend the following as good habits, mostly related to making your task config more visible and explicit

A.  wire up the 'sample mode' input for DAQmx Timing.  The default is Finite Samples, but it's a good habit to declare that explicitly in the code to show intention.

B. make an explicit call to DAQmx Start to start the task before reading from it (and later, an explicit call to DAQmx Stop to stop the task before clearing it).

C. in the call to DAQmx Read, explicitly declare the number of samples to read.  The default value is the magic # -1 which has a special meaning.  If you *want* that special meaning, wire in an explicit visible -1 value to show intent.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 2 of 2
(384 Views)