This section provides an overview of the behavior of application instances in LabVIEW. It is important to understand this behavior before investigating how it effects a TestStand system.
Introduction to LabVIEW application instances
Within the LabVIEW process, you can create independent instances of the environment, known as application instances. LabVIEW creates an application instance for each target within the project. By default, a LabVIEW project contains a single "My Computer" target. LabVIEW also creates a Main application instance, which contains VIs not in a LabVIEW Project.
When working in LabVIEW, you can use the application instance name that appears in the application instance shortcut menu on the bottom left corner of the front panel and block diagram windows to identify which application instance a VI belongs to. In addition, this control allows you to change the application instance of the VI to any other available instance. Note that this does not cause the VI to be removed from the LabVIEW project, it only changes the instance in which the VI is loaded in memory.
You can open the same VI on disk in multiple application instances at the same time. Each application instance behaves as a separate instance of LabVIEW. For example, you can open the same VI on disk in two different projects.
Each VI instance can be used independently, and maintains independent copies of the following items:
- Front panel data
- VI and other dependencies, including shared libraries
- Global variable values (each application instance has a separate instance of any global variables)
- Functional global variable values (uninitialized shift register values are independent between application instances)
This means that Global and functional variables cannot be used to share data between VIs in different application instances. VIs can only communicate across application instances using methods such as:
- Network-published Shared Variables
- TCP/IP Communication
- Reading/Writing to a file
Application instances in deployed applications
When you create an executable from LabVIEW, the executable runs within it's own process in the operating system. As with the Development Environment, LabVIEW executables can contain multiple application instances. In most cases, all VIs in an executable use the main application instance, but any shared libraries (for example LabVIEW built DLLs or .NET Interop assemblies) will execute in their own application instance. Additional application instances can be created for other reasons as well. Some of these cases are explored later in the document.
The diagram below illustrates the hierarchy of Operating system » LabVIEW process » Application Instance
Using multiple LabVIEW Run-time engines in a single process
In some cases, it is necessary to run VIs that are built with two different LabVIEW versions in the same process. For example, a TestStand sequence can call both LabVIEW 2009 and LabVIEW 2012 VIs. In order to execute VIs in different LabVIEW versions, a LabVIEW Run-Time Engine module for each LabVIEW version must be loaded into the current process. Each of these LabVIEW Run-Time Engine modules, like the LabVIEW development system, contain a Main application instance, and can contain additional application instances for shared libraries.
Note: In the previous sections, the module layer was not discussed to avoid unnecessary complexity. A process using LabVIEW typically only contains a single LabVIEW module, so it does not have an effect on functionality unless a single process is using multiple LabVIEW versions.
In the case that VIs in both Main Application instances call into a shared dependency, such as a shared library, a new application instance is created for each Main application instance. The diagram below illustrates this organization within the LabVIEW process.