11-22-2010 01:26 PM
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?
11-23-2010 11:40 AM
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
11-23-2010 12:04 PM
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
11-23-2010 01:19 PM
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.
11-23-2010 04:24 PM
Sean,
And there is no way to force a DAQmx task to remain in memory indefinitely, regardless of what the OS needs?
Thanks.
MC
11-24-2010 03:01 PM
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.
11-30-2010 07:48 PM
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:
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