Slow behavior of DAQmx Task property node

[eaolson]

It's taken me forever to track down why an application was running so slowly, and I think I've tracked it down to the behavior of the DAQmx Task property node. See the attached VI.  I should point out this is running on an RT target.

If I use Create Channel to create a task, then use the DAQmx Task property node to find which devices are in the task, it takes roughly 20 seconds for the property node to execute. If I verify the task first, using DAQmx Control Task, it only takes about 150 ms. The weirdest thing is that this only happens the first time I do this after rebooting the target. Any execution after the first, and it only takes about 150 ms. I understand if the property node needs to put the task in the verified state that it might take some time to do that, but why would manually verifying the task be so much faster? And why would it only affect the first run?

This is under LV 7.1.1 and DAQmx 8.3.

[MickeyD]

Hi,


I have tested your code out on an RT target, but I didn't see similar results. I wanted to check a couple of things that will help me to try and reproduce this problem.

1   I assume if you run this code in windows you don't see similar behavior? If you do see odd behavior what is it?
2   What hardware you are using when you run this code? RT controller and modules. It might be my RT controller was a newer model, so I did not see this behavior.
3   Are you running this code as an stand alone application, or just executing it on the real time target, when you see the behavior?

Have a great Evening,

Michael

Message Edited by Mike_D on 10-16-2006 05:22 PM

[eaolson]

For some reason, the manual verify step doesn't seem to make the first invocation of the property node any faster any more. I wonder if I initially had the verify step before the call to Tick Count. Still, the first call to a DAQmx property node after rebooting the RT hardware takes a very long time, and subsequent calls to it take much less time. This only seems to occur when the property being retrieved is "Devices" or "Number of Devices".

To answer your questions:

1. When I run the code on the Windows computer, using simulated DAQmx devices, I do not get the same behavior, correct.

2. The controller is a PXI-8186 in a PXI-1042Q chassis. The chassis also has two PXI-6733 analog output boards in it. The host is running 7.1.1, the RT target is running Real-Time 7.1.1, and both are using NI-DAQmx 8.3.

3. It seems to happen regardless of whether I run it from LabView on the host PC and targeting the RT hardware or as a startup executable on the RT target. I modified the VI above to run at startup and log the results to a file. Below are the results of calling the property node once at startup, and then once from my host PC using VI Server.

16:57:43 10/17/2006 result=23142
17:00:32 10/17/2006 result=172

You can see that the first call took 23000 ms, and the second run took only 170.

[MickeyD]

Hello,

Thanks for answering the questions and something is occuring that your DAQmx drivers are not loading before the VI runs. I am not seeing the same behaviour, but have only so far been able to run your program on LabVIEW 8.20 and 8.0 RT systems. I am currently trying to find an available RT system with LabVIEW 7.1.  I am going to contact the RT support team and see if they have one available, and have already forwared this thread to them to see if they have seen similar behaviour before.

Have a great evening,

Michael

[eaolson]

Thanks. I've gotten around it by parsing the string originally used to specify the channels for DAQmx Create Virtual Channels, but it would be nice to know what's going on or what I'm doing wrong.

[Jonathan_Brumley]

Hi,

I think you are running into possibly 2 different issues:

1) The DAQmx Task - Devices property can be _very slow_ when you have a lot of channels in your task.  We recently looked into this issue here on the DAQmx team and we are planning a fix that will speed up the performance. 

2) The first DAQmx operation you do after a reboot can take a long time if the driver has not finished initializing.  Also, DAQmx will take even longer to initialize on the _very first_ boot of your RT system (compared with subsequent boots).  We added some improvements to initialization for DAQmx 8.3, but DAQmx still requires a lot of initialization (the more devices you have, the more initialization will be required).  We are aware there is still some room for improvement here and are considering some possiblities.

I think the workaround you are using (parsing the channel string) is a good workaround for the problem with the DAQmx Task - Devices property node.  I recommend trying the DAQmx Task - Devices property again after you upgrade DAQmx.  Hopefully you can remove your workaround at that point. 

Jonathan

[eaolson]

1. About how many is "a lot" of channels? Right now, I'm using two tasks, each with one device with six or seven channels.

2. When does the driver initialization begin? I rebooted the controller, downloaded my application, and waited about 20 minutes before actually running it. No effect. Also, putting a 60 sec Wait between creating the task and the Task property node had no effect.

[eaolson]

[Double post deleted.]

Message Edited by eaolson on 10-24-2006 01:48 PM

[MickeyD]

Hi eaolson,

I was looking at what Jonathan had mentioned. I only saw this behavior when i worked with more than four channels in DAQmx. If I had more than four channels i did see the behavior you described. I had used a smaller number of channels before, because I didn't have a high analog output channel card and was worried it might have something to do with analog output tasks, but it turns out the channel count is the deciding factor. I also so this behaviour on windows system when using not using simulated devices. Congratulations on finding a workaround for you application, and thanks for helping to bring this issue to our attention. Please let me know if you have any further questions regarding this issue.

Have a great day,

Michael