Executable

[GrantPaterson83]

I am looking for advice running a stand-alone executable on a machine that does not have LabVIEW installed.

I understand that when I generate the executable and move to the LabVIEW-free computer, that I need to install the run time engine. My question regards creating multiple copies of the executable on the LabVIEW-free machine, without having to build multiple copies in the first instance. Am I able to copy and rename the executable and the associated, modified .ini file , so that it I can run more than one routine at a time. However, this just renames the .exe file, but not the embedded vi. and I am concerned about I/O communication conflicts.

Is there a way of copying the exe file and also renaming the associated vi, without having to re-build?

My application is using the same LabVIEW routine to control multiple rigs, which need independent labview exe files.

Advice / solutions are very welcome.

Best wishes,

Grant.

[mikeporter]

I'm trying to understand here, you want to have multiple instances of the same executable on the same computer, and each instance has to have a different name? Why? What are you trying to accomplish?

Mike...

[winterishere8]

---

@GrantPaterson83 wrote:

I am looking for advice running a stand-alone executable on a machine that does not have LabVIEW installed.

I understand that when I generate the executable and move to the LabVIEW-free computer, that I need to install the run time engine. My question regards creating multiple copies of the executable on the LabVIEW-free machine, without having to build multiple copies in the first instance. Am I able to copy and rename the executable and the associated, modified .ini file , so that it I can run more than one routine at a time. However, this just renames the .exe file, but not the embedded vi. and I am concerned about I/O communication conflicts.

Is there a way of copying the exe file and also renaming the associated vi, without having to re-build?

My application is using the same LabVIEW routine to control multiple rigs, which need independent labview exe files.

Advice / solutions are very welcome.

Best wishes,

Grant.

---

I am going to make some assumptions here, please correct me if I am wrong. You would like to invoke multiple instances of an application in your test machine that has LabVIEW run-time installed. Correct? Does your VI have all it's settings documented in an INI or a stand-alone file ?

I wonder: When you install the application on your test machine, if you can rename it while installing. You will essentially perform 2 installations: Application1.exe, Application2.exe. Not sure if that'll work?

[altenbach]

---

@GrantPaterson83 wrote:

My question regards creating multiple copies of the executable on the LabVIEW-free machine, without having to build multiple copies in the first instance. Am 

---

See if this answers your question. I have not tried it.

[Todd_Lesher]

Perhaps create a second Installer build spec that uses a different: "Installer Properties -> Version Information -> Upgrade code"

[altenbach · Accepted solution]

Another option would be to build a master VI that can launch multiple reentrant copies if your instrument controller as needed.

[cirrusio]

Soooo...I know this is pretty stale but a solution was never marked for this.  I think that Todd has hit it though (never really thought to look at this).  From the help:

Upgrade code

—Specifies the upgrade code that Windows uses to identify the installer. If you duplicate an installer  and you do not want the new installer to replace the previous version, generate a new upgrade code. If you want the installer to upgrade, do not change the upgrade code.

Seems to be the way to go...  Thanks for pointing in the right direction Todd.  

[Hooovahh · Accepted solution]

This technique is something I've had success with in the past.  I would make a master installer or what I called an "NI Installer" for the first major release.  So this would contain the 1.0.0 version of the LabVIEW application, and it would include all runtime engines, DAQmx tools, VISA, whatever the application needed.  This would make the installer big on the order of 1-2GB.  This could be installed on any computer without any NI software and run the 1.0.0 version of the program.

Then any builds I made after that, say the 1.1.0 version would be a new build spec that had the same upgrade code, but only containsed the exe.  When this "Upgrade Installer" is ran on a machine after running the 1.0.0 NI Installer, the old exe would be replaced but all the NI software would remain.  This meant I could have new installers be small (20-30MB) but the requirement existed that 1.0.0 needed to be installed first.

In my case we weren't often bringing up new PCs that needed software on them, often it was just making new upgrade installers.

[GrantPaterson83]

Thanks for all the comments and suggestions. I know this has got a bit stale so just wanted to clear up on this.

I managed to duplicate the exe to multiple locations on the one PC (without labview), and they can all run simultaneously. The only issue I wanted to address is how to rename the exe once installed, so that the duplicates did not all have the same reference/title, without having to build multiple copies. The application is to control cryogenic baths in our lab. Many baths are controlled by the one PC and I wanted multiple instances of the exe to control the baths independently - I know it would be possible to have a integrated package to contorl multiple baths within the same exe, but that would involve more work and time than I have to spend on it. I wanted there to be references so that users know what bath was controlled by what exe. There are many solutions to this problem and I have implemented a couple, but I will also try and hopefully make use of the ideas posted here.

Thanks for your help,

Grant.