Multiple Instances of LabVIEW - Revision history

Logmanoriginal: Fix category assignment

2020-04-10T10:02:22Z

Fix category assignment

← Older revision		Revision as of 10:02, 10 April 2020
Line 67:		Line 67:
	* [[Custom LabVIEW configuration file]]		* [[Custom LabVIEW configuration file]]

	[[~~category~~:~~development environment~~]]		[[Category:Development Environment]]

MichaelAivaliotis: Minor formatting edit to test the TinyMCE editor

2018-11-06T08:43:51Z

Minor formatting edit to test the TinyMCE editor

← Older revision		Revision as of 08:43, 6 November 2018
Line 6:		Line 6:
	In a custom executable ini file this would be:		In a custom executable ini file this would be:

	[MyApp]<br />		[MyApp]<br />allowmultipleinstances = TRUE
	allowmultipleinstances = TRUE

	Keep in mind, multiple instances of an application may require some special considerations, like deciding if you need them to read/write to different data files and talking to different hardware.		Keep in mind, multiple instances of an application may require some special considerations, like deciding if you need them to read/write to different data files and talking to different hardware.

	==Synchronization issues==		==Synchronization issues==
	When communicating between VI's that are running in the LabVIEW development environment, they both belong to the same process. When you build the VIs into executables, each executable becomes its own process. So for example, any Queue or Semaphore references created inside one executable is meaningless inside the other executable. In the case that you only build one VI into an executable and run the other VI in the LabVIEW development environment, the same holds true, you are still dealing with two separate processes.		When communicating between VI's that are running in the LabVIEW development environment, they both belong to the same process. When you build the VIs into executables, each executable becomes its own process. So for example, any Queue or Semaphore references created inside one executable is meaningless inside the other executable. In the case that you only build one VI into an executable and run the other VI in the LabVIEW development environment, the same holds true, you are still dealing with two separate processes.
			==Other Methods==
	== Other Methods ==

	'''Windows:'''		'''Windows:'''

Line 47:		Line 43:
	'''Linux:'''		'''Linux:'''

	In Linux you get a new instance of the LabVIEW development environment each time you run the LabVIEW executable ~~</usr/local/lv70/labview>~~, unless you pass the "-launch" command line argument. For example:		In Linux you get a new instance of the LabVIEW development environment each time you run the LabVIEW executable , unless you pass the "-launch" command line argument. For example:

	$ /usr/local/lv70/labview -launch		$ /usr/local/lv70/labview -launch
Line 54:		Line 50:

	One problem when running instances from mapped directories is that the same labview.ini file is used for all instances so that can cause conflicts. It is better to specify a different ini file using the -pref command line switch. The method is best implemented when launching LabVIEW with a batch file, with commands that maps the directory/drive, launch LabVIEW with ini file and eventually unmap directory after LabVIEW exits.		One problem when running instances from mapped directories is that the same labview.ini file is used for all instances so that can cause conflicts. It is better to specify a different ini file using the -pref command line switch. The method is best implemented when launching LabVIEW with a batch file, with commands that maps the directory/drive, launch LabVIEW with ini file and eventually unmap directory after LabVIEW exits.
			==Also==
	== Also ==

	Under Windows (and I assume other OSes as well) you can map a new network folder with a target of LabVIEW.exe in that attached to an icon on your desktop. I use this all the time to run two or three instances of LabVIEW for debugging and also to compare versions of a code tree without danger of mixing the paths to VIs.		Under Windows (and I assume other OSes as well) you can map a new network folder with a target of LabVIEW.exe in that attached to an icon on your desktop. I use this all the time to run two or three instances of LabVIEW for debugging and also to compare versions of a code tree without danger of mixing the paths to VIs.

	Example:		Example:
	1. Open Windows Explorer.		# Open Windows Explorer.
	2. Menu: Tools >> Map Network drive...		# Menu: Tools >> Map Network drive...
	3. In Map Network Drive Dialog: Select a new drive letter (something hight like j:		# In Map Network Drive Dialog: Select a new drive letter (something hight like j:
	4. Browse Button -> to your .\LabVIEW\ folder		# Browse Button -> to your .\LabVIEW\ folder
	5. Check Reconnect at Login		# Check Reconnect at Login
	6. Press Finish		# Press Finish
	7. Go to the new J: folder in Windows Explorer, right click on LabVIEW.exe and create a shortcut for your desktop. Label it "LabVIEW x.x Instance N"		# Go to the new J: folder in Windows Explorer, right click on LabVIEW.exe and create a shortcut for your desktop. Label it "LabVIEW x.x Instance N"

	Now each time you start up your machine you have multiple instances available. You can even copy-Paste code snippets in between, by saving a Copy-Paste VI.vi in your temp directory and copy to it, save (in Instance 1), then close and open in Instance 2. Otherwise the memory spaces are completely separate.		Now each time you start up your machine you have multiple instances available. You can even copy-Paste code snippets in between, by saving a Copy-Paste VI.vi in your temp directory and copy to it, save (in Instance 1), then close and open in Instance 2. Otherwise the memory spaces are completely separate.
			==See also==

	~~==See also==~~		* [[LabVIEW configuration file]]
	*[[LabVIEW configuration file]]		* [[Custom LabVIEW configuration file]]
	*[[Custom LabVIEW configuration file]]

	[[category:development environment]]		[[category:development environment]]

Michael_Aivaliotis at 09:30, 8 October 2007

2007-10-08T09:30:50Z

← Older revision		Revision as of 09:30, 8 October 2007
Line 1:		Line 1:
			{{TOCnestright}}
	The preferred approach is to add the following ini key into the labview.ini file:		The preferred approach is to add the following ini key into the labview.ini file:

Line 72:		Line 73:
	*[[LabVIEW configuration file]]		*[[LabVIEW configuration file]]
	*[[Custom LabVIEW configuration file]]		*[[Custom LabVIEW configuration file]]

			[[category:development environment]]

MichaelAivaliotis: /* See also */

2007-09-20T16:29:54Z

MichaelAivaliotis: added "see also" section

2007-09-20T16:29:34Z

added "see also" section

← Older revision		Revision as of 16:29, 20 September 2007
Line 68:		Line 68:

	Now each time you start up your machine you have multiple instances available. You can even copy-Paste code snippets in between, by saving a Copy-Paste VI.vi in your temp directory and copy to it, save (in Instance 1), then close and open in Instance 2. Otherwise the memory spaces are completely separate.		Now each time you start up your machine you have multiple instances available. You can even copy-Paste code snippets in between, by saving a Copy-Paste VI.vi in your temp directory and copy to it, save (in Instance 1), then close and open in Instance 2. Otherwise the memory spaces are completely separate.

			==See also==
			[[LabVIEW configuration file]]
			[[Custom LabVIEW configuration file]]

MichaelAivaliotis: /* Also */

2007-09-20T16:26:24Z

Also

← Older revision		Revision as of 16:26, 20 September 2007
Line 68:		Line 68:

	Now each time you start up your machine you have multiple instances available. You can even copy-Paste code snippets in between, by saving a Copy-Paste VI.vi in your temp directory and copy to it, save (in Instance 1), then close and open in Instance 2. Otherwise the memory spaces are completely separate.		Now each time you start up your machine you have multiple instances available. You can even copy-Paste code snippets in between, by saving a Copy-Paste VI.vi in your temp directory and copy to it, save (in Instance 1), then close and open in Instance 2. Otherwise the memory spaces are completely separate.

	~~WISHLIST: that we had a special direct clipboard, just in LabVIEW for copy-paste in memory.~~

MichaelAivaliotis: Added sync issues

2007-09-20T16:25:11Z

Added sync issues

← Older revision		Revision as of 16:25, 20 September 2007
Line 1:		Line 1:
	~~==Running multiple instances of LabVIEW==~~		The preferred approach is to add the following ini key into the labview.ini file:

	~~Add the following ini key into the labview.ini file or in an executable file ini:~~		'''allowmultipleinstances=True'''

	~~'''~~allowmultipleinstances=~~True''~~'		In a custom executable ini file this would be:

			[MyApp]<br />
			allowmultipleinstances = TRUE

			Keep in mind, multiple instances of an application may require some special considerations, like deciding if you need them to read/write to different data files and talking to different hardware.

			==Synchronization issues==
			When communicating between VI's that are running in the LabVIEW development environment, they both belong to the same process. When you build the VIs into executables, each executable becomes its own process. So for example, any Queue or Semaphore references created inside one executable is meaningless inside the other executable. In the case that you only build one VI into an executable and run the other VI in the LabVIEW development environment, the same holds true, you are still dealing with two separate processes.

	=== Other Methods ===		== Other Methods ==

	'''Windows:'''		'''Windows:'''

MichaelAivaliotis at 07:12, 17 March 2007

2007-03-17T07:12:32Z

← Older revision		Revision as of 07:12, 17 March 2007
Line 1:		Line 1:
	==Running multiple instances of LabVIEW==		==Running multiple instances of LabVIEW==

			Add the following ini key into the labview.ini file or in an executable file ini:

			'''allowmultipleinstances=True'''

			=== Other Methods ===

	'''Windows:'''		'''Windows:'''
Line 29:		Line 35:

	Type SUBST with no parameters to display a list of current virtual drives.[/quote]		Type SUBST with no parameters to display a list of current virtual drives.[/quote]


	'''Linux:'''		'''Linux:'''
Line 41:		Line 46:
	One problem when running instances from mapped directories is that the same labview.ini file is used for all instances so that can cause conflicts. It is better to specify a different ini file using the -pref command line switch. The method is best implemented when launching LabVIEW with a batch file, with commands that maps the directory/drive, launch LabVIEW with ini file and eventually unmap directory after LabVIEW exits.		One problem when running instances from mapped directories is that the same labview.ini file is used for all instances so that can cause conflicts. It is better to specify a different ini file using the -pref command line switch. The method is best implemented when launching LabVIEW with a batch file, with commands that maps the directory/drive, launch LabVIEW with ini file and eventually unmap directory after LabVIEW exits.

			== Also ==
	== ~~Other Methods:~~ ==

	Under Windows (and I assume other OSes as well) you can map a new network folder with a target of LabVIEW.exe in that attached to an icon on your desktop. I use this all the time to run two or three instances of LabVIEW for debugging and also to compare versions of a code tree without danger of mixing the paths to VIs.		Under Windows (and I assume other OSes as well) you can map a new network folder with a target of LabVIEW.exe in that attached to an icon on your desktop. I use this all the time to run two or three instances of LabVIEW for debugging and also to compare versions of a code tree without danger of mixing the paths to VIs.
Line 58:		Line 62:

	WISHLIST: that we had a special direct clipboard, just in LabVIEW for copy-paste in memory.		WISHLIST: that we had a special direct clipboard, just in LabVIEW for copy-paste in memory.

	~~== Easiest Way ==~~

	~~allowmultipleinstances=True~~

	~~Throw it in any EXE's ini~~
	~~INCLUDING Labview.ini~~

MichaelAivaliotis: New page: ==Running multiple instances of LabVIEW== '''Windows:''' You have to do this little trick. Create a new drive letter that maps the LabVIEW installation directory as a drive letter. From ...

2007-03-17T06:49:38Z

New page: ==Running multiple instances of LabVIEW== '''Windows:''' You have to do this little trick. Create a new drive letter that maps the LabVIEW installation directory as a drive letter. From ...

New page

==Running multiple instances of LabVIEW==

'''Windows:'''

You have to do this little trick. Create a new drive letter that maps the LabVIEW installation directory as a drive letter. From a command prompt, use the SUBST command to create a new drive letter ("L" in this case):

C:\> SUBST L: "C:\Program Files\National Instruments\LabVIEW 7.0"

You can now launch your new "instance" of the LabVIEW Development Environment by running the command:

C:\> L:\LabVIEW.exe

Or, you can launch the new instance of LabVIEW by double clicking on the LabVIEW.exe application icon inside the F:\ drive in Windows File Explorer.

When you are finished using your new instance of the development environment, delete the new drive mapping by entering the SUBST command with the /D switch:

C:\> SUBST L: /D

Note that you can run as many instances of LabVIEW as you can create drive letters.

[quote=Help printout for the SUBST command]Associates a path with a drive letter.

SUBST [drive1: [drive2:]path]
SUBST drive1: /D

drive1: Specifies a virtual drive to which you want to assign a path.
[drive2:]path Specifies a physical drive and path you want to assign a virtual drive.
/D Deletes a substituted (virtual) drive.

Type SUBST with no parameters to display a list of current virtual drives.[/quote]

'''Linux:'''

In Linux you get a new instance of the LabVIEW development environment each time you run the LabVIEW executable </usr/local/lv70/labview>, unless you pass the "-launch" command line argument. For example:

$ /usr/local/lv70/labview -launch

[quote=Help for the -launch command-line argument on UNIX/Linux plaforms]LabVIEW launches and checks for an existing instance of LabVIEW already running on the same display. If an existing instance is running, the existing instance opens the VIs passed in the command line, and the new instance of LabVIEW quits silently. If an existing instance is not running, LabVIEW opens the VIs passed in the command line in the new instance.[/quote]

One problem when running instances from mapped directories is that the same labview.ini file is used for all instances so that can cause conflicts. It is better to specify a different ini file using the -pref command line switch. The method is best implemented when launching LabVIEW with a batch file, with commands that maps the directory/drive, launch LabVIEW with ini file and eventually unmap directory after LabVIEW exits.

== Other Methods: ==

Under Windows (and I assume other OSes as well) you can map a new network folder with a target of LabVIEW.exe in that attached to an icon on your desktop. I use this all the time to run two or three instances of LabVIEW for debugging and also to compare versions of a code tree without danger of mixing the paths to VIs.

Example:
1. Open Windows Explorer.
2. Menu: Tools >> Map Network drive...
3. In Map Network Drive Dialog: Select a new drive letter (something hight like j:
4. Browse Button -> to your .\LabVIEW\ folder
5. Check Reconnect at Login
6. Press Finish
7. Go to the new J: folder in Windows Explorer, right click on LabVIEW.exe and create a shortcut for your desktop. Label it "LabVIEW x.x Instance N"

Now each time you start up your machine you have multiple instances available. You can even copy-Paste code snippets in between, by saving a Copy-Paste VI.vi in your temp directory and copy to it, save (in Instance 1), then close and open in Instance 2. Otherwise the memory spaces are completely separate.

WISHLIST: that we had a special direct clipboard, just in LabVIEW for copy-paste in memory.

== Easiest Way ==

allowmultipleinstances=True

Throw it in any EXE's ini
INCLUDING Labview.ini

← Older revision		Revision as of 16:29, 20 September 2007
Line 70:		Line 70:

	==See also==		==See also==
	[[LabVIEW configuration file]]		*[[LabVIEW configuration file]]
	[[Custom LabVIEW configuration file]]		*[[Custom LabVIEW configuration file]]