Unexpected time delay on the first call of DAQmx Write (Digital Out)

[FL MC 2010]

Here is the background to my problem:

Hardware:  PXI-1052 chassis with a 6704 controller and PXI-6704 card, and 8 SCXI-1166 relay cards.  We also have 5 SCXI-1001 chassis with 1102b's, 1102's, 1104c's, and 1124's.  Total channel count is around 1200 analog in, 400 digital outs.  Each DO card is configured as its own DAQmx task.

Software: LV 8.6, DAQmx 9.1.1, Windows Server 2003.

The problem we've been having is that we command a group of 8 digital out channels using the "Digital 1D U32 NChan 1Samp" version of DAQmx Write.  We write a 1D array (with 1 element) of a U32, and then command another 8 DO channels after a precise time delay.  Recent testing has shown that the first time this task is called, e.g., for the first time in a long time, there is a delay between when DAQmx Write issues the command, and when the relay actually actuates, as measured by voltage feedback measuring the output when the 1166 relay closes.  This causes the precise time delay between the 2 sets of 8 commands to get squeezed because the 1st set of commands takes ~40 ms too long to happen.

I ran Windows Monitor during the latest round of test runs, and on the first call of DAQmx Write for that task, there is a ReadFile operation with the path nilvaiu.dll right at the time of the 1st commands.  This corresponds to the delay we've witnessed.  A subsequent run with Windows Monitor did not show this .dll ReadFile call, and there was no delay in our timing results. We have seen this behavior repeatedly, where the first time a DAQmx task is accessed to issue a digital out command in a long period, there is a delay.

Questions:

1. Does DAQmx need to call nilvaiu.dll to re-activate a DAQmx task after a certain idle period or overnight?

2. Are there other operations that LV needs to perform to re-allocate resources for a DAQmx task?

[Sean_F]

Hi FL,

What's probably happening is Windows is loading the function into memory. One way to avoid this delay would be to issue a dummy DAQmx Write call before your control loop starts. This should work if there is only a delay when DAQmx Write is called for the first time in a long period of time. I'll look into some other options on my end.

Sean

[FL MC 2010]

Thanks for your response.

We have thought of ways to do a dummy command like that, but we don't understand why Windows needs to load the function into memory after a long idle period.  This software runs pretty much constantly, so we don't have a simple startup script that is run frequently. 

How do we know how long the idle period has to be before the DAQmx function leaves Windows memory?

Thanks.

MC

[Sean_F]

Hi MC,

In general, Windows' memory manager will add and remove pages from memory as they're needed. If a certain section of code is not used in a long time Windows might overwrite it. There is no simple way to determine this time. If you were to use NI Switch, the dll would be loaded into memory when you open the program in labVIEW. For some examples, go to Help » Find Examples » Hardware Input and Output » Modular Instruments » NI-SWITCH. However, if you want to keep the code you've already written using DAQmx, use the DAQmx Switch Open Relay VI as a dummy VI.

[FL MC 2010]

Sean,

And there is no way to force a DAQmx task to remain in memory indefinitely, regardless of what the OS needs?

Thanks.

MC

[Sean_F]

Hi MC,

I'm not aware of any way to keep a section of code in memory other than by executing that code. The simplest thing to do would be to insert that dummy switch open call like we discussed earlier.

Best,

Sean F.

[Brad_K]

Hi MC,

It doesn't sound like the DAQmx task is being removed from memory; rather, some of the executable code that is used by DAQmx and LabVIEW is being removed. As far as LabVIEW is concerned, everything remains in virtual memory. The virtual memory pages that are present in physical memory are the process working set. Pages that are removed from the working set may be discarded (e.g. executable code like nilvaiu.dll or LabVIEW.exe) or written to the pagefile.

There are ways to control this behavior:

• The SetProcessWorkingSetSizeEx function may allow you to keep LabVIEW's working set from dropping below a certain size. This could be useful if there is memory pressure from other applications running on the same system. However, if LabVIEW's working set becomes too large, it will still be trimmed, and this function won't control which pages are trimmed.
• The VirtualLock function forces Windows to keep specific pages in memory, but there's a catch: you have to find them first. Finding the locations of executable modules like LabVIEW.exe, nilvaiu.dll, etc. is doable, but that's not the entire picture: if data structures associated with specific DAQmx tasks, VIs, etc. are removed from the working set, they will be written to the pagefile, and accessing them will incur a page fault. Even if you searched the entire process virtual memory for committed pages and locked them all, some DAQmx kernel-mode data structures may get paged out.
• You can disable the pagefile, but that will probably make the problem worse, not better. Forcing more data structures to be stored in physical memory can cause Windows to discard more executable code (because executable code can always be re-read from disk).

Controlling the working set size might help, and is certainly worth a try, as well as Sean's suggestion of calling the DAQmx Write function more frequently. However, Windows isn't a real-time OS, so deterministic timing for single-point I/O is not guaranteed. How many channels require precise timing? If the answer is "a few", adding a device that supports hardware-timed DIO (such as X Series or CompactDAQ) might be a reasonable solution. If the answer is "all of them", you might want to look into LabVIEW Real-Time.

Brad