How TestStand Interacts with LabVIEW Application Instances

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
• Pipes
• ActiveX/COM
• 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.

In this section, we explore how LabVIEW application instances can effect the various forms of TestStand and LabVIEW interaction. 

Calling LabVIEW code modules

When using TestStand to interact with LabVIEW, it is important to consider the application instance that the VI code modules will execute in. The amount of control provided in TestStand varies based on the TestStand version being used and the current LabVIEW execution system (specified in the LabVIEW adapter settings).  The differences are summarized in the table below.

*The TestStand process refers to the process of the executable using the TestStand engine, which is typically the sequence editor or TestStand user interface.

When running sequences using the sequence editor, the application instance used to execute VIs typically does not have any effect on functionality.  However, issues can arise when using calling LabVIEW code modules in conjunction with using a LabVIEW built TestStand user interface, as described in the next section.

Using LabVIEW built TestStand user interfaces

A LabVIEW built TestStand user interface behaves like any other LabVIEW application in regards to application instance behavior. The table below summarizes the behavior.

Using a LabVIEW User Interface to call sequences with LabVIEW code modules

When using the LabVIEW user interface to execute sequences which call LabVIEW code modules, many variables are involved in determining the application instance behavior:

• project setting in the module tab for LabVIEW steps (TestStand 2010 and later only)
• LabVIEW execution system set in the LabVIEW adapter settings (Development system, runtime engine, or other executable)
• Application type of the user interface (executing as a VI or as a standalone executable)
• LabVIEW Version of User interface and code module VIs (whether multiple versions of LabVIEW are being used)

It is very important to understand what application instances are used in each case, because behavior changes can occur when changing these settings, such as:

• The scope of global and functional global variables can change
• The scope of hardware references can change
• Naming conflicts can become an issue (two VIs of the same name cannot be loaded in the same application instance simultaniously)

These settings are typically changed when preparing a TestStand system for deployment, especially the User Interface application type and the VI execution system settings.  The table below explores what behavior you will encounter when changing these settings, assuming all VIs are built using the same LabVIEW version.  The next section describes methods to address the issues that can arise due to these changes.

In the case that code module VIs are not built in the same LabVIEW version as the user interface, these code module VIs will execute in a new main application instance, contained within the corresponding LabVIEW run-time engine version module.
Refer to the Using multiple LabVIEW Run-time engines in a single process section above for more information.

Note: this behavior does not occur when using the development system execution system for a code module, since all code module VIs are recompiled into the current LabVIEW version before execution.

This section addresses issues that can occur due to problems with the way Application Instances are used in a TestStand application.  In many cases, these issues occur when deploying a TestStand system, since many of the settings affecting the application instance behavior are modified at this time.

Global or functional global variables no longer working as expected

If changes to your system cause VIs to no longer execute in the same application instance, sharing data between the VIs using global or functional global variables will no longer work, since each VI is accessing a separate instance of the variable.  This can occur for a few reasons, including:

• Your User Interface and code module VIs use a global variable to share data, and you migrate your code modules to a project.
• Your Code modules use a functional global to share data, and you use multiple projects to contain these VIs
• Your User Interface and code module VIs use a global variable to share data, and you test your code using a LabVIEW built User interface in executable form

In the case that you are sharing data between the user interface and code modules using globals, you should consider using TestStand User Interface messages, or UI Messages.  This method allows you to communicate between the TestStand sequence and user interface without the need for any shared dependencies such as global variables, in addition to other benefits.  for more information on effectively using UI Messages, refer to this article:

Using TestStand User Interface Messages (UI Messages)

In the case that you are sharing data between code modules, you should typically configure the modules to use the same project in the module settings for the step.  This will ensure that these code modules are executed in the same application instance. 

Errors related to invalid hardware references

In many test applications, multiple code modules use the same reference to hardware, such as a NI-DAQ task or a VISA session to communicate with hardware. It is important to understand how LabVIEW stores these references and when they are valid to avoid invalid reference issues. 

When a hardware reference is opened in LabVIEW, the driver module creates the reference and provides a reference number (refnum) to LabVIEW.  Because the LabVIEW process has a single instance of the driver module, a hardware reference will be valid in any application instance within the LabVIEW process.  However, if you use a global or functional global to store the hardware reference, the reference value will be invalid if you attempt to share it between multiple application instances.  For this reason, you consider storing hardware references into a TestStand property, which you can pass in as a parameter to any VIs which access the hardware.

Issues can arise in scenarios such as:

• Your test calls two VIs which access the same hardware, and the VIs are running in two different projects.  The VIs use a global to store the reference.  In this case, you will encounter out of reference errors when you attempt to use the global outside of the application instance in which it was initialized
  
• You are calling some code module VIs in the development system execution system, and others in the run-time system execution system using the "always Run VI in LabVIEW Run-Time Engine" option in the LabVIEW advanced Settings.  In this case, VIs are executing in two processes (the LabVIEW process and the TestStand process), so the hardware reference will be valid only in the process in which it was created.

Errors related to Naming conflicts

If changes to your system cause VIs to execute in the same application instance, but previously executed in separate application instances, you may encounter naming conflicts.  This can occur because two VIs of the same name can be loaded simultaneously if they are in different application instances, but only one instance can be open within a single application instance.  This issue can occur in scenarios such as:

• your user interface VIs and code module VIs both call a shared dependency, or both have dependencies of the same name.  If your settings change such that the User interface VI and code module VIs are executing in the same application instance, your code module steps will error, indicating that the VI is not executable.  This behavior occurs because the code module dependency has already been loaded by the user interface, and the code module VI therefore cannot load it.
  
  Note: this issue will only occur when using the LabVIEW runtime engine execution system.  the development environment can re-link the code module to the loaded version of the dependency.  For this reason, this issue typically does not occur until system deployment.
  
• you have two code modules which have different dependencies of the same name (for example, module1.vi calls sub.vi, and another code module ,module2.vi, calls /subfolder/sub.vi). If your settings change such that the two code module VIs are executing in the same application instance, both module VIs will use the same loaded dependency, or will give a VI not executable error if using the run-time engine execution system

To address these issues, consider using unique names for all VIs to avoid naming conflicts.  Also, you should avoid having multiple copies of your VIs on disk to prevent cross linking.