LabVIEW Adapter Configuration Dialog Box
- Updated2024-10-09
- 10 minute(s) read
LabVIEW Adapter Configuration Dialog Box
Selecting a LabVIEW Server
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.
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.
- When using IO Configuration step types with LabVIEW to control NI Modular Instruments, if the LabVIEW Adapter is configured to use the LabVIEW Runtime and the Auto detect using VI version option is selected in the Version control, the LabVIEW Adapter will use a pre-defined LabVIEW version to execute the IO Configuration step types. This might lead to errors when using the IO session handle in other VIs. To resolve the issue open <TestStand>\Components\Language\English\IOConfigurationStrings.ini and modify the value of DEFAULT_LV_RTE_VERSION_FOR_IPXI_VI to match the LabVIEW version of the VIs that you are currently using in your sequence file.
- If you see a version mismatch error on executing source-only VIs when this option is enabled, then refer to Executing source-only VIs in LabVIEW Runtime Engine
- 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.
Note
- 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.
-
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.
-
Enable Build Source Files and Execute
—Enable this option to use the
Build Source Files and Execute
feature.
Note
- Enabling the Enable Build Source Files and Execute option will enable the Enable Version Independent Runtime Engine option.
- Changes made to this option do not take effect until you restart the TestStand application.
-
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 LabVIEW runtime server is set to
Auto detect using VI version
by default.
Note
- 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.
-
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.
Note
- 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) 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.
Configuring Other Options
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.
-
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.
Note Using this option requires that user configures override module settings for each 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.
Configuring LabVIEW Project Settings
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.
Note
- 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.
See Also
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
Drivers and Components dialog box
Organizing LabVIEW-Based TestStand Systems
Symmetric Multiprocessing in VIs Executed from TestStand