Multiple test systems can exist on the same test station computer. For example, you might want a legacy version and the current version of a test system on the same test station computer. When you install deployments for different versions of TestStand on the same computer, use the TestStand Version Selector to select the active version of TestStand before you launch the deployed TestStand application. NI does not support running applications that use two different versions of TestStand at the same time.

To effectively use multiple test systems on the same test station computer, you must design the test systems to avoid potential conflicts when the test systems or . If you are creating MSI-based installers, use the Save As option in the TestStand Deployment Utility and select the option to create a new installer to create a new TSD file with a different installer GUID so both installers can install side by side. You can also create installers that install side by side.

If you are creating package distributions, ensure that the product and/or company name fields are different for each distribution, since these fields are used to generate the package name which must be unique for each package you create.

The following changes you make to one test system affect all test systems installed on a test station computer:

Note You must apply bug fixes and updates for common files to all test system locations if each test system uses a separate copy of the common files.
  • Changing TestStand configuration settings stored in GeneralEngine.cfg, Adapters.cfg, TypePallete.cfg, and SearchDirectories.cfg affects all test systems on the test station computer. For example, if one test system adds a directory to the search paths, another test system on the test station computer can also find a file in that directory. You can use LabVIEW projects, unique filenames in each test system, or different configuration directories for each test system on the test station computer to work around this behavior. If you want to use a separate configuration file for multiple deployments on a single test station, you can deploy the files using an engine environment file to specify a custom location for the configuration files for each deployment. See the Deploying with Environments topic for more information.
  • Updating NI drivers affects all test systems on the test station computer.

Supporting Multiple Versions of TestStand

When you use the deployment utility to build an installer, the deployment utility can include multiple versions of the TestStand Runtime. The Include TestStand Runtime option includes only the version of the TestStand Runtime that matches the version of the deployment utility. Use the Drivers and Components dialog box to include additional TestStand Runtimes. Multiple versions of the TestStand Runtime can exist on the test station computer, but the test system uses the most recently registered version of TestStand. You can use the TestStand Version Selector to change the currently active version of TestStand.

Test Systems That Do not Share Files or Execute at the Same Time

Test systems that do not share files and that do not load or execute simultaneously rarely conflict with each other when you deploy the test systems to the same test station computer.

To ensure that the test systems do not share files, install the test systems to different directory hierarchies on the test station computer and ensure that each test system uses separate copies of the code modules, including code modules used in all test systems on the test station computer. If the test systems do not share files, you can update any file in one test system without affecting another test system.

To ensure that the files do not load in memory simultaneously, unload all code modules after you execute one test system and before you load the next test system to avoid conflicts among the test systems installed on the same test station computer.

Test Systems That Share Files

Shared files must work correctly with all the test systems that use the shared files. You must test changes to shared files with all the test systems on the test station computer to ensure that the test systems execute successfully after the update.

Consider the following guidelines when you change shared files:

  • If you change the prototypes of exposed interfaces of shared files, you must update all the callers in all the test systems that use the shared files to ensure that the callers execute without errors. Exposed interfaces include VI connector panes and DLL function prototypes.
  • Do not delete files until you confirm that no test system installed on the test station computer uses the files.
  • Do not install an updated version of the file unless both test systems can use the updated version of the file.
  • Compiling a test system to use a later version of LabVIEW also updates any shared files to use the later version of LabVIEW, which can break VIs in the test systems you did not update.
  • Uninstalling an installer you built with the TestStand Deployment Utility removes shared files from other test systems installed on the test station computer unless you distributed the files as LabVIEW packed project libraries.
  • When you update existing test systems, the installer replaces a previously installed configuration file or does not modify the file. When you replace a configuration file, such as GeneralEngine.cfg, you replace all the settings stored in the file. TestStand does not merge the existing settings with the new settings in the file. Because configuration files are non-versioned files, you can use the Force File to Install option on the Distributed Files tab of the deployment utility to ensure that deployments always install configuration files, such as GeneralEngine.cfg. If you want to use a separate configuration file for multiple deployments on a single test station, you can deploy the files using an engine environment file to specify a custom location for the configuration files for each deployment. See the Deploying with Environments topic for more information.
    Notice When you enable the Force File to Install option, an installer can replace a newer version of a file with an older version of a file, which can be problematic for DLLs because components on the computer might rely on functionality available only in the newer version of the DLL and might not execute correctly when the installer downgrades the DLL.

Test Systems That Execute Simultaneously

Name collisions or type conflicts can occur if you load sequence files from multiple test systems simultaneously. Name collisions can occur among VIs or among dependent DLLs. Type conflicts can occur when TestStand loads two sequence files that include data types or step types with the same type version but different definitions.

Use the following techniques to avoid VI and DLL dependency name collisions or type conflicts:

  • Use unique filenames or unique qualified names for VIs across test systems you install on the same test station computer.
  • Call VIs in the context of LabVIEW projects that are unique to each test system to avoid name collisions and partial project library conflicts.
  • Because TestStand cannot load two DLLs that load dependencies with the same name from different paths, change the DLLs to use the same dependency with the same path or use unique names for the dependencies.
  • Download the NI TestStand Toolkit for Large Application Development from ni.com and use the type differ tool to locate type differences between sequence files of two test systems.