Labview Built Executable - Long Runtime Startup Time

[tyk007]

Hi All,

I have a LV 2011 SP1 application that has been built (executable) on a development machine running Windows 7 Professional. The application is copied to the target runtime machine. This machine has the LV 2011 runtime plus other DAQmx pre-requisites. The target machine is also Windows 7 Professional, an quad core @ 3.3GHz Xeon machine that, on paper, is significantly faster than the development machine.

I run the built application on the development machine. It takes around 1-2 seconds for the Startup VI Front panel to show. The application loads and runs. So far so good.

I run the built application on the runtime machine. It takes just over 90 seconds for the Startup VI Front panel to show. The exe process during this time is showing 0% CPU usage and a very small memory footprint (around 32MB). Eventually the Startup VI is shown and CPU usage and Memory consumption climb almost immediately to around 2% and 80MB. This is normal. From this point on the application runs as it should.

My question - why does the application startup time so dramatically different on the target machine? Is there some other startup process inherent in the runtime engine that is taking longer? I have tried loading the evaulation version of Labview 2011 SP1 on the target machine but this appears to make no difference. I know that this delay is more an annoyance than a show-stopper but my clients are asking questions and it would be good to provide some answers.

Some basic web searches have revealed others having similar problems and often the problem is related to some Windows service or other. I have also disabled the firewall on the target PC (though it is not connected to the internet, just a small IO network with ethernet chassis CompactDAQ modules) with no apparent difference. Unfortunately I cannot disable the virus scanner due to company policies.

Thanks for your help all.

[soupy]

i've noticed this behaviour at our site as well when we run things within the secure sector of the network.i haven't had time to look into it, but i believe that we're seeing the same issue.

i really beleive that this is firewall-related, so i planned on troubleshooting it by logging network traffic and determining what is trying to call home.

[Zachmx]

Have you seen this behavior on any other target machines or is it limited to the one? The firewall issue mentioned by soupy could be a problem as well, so you may want to test on an off-network machine. Also, you might want to make sure your executable is not in debuggable mode when built.

Is your executable interfacing with any external hardware or software? This might be causing a problem on the development machine if there is a difference in driver/file structure configuration.

[VeeJay]

I have been having this problem and it is very annoying. I am unable to figure out what exactly is slowing load time of an exe in a target machine. My target machines (3 of them) are not connected to the network. I have LabVIEW 2012 and am pretty sure all drivers daqmx,VISA, and Runtime have been installed correctly.

I have noticed this issue isn't there when the entire development environment is installed. To troubleshoot, I am using my personal laptop as test site (because I can't travel to other cities to fix it without knowing the solution), and my laptop has no previous installations of LabVIEW. I install the application and drivers using the installer I build, but it is exhibiting the same behavior. I must note here that I did not see this problem for LabVIEW 2010 that I was previously using, but my application design has changed. Nonetheless, I have checked the functionality of my application and am absolutely sure it has nothing to do with slow load times.

I am beginning to suspect some component has a bug in it for LabVIEW 2012 but, I am in no position to validate that. Is there anyone that has found a concrete solution that has made their application open instantly and run?

Thanks a bunch!

V

[soupy]

we've been seeing this issue as well with 2010 sp1. the same executable runs fine on our open network, but they take quite a while to come up when ran on our secure network. it appears to be some sort of firewall issue when the executable "calls home".

we haven't had time to troubleshoot this issue. when we do look into it, we're probably going to wireshark the computer when we boot the gui.

[VeeJay]

The weird thing is even when I "abort" the program, the front panel closes, but the icon on the taskbar remains for about a minunte unitl it disappears as well.

summary: When I open the program, the icon appears on the taskbar first and after a few seconds front panel and after a minute or so, it starts the program.

When I abort/close the program, the front panel closes in a few seconds and after a minute, the icon disappears from the taskbar.

[Yamaeda]

Have you tried unplugging the network cable? I've had similar problems when there's been problems contacting NI, but removing the network cables seems to stop those attempts.

/Y

[maxwellb]

Yamaeda, do you know for a fact that all/most EXEs try to contact NI or some other Internet resource upon startup?

[VeeJay]

Creating a .config file as described in this Knowledge base article solved the problem for me.

http://digital.ni.com/public.nsf/allkb/9A7E2F34EC9DDEDE86257A09002A9E14

[maxwellb]

VeeJay, that article seems to have solved my issue. I used the config file method also.