Odd delay on starting an exe using DAQmx

[minnellac]

I'm seeing a very odd delay when launching a program that loads a LabVIEW generated DLL that uses DAQmx. I see the same thing on a LabVIEW EXE, and maybe also on a loading a LabVIEW VI that calls the LabVIEW DLL. The funny thing is, this delay only occurs when the sensors are connected. In this case, I'm using two 4462s with about 50' of cable with a few connections in between and IEPE accels. I don't see a delay when connecting sensors directly with a few feet of cable, or when the sensors aren't connected to the cable.

I'm going to attempt to narrow the problem down to a particular card or sensor tomorrow. The delay lasts about 2 minutes and occurs before the vi loading screen appears. When launching the C program that loads the LabVIEW dll on launch, basically I get no feedback, but the process does appear in the task manager. When loading a LabVIEW vi from a project that calls the dll, I get a busy cursor until the loading vis screen comes up. So, the question is, what is going on before that VI loading screen appears?

This is all before any of my code executes, so I don't see how any software configuration comes into play.

Any thoughts?

Chris

[minnellac]

I created a test vi that calls the dll by path. With this, I can measure the time it takes for the dll to load. Curiously, it takes different amounts of time when launching labview and running the vi, closing the vi and reopening it (with LabVIEW remaining open), and just running the vi multiple times. Once I started measuring the time, I experimented with different things.

Bottom line up front, it is the network connection, not the sensors (yay, because that made no sense). I'm on a lab network with no internet access and possibly no dns.

When connected to the network and starting with LabVIEW closed, the program takes ~136seconds to load the dll and run the function. Closing and opening the vi results in about 40 seconds. Rerunning the function from the running vi takes <1second.

When the network cable is unplugged, the same sequence of tests take <2seconds regardless.

So, it looks like something it trying to use the network when this dll is loaded. Can anyone tell what it is and how to tell it to stop?

Thanks

Chris

[Craig_]

Since removing the network makes it work so much faster I wonder if it is to do with looking for devices on the network. What DAQmx tasks are you running and does the user have options to select them? Also, does your MAX have any remote systems connected to it which it may be trying to connect to?

[minnellac]

Actually, all the tasks are created on the fly in the software. No predefined tasks are created in MAX. There are no NI remote devices on the network, but I am talking to a PLC over TCP. The user doesn't have any ability to configure the system from the UI; it is all done via config files.

For reference, the PXI system is composed of a PXIe-8133 controller, 2 PXI-6230s and 2 PXI-4462s. I can't remember whether I mentioned this before, but I can disconnect the Ethernet cable, run the software, and then reconnect the cable to speed up the start without any ill effects. Whatever it is doing, it doesn't seem necessary.

Thanks

Chris

[Craig_]

The LabVIEW dll has to load the LabVIEW Runtime Engine when called, and this may trigger the start of a couple NI specific system services. If those services aren't set to load automatically the delay you are seeing could be due to them polling both system devices and the network for devices for appropriate DAQ devices (even if there aren't any configured in MAX).

You can check service settings by going to Start -> Run -> services.msc and checking the status of NI Device Loader and NI mDNS Responder (they should be set to automatic start). NOTE: The names of these services changed due to one of the recent DAQmx driver versions, hopefully you see them under the same name.

[minnellac]

I feel like this is progress. Unfortunately, I don't have access to the system anymore (it is at a customer site), but I think I can reproduce the conditions here. The system's configuration should be default, so I don't see any reason why those services wouldn't be set to auto start. Is there a service that I could disable that would prevent this issue (and not break my software)? Just based on the name NI Network Discovery looks like it could be a culprit.

I am going to try to reproduce the issue here, and we'll try disabling things to see if it has any impact. Is there any list of mandatory services?

Chris