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

[Craig_]

Typically the two main services which load devices into MAX are NI Device Loader and NI mDNS Responder, so if they are the cause of the inconsistent load times then I would start by looking into those.

[minnellac]

Okay, so we've spent time on this and haven't made any progress. I created a vi which dynamically loads a labview dll when a button is pressed on the front panel. This way, I can time how long it takes to load the dll. After the first time the vi is run, it runs quickly on subsequant runs. Closing the vi and reopening it reintroduces a delay, but there is quite a bit of variability in the run time at this point. The most reliable measure seems to be quitting LabVIEW, Launching LabVIEW (by double clicking on the vi), and then running the vi. We've found that the time involved in launching LabView also changes dramatically based on the network connection, but that is harder to time accurately. These results are from testing done on our development network (no internet access).

Summary:

 - all services running, network connected (but no internet). Time to launch LV - long, time to load dll, 37 seconds.

 - all services running, network not connected. Time to launch LV - short, time to load dll, 1.3 seconds.

 - all other tests produce the full 37 second delay on running the vi and loading the dll; we tried stopping and disabling each of these services individually and all together:

• National Instruments Domain Service
• National Instruments LXI Discovery Service
• National Instruments mDNS Responder Service
• National Instruments PSP Server Locator
• National Instruments RIO Server
• National Instruments Time Synchronization
• National Instruments Variable Engine
• NI Application Web Server
• NI Application Web Server (64-bit)
• NI Configuration Manager
• NI Device Loader
• NI Network Discovery
• NI PXI Resource Manager Service
• NI System Web Server
• NI TSU Clock Service
• NI-488.2 Enumeration Service
• NILM License Manager

I really don't like that the way I need to tell the customer to run our software is to disconnect the network cable when launching the program, and then plugging it in immediately afterward. Any other suggestions? Any illumination on what is going on when loading a dll could help.

Chris

[minnellac]

I was able to reduce the delay from ~37seconds to ~18 seconds by disabling .NET CLR Certificate checking. I found a blog post that descirbes the problem, and it actually links back to an NI page. I don't feel like I've solved my problem yet. At the actual customer site (with the real hardware) we are seeing in excess of 2 minutes delayed on launch. I feel like this was probably a part of that, but there must be something else going on. Are their any other certificate checks, or something similar?

Chris

[Craig_]

What version of LabVIEW are you running on the PXI system and on your computer?

What version of DAQmx are you running on the PXI system and on your computer?

What version of Windows are you running on the PXI system and on your computer?

If it is related to CLR checks there was mention of a Microsoft .NET 2.0 patch amidst what you linked previously: http://support.microsoft.com/kb/936707

It may be worth it to check for Windows updates as this could have been resolved through one of those.

It's odd that disabling CLR checking helped as the article only discusses it in reference to older versions of Measurement Studio: Starting with Measurement Studio 8.1, Measurement Studio assemblies will no longer be authenticode-s... This does not seem to be the case with your system, but there may be some other checking going on.