From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview built *.exe does not function without an automatically generated *.run file?

I have an Labview 2014 built executable that, on first execution, will not function properly to the front panel GUI controls (start, stop, etc). When I quit the executable, it automatically generates a GUI.run file extension.. and I need to hardkill (Ctrl-Alt-Del) the program.  On subsequent executions of this executable, now with the GUI.run file in the same directory, the program functions as expected. I have Googled and searched what this automatically generated file is, and cannot find any references to it. Any help here? 

0 Kudos
Message 1 of 5
(2,423 Views)

Never seen that.

 

What OS is this? (since you say *.exe, I assume windows) Is this real windows or some emulator running on some other OS?

 

Is there anything unusual with your application? Any third party components? (matlab, etc.)

0 Kudos
Message 2 of 5
(2,412 Views)

Yes, this is essentially a software controller for a temperature controlling device, Watlow F4, with a GUI interface for user's to Stop, Start, Load temperature profiles, and monitor temperature readings from the device. The Labview project file and vis, run fine.. no issues.

 

However, the built executable has this funny issue where it needs a first instance generation of this GUI.run file in order for it to run properly. The GUI is programmed with event structure and appears that the GUI portion does not function on the very 1st execution without this generated *.run file. 

0 Kudos
Message 3 of 5
(2,399 Views)

I think that this kb could be helpful here: 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PAiTSAW   - Remotely Debugging Executables in LabVIEW 

 

Perhaps debugging the executable could help you determine at what point the .run file is generated, then figure a way to handle whatever causes the freeze. 

 

You could also build an installer that includes the GUI.run file in it and see if running the installer will give you an application that skips the error at the first execution. 

 

I hope this helps!

 

0 Kudos
Message 4 of 5
(2,320 Views)

@ConnieS wrote:

Yes, this is essentially a software controller for a temperature controlling device, Watlow F4, with a GUI interface for user's to Stop, Start, Load temperature profiles, and monitor temperature readings from the device. The Labview project file and vis, run fine.. no issues.

 

However, the built executable has this funny issue where it needs a first instance generation of this GUI.run file in order for it to run properly. The GUI is programmed with event structure and appears that the GUI portion does not function on the very 1st execution without this generated *.run file. 


I am guessing that the application itself creates that file (e.g. as an configuration file) if it is not there. Most likely you have a race condition where another part of the code tries to access it while it is still being created/locked by another code section, for example. If it needs to be there, include it with the installer. Then you should also fix the race condition and improve error handling to make the code more robust dealing with unusual conditions such as this.

Message 5 of 5
(2,301 Views)