NI DAQmx Stop task is slow

[dpacaba]

Hello All:

I have the following system:
NI LabVIEW 7.1.1
NI DAQmx 8.0
NI PXI-8196 Pentium M 2.0GHz Controller with 2GB RAM
NI PXI-1031 4-Slot Chassis
   PXI1Slot2 = NI PXI-6221
   PXI1Slot3 = NI PXI-6221
   PXI1Slot4 = NI PXI-2570

Actually, this system is being used for simultaneous testing.  For example, while the NI 6221 DAQ card at PXI1Slot2 is performing synchronized AI/AO, the NI 6221 DAQ card at PXI1Slot3 is performing another AI/AO task independently among each other.  I peform testing for one at a time and system is working perfectly.

The problem is when I perform continuous synchronized AI/AO on one DAQ card and the other DAQ card performs another continuous AI/AO task, the "Stop task.vi" is very slow.  I perform benchmarking by placing a "tick count" before and after the vi.  It takes around 100-200 milliseconds.  Although I checked using an oscilloscope that the output stopped immediately after I called the "Stop task.vi".
It seems that there's something that LabVIEW is waiting for although he already stopped the AI/AO.

What does the "Stop task.vi" waiting for although the NI-DAQ card already stopped the waveform generation? Can this be reduced? Does NI-DAQmx has some kind of functions to improve performance or memory or bus allocation?

Thanks in advance.
Please advice if there's any information that you need.

[Jonathan_Brumley]

Hi Debonair,

I have measured that Stop Task is _normally_ about 200 microseconds (not milliseconds) on my Dell workstation.  I haven't measured it on an 8196 but I suspect the time is similar.  So you are right, the fact that Stop is taking 200 ms indicates there is something odd going on.

Inside NI-DAQmx, when you call Stop, we immediately stop a task in the hardware.  However there is some additional delay because we have to wait for a secondary thread to finish some cleanup processing.  The reason we use a secondary thread is somewhat complicated so I won't go into that here.  Unfortunately this is not configurable so there is no way you can disable this thread from executing.  However, under normal circumstances, this additional delay is very small (only a few microseconds), so I'm not sure it completely explains your problem.  However, it could be a factor depending on how soon the OS allows the secondary thread to run.   

It could be some additional information will help diagnose this:

1. Is your 8196 controller running LabVIEW ETS or Windows? 
2. Have you tried tweaking the priorities of your application or of your data acquisition VI? 
3. Is your synchronized AI/AO task putting a heavy load on the system?
4. How many samples are you reading or writing at a time?

[dpacaba]

Hello Jonathan:

Thank you very much for you help.

Yes, I suspected that. I'm not planning to eliminate this "secondary thread". I'm trying to figure out the reason why this "secondary thread" is delayed.  And that is the one I'll eliminate.

Anyway, answers to your questions.

1] I'm running Windows XP
2] Priority: High, Preferred execution system: Data acquisition, Reentrant execution: True.
3] I'm not sure. The problem does not occur when I'm using only 1 DAQ card.
4] The most critical test step:
    AO Continuous: 100kS/s, approx 1000 samples, single channel
    AI Continuous: 100kS/s, approx 300 samples per read, single channel

PS
Another information although I'm not sure if it's useful.
There's no LabVIEW installed on PXI.  I built an executable on another PC and deploy it on PXI.

[Jonathan_Brumley]

Hi Debonair,

Here are a few ideas:

1. You're not going _extremely_ fast, but it is possible that once you add the second task, you will notice some big delays because your computer is struggling to keep up with both tasks.  You could try to gather more timing information by putting some timers around the calls to DAQmx Read and DAQmx Write in your primary task and see how long they are taking.  However, be aware that the LabVIEW tick timer may not be very accurate when trying to measure functions that take less than a few milliseconds.  2. Double check the setting for the DAQmx Read Property called Wait Mode (in the Advanced sub-palette).  Make sure the Wait Mode is set to sleep, and make sure the sleep time is set to a non-zero number.  Do the same for the Wait Mode property in the DAQmx Write Property Node.  By ensuring the sleep time is a non-zero number, you are giving the operating system time to run other tasks so that other tasks are not starved.  However, since you are using DAQmx 8.0, then I think the default values will be good enough for you.

3. It is possible that since you have set the LabVIEW priority very high, that your LabVIEW threads are starving the NI-DAQmx thread in the kernel, causing it to take longer to execute.  (priority inversion)  If this is the case, it could indicate a bug in the NI-DAQmx driver, because NI-DAQmx should be setting the priority of the internal secondary thread to be at least the same priority as the foreground thread.  You could try to set the priority lower and see if your DAQmx Stop call gets faster.  However, the overall throughput of your application may decrease.

4. You could try using DAQmx Abort instead of DAQmx Stop and see if it is any faster.  However, this could have some side effects, so I don't recommend this unless you do some more testing.

If this doesn't help, but if you can isolate what you are doing to just DAQmx calls and post a VI that reproduces the problem, then I will try to run it on my computer and figure out what is going on.  I'd like to help you fix this problem if possible, or identify the NI-DAQmx issue if there is one.

[dpacaba]

Thanks.  You have been a very great help.