Data Streams Step Types

TestStand Data Streams provide a simple way to read data from or write data to CSV (comma separated value) files. Basic Data Streams functionality is provided by the Data Streams step types as well as an update to the existing For Each step type. Use these step types to quickly and easily create sequences that consume or produce CSV file data.

Data Streams step types are built on an underlying public API that you can call directly to handle more complex applications. At the core of the Data Streams feature are two COM (Component Object Model) interfaces: InputRecordStream and OutputRecordStream. Advanced users can create custom implementations of these interfaces to enable TestStand sequences to work with any producer or consumer of data that has a logical structure similar to a table.

To get started using the feature, use the example code provided with TestStand 2017 at <TestStand Public Directory>\Examples\Fundamentals\Using Data Streams.

Crash Recovery for TestStand Applications

TestStand 2017 has the option to generate a log containing execution information and use the NI Error Reporting Service, NIER, to automatically generate a crash dump file. You can use a crash dump file to diagnose the root cause of a crash. In cases where the crash is in an NI product, you can send the crash dump file to NI support engineers for diagnosis. TestStand also offers a way to register a custom sequence to execute in an external process in response to a crash.

TestStand Crash Log—When a crash occurs TestStand generates a log file in the directory <TestStand_LocalAppData>\CrashLogs. Only the last 100 crash logs are saved, after which the earliest log file will be deleted and a new log file is created.

NIER Crash Dump—Using the same error reporting service as LabVIEW, TestStand generates a NIER crash dump in <TestStand_LocalAppData>\NIERdump.

TestStand Crash Log and Dump File

You can use a configuration file to specify settings for the dump and TestStand specific log file. The configuration file is an .ini file in the same directory as the TestStand application. The name of the configuration file must be same as the executable name of the TestStand application.

In the configuration file, create a section with the same name as the name of the executable. Use the following tokens and values to specify the options:

Code modules should not register to functions like SetUnhandledExceptionFilter, set_invalid_parameter_handler, and set_purecall_handler to handle application crashes. Crash logging due to running out of memory is not supported.

Registering a Crash Recovery Sequence

You can register sequences to respond to a crash in your TestStand application to return any hardware or other system assets to a good state. The sequences are executed by an external process and run without a process model or a logged-in user. Since multiple crash recovery sequences can be registered, the order in which the sequences will be executed is the order in which they are registered.

Any errors encountered in executing crash recovery sequences are recorded in a log file, and a dialog displays the location of the log file. Similar to the main application TestStand crash log, this log file stores the errors from a maximum of 100 crash callbacks.

To register a sequence for execution in the case of a crash you must call Engine.RegisterSequenceToExecuteOnCrash with the sequence name and file path to be executed. This function returns a unique ID that can be used to unregister the sequence later with a call to Engine.UnregisterSequenceToExecuteOnCrash.

Support for Package Distribution in the TestStand Deployment Utility

TestStand Deployment Utility now supports building package distributions in addition to MSI-based installers. Use the Output Type control on the Mode tab to configure the TestStand Deployment Utility to build a package-based installer. This control has 3 settings:

• Deployable Image Only—The deployment files are moved to the specified image directory on the System Source tab.
• MSI-Based Installer—In addition to the deployable image, the deployment utility creates an installer to distribute the system. When you select this option, the Installer tab is enabled, which you can use to configure the installer.
• Package-Based Distribution—In addition to the deployable image, the deployment utility creates a package distribution. When you select this option, the Package Distribution Options tab is enabled, which you can use to configure the package distribution. You can configure the package output type using the options below:
  • Single Package—The files in the image directory are packaged into a single .nipkg file. Dependencies you select are referenced by the package, and must be installed on the deployment target to install the package.
  • Repository—In addition to the main package, all dependent packages are also included in the deployment (the repository). A feed is generated which references all included packages in the repository. To install the deployment, you can register the feed in NI Package Manager on the target machine.
  • Package Installer—In addition to the main package, all dependent packages are also included in the deployment. A standalone installer is generated which installs all the packages on a machine. The installer will also install NI Package Manager if it is not present on the machine.

Configuring the Package Settings in the TestStand Deployment Utility

Package distribution settings are configured on the Installer tab. The package name is generated from the Installation name you specify. To configure additional settings for the package, click the Advanced Options button.

To include package-based dependencies, click the Dependencies button. For each dependency you select, you can configure the dependency level:

• Required— The package cannot be installed unless the dependency is on the system or can be found by NI Package Manager through a registered feed. These packages are included in the deployment in feed or package distribution mode.
• Recommended/Optional— The package can be installed without these dependencies. They are not included in feed or package distribution mode.

The following features are currently not supported in package mode:

• Advanced File Options (creating shortcuts, program items, or registering as an ActiveX server)
• Custom Commands
• Including readme files or license agreements
• Media spanning

Support for LabVIEW NXG in the TestStand Deployment Utility

TestStand Deployment Utility supports deploying sequence files which call LabVIEW NXG code modules. LabVIEW NXG steps can be configured in the following ways:

• Project and GLL are Both Specified— These steps can execute using the LabVIEW NXG development system to execute the VI directly, or using the LabVIEW NXG Run-Time Engine to execute the VI within the GLL. In this case, TestStand enforces that the specified GLL must match the GLL output configured in the project and component in LabVIEW NXG. When deploying these types of steps, TestStand Deployment Utility automatically regenerates the GLL from the project before deploying to ensure that the latest code is used.
• GLL Specified, Project Not Specified— These steps must be executed using the LabVIEW NXG Run-Time Engine to execute the VIs built into the GLL. When deploying these types of steps, the GLL file is deployed as-is because no source files are present to rebuild it.
• Project Specified, GLL Not Specified— These steps can execute using the LabVIEW NXG Development System to execute the VI directly. Deployment is not supported for these steps by TestStand Deployment Utility. An error is generated indicating that a GLL is required.

Configuring LabVIEW NXG Files in the TestStand Deployment Utility

After analyzing a sequence with LabVIEW NXG code modules, the referenced GLLs are displayed in the distributed files tab. You can configure the destination for the GLL file. Like other code module types, TestStand Deployment Utility ensures that the sequence file is updated to reference the correct files if the files are deployed within the same base destination as the calling sequence file.

To include LabVIEW NXG source files in the deployment, click LabVIEW options, and select the LabVIEW NXG options tab. Enable the Include LabVIEW NXG Source Files option. With this option selected, LabVIEW NXG projects, components, and VIs will also be displayed in the distributed files tab. Only referenced files are displayed in the distributed files tab, but all files included in the project will be included in the deployment. You can configure the destination for the source project, but not for contained components and VIs; these files will be deployed to a location relative to the project.

Deploying the LabVIEW NXG Run-Time Engine in an MSI-based Installer in the TestStand Deployment Utility

Because the LabVIEW NXG Run-Time Engine is a National Instruments package it is not directly available as a dependency in an MSI-based installer. However, if you enable the Automatically Include Required Installers option in the Drivers and Components dialog, TestStand Deployment Utility will include the Run-Time Engine package within the installer folder. When the installer is executed, it will invoke NI Package Manager to install the Run-Time Engine package.

Limitations in the TestStand Deployment Utility

The following LabVIEW step features are not currently supported with LabVIEW NXG Steps:

• Generating a PPL for deployment. This feature is no longer necessary because LabVIEW NXG does not create PPLs.
• Merging of LabVIEW NXG projects.

Early Access Support for LabVIEW NXG

TestStand 2017 provides early access support for LabVIEW NXG. The LabVIEW NXG Adapter is suitable for developing simple test systems, or augmenting existing test systems, but has limitations that may not be acceptable for all applications. National Instruments recommends that you fully evaluate LabVIEW NXG before using it in a TestStand system.

Consider the following topics when evaluating LabVIEW NXG for your test system:

• Processor architecture—The LabVIEW NXG Adapter is only available in 64-bit TestStand.
• LabVIEW NXG Classes—TestStand 2017 does not support LabVIEW NXG classes.
• GLL Support—TestStand 2017 enables the ability to build GLLs for use with the run-time engine. GLLs can be executed through the LabVIEW NXG adapter but cannot be called directly from VIs.
• Debugging—LabVIEW NXG 2.0 does not support building debuggable GLLs. TestStand 2017 supports debugging LabVIEW NXG code modules in the development environment.
• COM Automation Support—Invoke nodes are not available in LabVIEW NXG. All Properties and Methods of the TestStand API are available through the TestStand palette in LabVIEW NXG.
• Modules and Toolkits—LabVIEW NXG is not supported in TestStand Semiconductor Module applications.
• Data types Support—The following data types present in LabVIEW NXG are not supported in the LabVIEW NXG Adapter:
  • Variants
  • Digital Waveform
  • Digital Table

LabVIEW NXG Adapter

TestStand 2017 offers early access support for calling into code modules developed in LabVIEW NXG 2.0 with the LabVIEW NXG Adapter. The LabVIEW NXG Adapter provides advanced functionality for calling VIs from TestStand. You can use the LabVIEW NXG Adapter to complete the following tasks:

• Call VIs that exist in a LabVIEW NXG project or a LabVIEW NXG GLL.
• View the VI description and parameter descriptions through the Module tab in Step Settings.
• Run VIs using the LabVIEW NXG Development System.
• Run VIs in GLLs using the LabVIEW NXG Run-Time Engine.
• Create and edit VIs from TestStand if the LabVIEW NXG Development System is installed.
• Auto-build a LabVIEW NXG GLL from the LabVIEW NXG project when executing in the LabVIEW NXG Run-Time Engine.

For a LabVIEW NXG test step, specify the module in the Module tab of the Step Settings pane by defining the Project or GLL path, the VI name, and the desired parameters. The LabVIEW NXG Adapter requires the Project or GLL Path and the VI name to be defined.

The LabVIEW NXG Adapter can run VIs using the LabVIEW NXG Development System or the LabVIEW NXG Run-Time Engine. You must build your VIs into a GLL containing your VIs when using the Run-Time Engine. Additionally, recompilation of GLLs is required when modifications are made to the original VIs.

Use the LabVIEW NXG Adapter Configuration dialog box to switch between executions using the LabVIEW NXG Development System and the LabVIEW NXG Run-Time Engine.

The Adapter Configuration also includes the option to Automatically Build Missing GLLs at Start of Execution. This option allows you to run a step in the Run-Time Engine which only has the project and VI specified. The LabVIEW NXG Adapter builds the GLL if necessary.

Use the LabVIEW NXG Advanced Settings dialog box in the Step Settings pane to access the option Always Run VI in LabVIEW NXG Run-Time Engine. This option allows you to execute an individual code module in the Run-Time Engine, regardless of the server setting for the LabVIEW NXG Adapter.

TestStand LabVIEW NXG Conversion Utility

Use the TestStand LabVIEW NXG Conversion Utility to convert TestStand files that use LabVIEW code modules to refer to their converted LabVIEW NXG code modules. You can convert TestStand Workspaces (.tsw), Sequence Files (.seq), TestStand Deployment Specification files (.tsd), and the folders containing those files using the TestStand LabVIEW NXG Conversion Utility.

The Conversion Utility application window contains the following panes:

• Files pane — This pane displays items added for conversion, their dependencies, and their status. The pane also indicates duplicate files and files that are called in a recursive loop (a file that calls itself at some point in its dependency hierarchy) that were added for conversion. You can navigate to the file from this pane by right clicking the file and selecting the Open Original option.
• Preview pane — This pane displays a preview of the output directory. When you start a preview, preconversion checks run on the files added for conversion, and any errors or warnings are reported in the log.
• Log pane — This pane displays and logs error, warning, and information messages that are generated during the conversion process.
• Call Hierarchy pane — This pane displays the call hierarchy of items and is shown when you click the Call Hierarchy button on any log message. The Call Hierarchy button appears only if the log message is about an item undergoing conversion.

TestStand API in LabVIEW NXG

TestStand 2017 includes full access to the TestStand API in LabVIEW NXG through the addition of a TestStand palette to the Functions palette. The palette includes VIs to call into the TestStand API as well as basic COM automation functionality to handle references to TestStand classes.

Operator Interfaces in LabVIEW NXG

TestStand 2017 includes early access support for developing TestStand operator interfaces in LabVIEW NXG. TestStand 2017 populates the LabVIEW NXG controls palette with the same user interface controls as well as the same ApplicationMgr, ExecutionView, and SequenceFileView controls as is offered in other development environments. Overall development of TestStand operator interfaces offers a similar experience in LabVIEW NXG as LabVIEW.

To help get started with operator interface development in LabVIEW NXG, new versions of the Simple and Full-Featured UIs written fully in LabVIEW NXG are available as shipping examples with TestStand 2017. The examples can be found in the <TestStand Public>\TestStand 2017\UserInterfaces\ directory.

HTBasic Adapter

In TestStand 2017 and later, the HTBasic Adapter is hidden by default. You can enable the HTBasic Adapter in 32-bit TestStand by selecting Configure » Adapters and opening the HTBasic Adapter Configuration Dialog Box.

INI Format

Saving to INI file format will be disallowed in future versions of TestStand.