TestStand 2019 Help
»View Product Info
Select Configure»Adapters, select the LabVIEW Adapter in the list control, and click Configure to launch the LabVIEW Adapter Configuration dialog box, which contains Select or Type Which LabVIEW Server to Use, Options, and LabVIEW Project Settings sections.
||Note If no LabVIEW Runtime versions are installed, the LabVIEW Adapter Configuration dialog box is disabled.
The Select or Type Which LabVIEW Server to Use section contains the following options for specifying the server or engine the LabVIEW Adapter uses:
- LabVIEW Runtime—The version of the LabVIEW Runtime to use for loading and executing VI code modules. Selecting this option runs VIs in the same process as TestStand to provide optimal performance when calling VIs. When you select this option, you cannot create or edit VIs from TestStand.
This control lists only the supported versions of the LabVIEW Runtime. When you only have an older version of LabVIEW installed, this control is disabled.
- Version—Select the LabVIEW Runtime version that matches the version of the VIs that TestStand executes.
Select the Auto detect using VI version option in the Version control to let TestStand automatically detect the version of the LabVIEW Runtime to use when executing a LabVIEW code module VI. Use this option when you have VIs saved in different versions of LabVIEW and you want them to always run in the LabVIEW Runtime without mass compiling to a specific LabVIEW version. You can also use this option when you create a deployment to ensure that TestStand uses the correct LabVIEW Runtime version to execute VIs you deploy.
When you select this option, TestStand searches for the most recent LabVIEW Runtime version you have installed. If you configure a LabVIEW step to use a VI compiled with a version of LabVIEW earlier than the most recent Runtime version you have installed, the LabVIEW Module tab displays an error that states that TestStand cannot load the VI using the most recent Runtime version because the VI version is earlier than the current Runtime version.
||Note TestStand can use newer versions of the LabVIEW Runtime when you install LabVIEW on your development system. You can include newer versions of the LabVIEW Runtime in deployments using the Drivers and Components dialog box of the TestStand Deployment Utility. If you do not have a LabVIEW development system installed on the computer, the default value of the LabVIEW Runtime option is Auto detect using VI version, and you do not need to deploy the Adapters.cfg file that specifies the LabVIEW Runtime version to use.
- Execute 'Same as caller' VIs Using Multiple Threads—Specifies whether TestStand configures the LabVIEW Runtime to use multiple execution threads to execute VIs with the preferred execution system set to same as caller.
- Number of Threads—The number of LabVIEW execution threads TestStand configures the LabVIEW Runtime to use to execute VIs with the preferred execution system set to same as caller.
- Additional Threads Inherit Calling Thread's CPU Affinity—Specifies whether TestStand sets the CPU affinity of additional LabVIEW execution threads to the CPU affinity of the TestStand execution thread.
- The Execute 'Same as caller' VIs Using Multiple Threads, Number of Threads, and Additional Threads Inherit Calling Thread's CPU Affinity options apply only when TestStand executes VIs using the LabVIEW Runtime and apply only to VIs with the preferred execution system set to same as caller. If you modify any of these options, the changes do not take effect until the next time you start the TestStand application.
- The LabVIEW Runtime option performs the same behavior as the Always Run VI in LabVIEW Runtime option in the LabVIEW Advanced Settings window in the TestStand Sequence Editor or on the Advanced Settings tab of the Edit LabVIEW VI Call dialog box in a TestStand User Interface. However, the Auto detect using VI version option applies to all LabVIEW steps in a sequence.
- Enable Debugging and Tracing —Configures the LabVIEW Runtimes loaded by TestStand to accept remote connections from LabVIEW Development Systems and LabVIEW Desktop Execution Trace Toolkit (DETT) to support debugging and tracing of VIs executed using the TestStand Sequence Editor. You can use the LabVIEW Development System to debug VIs and the DETT to capture execution events for VIs executing on the local machine. Refer to the Debugging and Tracing of VIs Executed Using the LabVIEW Runtime topic for more information about using the Enable Debugging and Tracing option.
- The Enable Debugging and Tracing option applies to VIs executed using the LabVIEW 2015 Runtime or later.
- Debugging VIs is only supported in the TestStand Sequence Editor.
- Tracing VIs is supported in both the TestStand Sequence Editor and a TestStand User Interface.
- Development System (Active Version)—To use LabVIEW to create or edit VIs or to debug VIs TestStand calls, you must select this option so VIs execute in the active version of the LabVIEW development environment. You must have the LabVIEW development system installed on the same computer as TestStand to use this option. If the text Not Allowed appears next to a LabVIEW version, TestStand no longer allows connecting to that version of LabVIEW. Select one of the following options to indicate which LabVIEW version to launch:
- Use Active LabVIEW Version—Launches the current active 32-bit LabVIEW or 64-bit LabVIEW development environment, with a preference to match the bitness of TestStand. This is the default option.
- Use Active 32-bit Version—Launches the current active 32-bit LabVIEW development environment.
- Use Active 64-bit Version—Launches the current active 64-bit LabVIEW development environment.
||Note Although the LabVIEW adapter configuration dialog will display the most recently opened version of LabVIEW Development System as the active version of LabVIEW, if multiple versions of LabVIEW are open at the same time on the system, the first version of LabVIEW launched will be used by the LabVIEW adapter and related tools to create or edit or debug VIs. This behavior is the consequence of how Out-of-Process ActiveX Servers are designed and implemented.
||Note TestStand supports invoking cross-bitness code modules by executing the VIs only in the LabVIEW development environment and does not support using the LabVIEW Runtime. In addition, the TestStand Deployment Utility only supports packaging VIs for LabVIEW code modules of the same bitness as the deployment utility. |
- Other Executable—Uses a LabVIEW executable you build with the Build Executable functionality in LabVIEW. When you select this option, you cannot create or edit VIs from TestStand or debug VIs TestStand calls. The version of the VIs that TestStand executes must match the version of the LabVIEW Runtime or the version of LabVIEW that built the executable.
To use this option, enter the ActiveX Automation server name associated with the LabVIEW executable. You must install and register the executable on the same computer as TestStand. Launch the executable once to register it as an ActiveX Automation server. The <TestStand Public>\Components\RuntimeServers\LabVIEW directory contains an example server VI and application build script for LabVIEW.
||Note (Windows 10/8.1/7) Microsoft Windows requires you to log in as a user with administrator privileges to register a server. LabVIEW cannot register ActiveX Automation servers on Windows Vista when building executables without elevation.
The Options section contains the following options:
- Reserve Loaded VIs for Execution—Specifies whether LabVIEW reserves each VI to run when TestStand loads the VI. When a VI is reserved for execution, any references the VI creates during execution remain valid until the VI is unreserved. VIs LabVIEW reserves take less time to call. However, you cannot edit the VIs in LabVIEW unless you click Edit VI on the LabVIEW Module tab or Specify Module dialog box or select Edit Code from the context menu for the calling step.
TestStand unreserves a VI under the following circumstances:
- When you select File»Unload All Modules.
- When the VI is unloaded based on sequence file or step unload options.
- When you open a VI for editing from within TestStand.
The Reserve Loaded VIs for Execution option eliminates the need to use permanent reference VIs for sharing LabVIEW references between step modules.
You can create a reference in a VI one step in a sequence calls, use the reference in a VI a second step calls, and close the reference in a third step. For example, you can create a file refnum from Open File, use the reference in Read File or Write File, and close the reference using Close File when you no longer need the reference.
A LabVIEW reference exists only as long as the VI that creates it is reserved. When you set the Unload Option for a step that calls a VI to Unload After a Step Executes or Unload When Precondition Fails, the LabVIEW references the step creates might be destroyed on completion of the step. If you do not reserve VIs for execution, you can use the permanent reference VIs to maintain LabVIEW references between steps. Refer to the Accessing Arrays Using API from LabVIEW Code Modules example program for more information.
- Enable Version Independent Runtime Engine—Specifies whether Version Independent Runtime Engine support is enabled in the LabVIEW Adapter. This option applies to all instances of LabVIEW runtimes, version 2017 or later, that are used by the TestStand application.
When you enable this option, the Auto detect using VI version option is set to the LabVIEW runtime server by default.
- You can enable the Enable Version Independent Runtime Engine option only if your machine has LabVIEW runtime version 2017 or later installed.
- Changes made to this option do not take effect until you restart the TestStand application.
- Always run VI in Packed Project Library—Overrides the VI configured in the code module with the VI in the packed project library. You can select the packed project library in the Override Module Settings window for the step.
- Automatically Build Packed Project Libraries at the Start of Execution—Builds the packed project library at the start of execution if the packed project library is missing or out-of-date.
- Code Template Policy—Specify the templates to use during code creation. The following options are available:
- Allow Only New Templates—Only searches for new code templates.
When you select this option and create a new VI using the LabVIEW Module tab, TestStand creates a new VI based on the code template for the specified step type. When the step type has multiple code templates available, TestStand launches the Choose Code Template dialog box, in which you can select the code template to use for the new VI.
- Allow Only Legacy Templates—Only searches for legacy code templates.
When you select this option and create a new VI using the LabVIEW Module tab, TestStand launches the Optional Parameters dialog box, in which you select the optional parameters, such as Input Buffer, Invocation Info, or Sequence Context ActiveX Pointer, you want to include as input parameters for the VI.
- Allow New and Legacy Templates—Searches for both new and legacy templates.
When you select this option and create a new VI using the LabVIEW Module tab, TestStand launches the Choose Code Template dialog box, in which you can select the code template to use for the new VI.
- Legacy VI Settings—Launches the Legacy VI Settings dialog box, in which you can configure settings relevant to calling legacy test VIs. The Legacy VI Settings dialog box contains expressions the LabVIEW Adapter evaluates to generate values to pass to the VI in the various Invocation Info cluster fields. Legacy VIs can use the Invocation Info cluster as an optional input.
The LabVIEW Project Settings section contains the following options:
- Auto Deploy Shared Variables on First Load of any VI in a Project—When you enable this option, TestStand deploys to the local computer shared variables defined in LabVIEW libraries within the LabVIEW projects you use in TestStand. The deployment of shared variables occurs the first time TestStand loads a LabVIEW step that references the project during execution. Ensure that the LabVIEW library to deploy contains only shared variables.
- Enabling this option does not deploy shared variables defined in LabVIEW packed project libraries specified in LabVIEW projects you use in TestStand. Use the Deploy Library step type to deploy or undeploy to the local computer the shared variables defined in a LabVIEW packed project library file.
- TestStand can deploy a shared variable bound to another shared variable only when you use an NI Publish-Subscribe Protocol (NI-PSP) URL to bind the shared variable to deploy to another shared variable. If you attempt to use a Deploy Library step to deploy a shared variable to a variable in a LabVIEW project, the deployment fails. Refer to the LabVIEW Help for more information about deploying shared variables and NI-PSP URLs.
- Auto Undeploy Shared Variables on Last Unload of all VIs in a Project—When you enable this option, TestStand undeploys the shared variables defined in LabVIEW libraries within the LabVIEW project after TestStand unloads the last LabVIEW step that references the LabVIEW project. TestStand automatically enables this option when you enable the Auto Deploy Shared Variables on First Load of any VI in a Project option.
||Note If you do not want TestStand to automatically deploy shared variables, leave the Auto Deploy Shared Variables on First Load of any VI in a Project option disabled.
Caveats for Configuring the LabVIEW Adapter to Use a LabVIEW Runtime or Other Executable Server
Choose Code Template dialog box
Deploying Network-Published Shared Variables
Deploying TestStand Systems
Drivers and Components dialog box
LabVIEW Module tab
Legacy VI Settings dialog box
Organizing LabVIEW-Based TestStand Systems
Specify Module dialog box
Symmetric Multiprocessing in VIs Executed from TestStand
TestStand Deployment Utility
Version Independent Runtime Engine Support