Academic Company Events NI Developer Zone Support Solutions Products & Services Contact NI MyNI
This Document is not yet Rated  Rate this Document

What is new for TestStand 4.2?

Primary Software: TestStand
Primary Software Version: 4.2
Primary Software Fixed Version: N/A
Secondary Software: N/A

Problem:
What is new for TestStand 4.2?

Solution:

The following list describes the new features in TestStand 4.2 and other changes since TestStand 4.1. This list only summarizes each new feature. Refer to the TestStand documentation listed for a particular feature for more information about the feature.

TestStand Deployment Utility Improvements

The TestStand Deployment Utility now uses improved internal caching to accelerate analysis and build times. Additionally, the LabVIEW VI Options dialog box includes the following new options so you can choose between faster performance and improved error handling:

  • Check for Broken VIs During Analysis—When enabled, the TestStand Deployment Utility checks for broken VIs during analysis. This option is disabled by default to improve performance. Enable this option when you want to debug VI errors.
  • Check for Broken VIs After Build—When enabled, the TestStand Deployment Utility checks for broken VIs in the image directory when building an image. This option is enabled by default to ensure that distributed files do not contain broken VIs. Disable this option for better performance if you are rebuilding and have not made changes to VIs.
  • Remove Unused SubVIs—Removes unused polymorphic subVIs and disconnects type definitions when building. This option is disabled by default for backward compatibility. Enable this option for better performance and to deliver a smaller number of subVIs.
  Note  Enabling the Remove Unused SubVIs option disables certain editing and debugging options on the deployed system, such as wiring a new type to a polymorphic VI or making type changes across several VIs by editing a type definition.

The Deployment Utility also better integrates with LabVIEW 8.6.1 or later for improved build speeds and deployment of advanced LabVIEW features, such as VIs that include LabVIEW object-oriented programming.

The Installer Properties section of the Distributed Files tab of the TestStand Deployment Utility also includes a new Force File to Install option. Enable this option to force the installers the deployment utility builds to always overwrite existing files.

Refer to Chapter 14, Deploying TestStand Systems, of the NI TestStand Reference Manual for more information about the TestStand Deployment Utility.

Using Expressions to Customize Report File Paths

In addition to the existing options to customize reports, you can now use predefined macros and custom expressions on the Report File Pathname tab of the Report Options dialog box to specify the filename of reports and the directory in which TestStand stores reports. For example, you can use expressions to save reports in a directory that uses the sequence filename, save reports in different directories based on execution status, and generate report filenames that include the serial number, user name, or execution status. You can use expressions to replicate all existing report filename options.

Select Specify Report File Path by Expression in the File Name/Directory Options drop-down list in the Generate Report File Path section on the Report File Pathname tab of the Report Options dialog box to enter an expression in the Report File Path control. The following table lists common report options and the equivalent expression for the Sequential model using the client sequence file directory as the base directory.

Current Report Option Equivalent Expression
New UUT Report File for Each UUT <ClientFileDir>\Report_<UUT>.<FileExtension>
Prefix Sequence File Name to Report File Name <ClientFileDir>\<ClientFileName>_Report.<FileExtension>
Add Date and Time to File Name <ClientFileDir>\Report_<FileDate><FileTime>.<FileExtension>
Force File Name to Be Unique <ClientFileDir>\Report_<Unique>.<FileExtension>
Client Sequence File Directory + Prefix Sequence File Name to Report File Name + New UUT Report File for Each UUT + Add Date and Time to File Name <ClientFileDir>\<ClientFileName>_Report_<UUT>_<FileDate><FileTime>.<FileExtension>

The following table lists example expressions for common tasks using the Sequential model.

Task Equivalent Expression
Save reports in a directory that uses the sequence filename C:\<ClientFileName>\Report.<FileExtension>
  Note  TestStand overwrites existing files unless you use the <Unique> macro or enable the Append if File Already Exists option.
Save reports in different directories based on execution status C:\<ClientFileName>\<UUTStatus>\Report.<FileExtension>
  Note  TestStand overwrites existing files unless you use the <Unique> macro or enable the Append if File Already Exists option.
Generate report filenames that include the UUT serial number C:\<ClientFileName>\Report_<UUT>.<FileExtension>
Generate report filenames that include the user name C:\<ClientFileName>\Report_<UserName>.<FileExtension>
Generate report filenames that include the execution status C:\<ClientFileName>\Report_<UUTStatus>.<FileExtension>

TestStand supports the following macros:

  • <Batch>—Batch serial number the user provides during execution. If the batch serial number is empty, TestStand uses the Empty_Batch_SerialNo resource string.
  • <ClientFileDir>—Directory that contains the client sequence file.
  • <ClientFileName>—Name of the client sequence file.
  • <Desktop>—Directory path of the desktop.
  • <FileExtension>—File format extension that corresponds to the report format you specify on the Contents tab of the Report Options dialog box.
  • <FileDate>—String that contains the date that TestStand when first writes the file to disk during execution.
  • <FileDay>—String that contains the numeric day (1 through 31) when TestStand first writes the file to disk during execution.
  • <FileMonth>—String that contains the numeric month (1 through 12) when TestStand first writes the file to disk during execution.
  • <FileTime>—String that contains the time when TestStand first writes the file to disk during execution.
  • <FileYear>—String that contains the year when TestStand first writes the file to disk during execution.
  • <PublicDocumentsDir>—Public documents directory.
  • <StationID>—Station ID during execution.
  • <TempDir>—Temporary directory.
  • <TestSocket>—Test socket number during execution. This value is always 0 for the Sequential model.
  • <TestStandExecutableDir>—Directory of the TestStand executable.
  • <TestStandPublicDir>—<TestStand Public> directory.
  • <Unique>—A unique numerical value if the path evaluated already exists on disk.
  • <UserDocumentsDir>—My Documents directory path during execution.
  • <UserName>—Username currently logged in during execution.
  • <UUT>—UUT serial number users specify during execution. If the serial number is empty, TestStand uses the Empty_UUT_SerialNo resource string.
  • <UUTStatus>—UUT status during execution.

Refer to Specifying Report File Paths by Expression for more information about each macro and about using expressions to specify the filename of reports.

On-The-Fly XML Report Improvements

TestStand includes improved style sheets and uses new report API objects to generate on-the-fly XML reports more efficiently. Refer to the XML Reports section of Chapter 6, Database Logging and Report Generation, of the NI TestStand Reference Manual for more information about XML reports.

Improved XML Style Sheets

TestStand includes restructured style sheets that reduce the time required to generate HTML output from XML report files and to simplify the task of modifying style sheets so that you can change the appearance and content of XML reports. Refer to the XML Reports section of Chapter 6, Database Logging and Report Generation, of the NI TestStand Reference Manual for more information about XML reports.

Call Executable Step Improvements for Scripting Languages

You can now use the Call Executable step to more easily call scripting languages, such as Python or Perl, using any of the following methods:

  • Specifying the script file as the file to execute
  • Configuring the standard input text or file to pass to the executable call
  • Configuring the file or variable to retrieve standard output and error
  • Specifying the working directory

You can now use the File Pathname control on the Call Settings tab on the Step Settings pane to specify the name of a file to open using the default application associated with the extension of the file. For example, you can launch a .bat file or open a .txt file by specifying the non-executable file directly. You can also use expressions to specify the path to the file.

You must configure the step to wait for the specified executable call to exit or wait for a specified time to enable access to the options you use to specify standard input to pass to the call and to specify how to retrieve standard output and standard error from the call.

You can configure the step to stream a file as input or evaluate a string or an expression as input. You can store the output and error information in a file on the local computer or on the remote computer when you call the executable on a remote computer. TestStand overwrites the file if it already exists. Alternatively, you can use an expression to store the output and error information in a TestStand variable or property, and you can use the status expression of the step to evaluate the output value. You can configure the step to ignore or set the step status to Error or Failed when the executable you call returns an error. You can include error information in the report TestStand generates.

You can specify the working directory for the executable by configuring TestStand to use the file directory, the sequence file directory, the current directory for the process, or an absolute path. You can also use expressions to determine the working directory at run time.

Refer to Chapter 4, Built-In Step Types, of the NI TestStand Reference Manual for more information about the Call Executable step type.

Visual Studio 2008 Support

TestStand now supports creating, editing, and debugging code modules with Visual Studio 2008, in addition to existing support for Visual Studio 2005. TestStand no longer supports using Visual Studio 2003 for these operations from within TestStand. You can call DLLs or manually attach to a TestStand process to debug native code using Visual Studio 2003 or earlier. However, you cannot attach to a TestStand process using Visual Studio 2003 if you want to debug managed code.

Use the .NET Adapter Configuration and the C/C++ DLL Adapter Configuration dialog boxes to specify the versions of Visual Studio you want to use when you create or edit code, or when you debug code. You can configure the .NET and C/C++ DLL Adapters to use a specific version of Visual Studio installed on the computer to use the version that matches the project file the step specifies or to prompt you when performing the operation.

Refer to Chapter 5, Module Adapters, of the NI TestStand Reference Manual for more information about using Visual Studio with TestStand.

Customizing TestStand Behavior on Multi-core Systems

Symmetric multiprocessing (SMP) systems are computers that contain multiple CPUs, where a CPU can be a single core on a multi-core processor or a single-core processor on a multiprocessor computer. Windows and other modern operating systems can take advantage of SMP systems to achieve increased performance. SMP systems achieve better performance by executing multiple threads on multiple CPUs concurrently. Performance improvement can come through executing multiple processes concurrently as well as from executing multiple threads within a process concurrently. Generally, when an application is implemented with multiple threads, the operating system attempts to schedule each thread on a separate CPU when possible. Under some circumstances, this automatic scheduling can have a negative impact on application performance.

For instances in which the automatic scheduling of threads on CPUs negatively affects TestStand application performance, you can manually assign or constrain the TestStand process or specific threads to specific CPUs using the following new TestStand features:

  • Station Option: Default CPU Affinity for Threads—Determines the default CPU affinity TestStand gives new threads of executions and the user interface thread. The default behavior is to allow all CPUs. This option is located on the Preferences tab of the Station Options dialog box.
  • Sequence Call Step Setting: CPU Affinity for New Thread or Execution—Specifies the CPU affinity of the new thread in the current execution or the initial thread in a new execution. By default, the new thread uses the Default CPU Affinity for Threads station option. However, the new thread can also allow all CPUs, use the CPU affinity of the calling sequence, or allow specific CPUs that you specify. This option is located on the Sequence Call Advanced Settings window.
  • CPU Affinity Step Type—Directly gets or sets the CPU affinity of the process or the current execution thread. This step provides low-level control over how a system utilizes CPUs, and is located in the Advanced subgroup of the Synchronization group on the Insertion Palette or in the Insert Step submenu of the Steps pane context menu. Refer to Appendix B, Synchronization Step Types, of the NI TestStand Reference Manual for more information about the CPU Affinity step type.

Refer to the Using TestStand on SMP Systems topic in the NI TestStand Help for more information about optimizing TestStand performance on SMP systems for multithreaded applications and about when you might need to use these new features to control CPU affinity in TestStand.

PropertyObject Attribute Support

You can now create attributes for TestStand PropertyObjects, such as variables, steps, and module parameters. Use attributes to store additional information, such as the author of a sequence, about a PropertyObject within a sequence file or type palette file.

When you copy a PropertyObject, TestStand adds the attributes stored on the PropertyObject to the new copy. You can create attributes for properties of a type. Attributes of type properties specify the default attributes when you create an instance of a type.

Every PropertyObject includes an Attributes property, which is an unstructured container that stores arbitrary data. Although an attribute can be any kind of data, you typically create a name-value pair to give an attribute a name and a data value.

Right-click a PropertyObject on the Variables pane and select Advanced»Edit Attributes from the context menu to launch the Attributes dialog box, in which you can create and edit attributes. PropertyObjects with attributes include an Edit Attributes button in the Name column of the Variables pane.

Steps with attributes include the word Attributes in the step description, and the General panel of the Properties tab on the Step Settings pane includes an Edit Attributes button.

Right-click a parameter on the Module tab of the Step Settings pane in the sequence editor or in the Specify Module dialog box in user interfaces and select Edit Attributes from the context menu to launch the parameter Attributes dialog box. Parameters with attributes include an Edit Attributes button in the Name column of the Parameters Table. You can edit attributes for fields of containers and elements of arrays. TestStand associates parameter attributes with the module parameter, which TestStand stores with the step configuration information, not with the parameter value that TestStand passes to the module. TestStand stores attributes specified on module parameters with the parameter definition for the module, and not with a parameter value passed to the code module.

The TestStand Differ application detects and merges attribute differences. Right-click an item and select Edit Attributes from the context menu or click the Edit Attributes button in the Name column of the Differ window to launch the related Attributes dialog box. When you right-click an item and select Replace Item Values in File <filename> from the context menu, TestStand now also copies attribute values.

Attributes must have unique names. You can use a container under an Attributes property to serve as a namespace and to ensure uniqueness of attribute names. National Instruments recommends using company prefixes as namespaces. For example, the Attributes property can include a top-level NI container that acts as a namespace for attributes of built-in features. The NI attribute can include a TestStand attribute for TestStand-related attributes. The NI.TestStand attribute includes subproperties for individual TestStand features to prevent conflicts among TestStand features. Similarly, NI.ATML would include ATML-related attributes.

  Note  The report generation and database logging features in TestStand do not support including attribute information in reports or databases. In addition, the Find and Find in Files features in the sequence editor do not support searching attributes for matching attribute names or values. Also, the PropertyObject.GetXML and the PropertyObject.SetXML methods do not support attribute information in the generated XML.

Setting the Policy for Marking Files as Modified

Use the Do Not Mark Files as Modified if Modification is Caused Only by Automatic TestStand Version Upgrade option on the File tab of the Station Options dialog box to configure when TestStand marks files as modified. Enable this option if you do not want TestStand to mark files as modified when the only changes to the file are the result of the automatic conversions TestStand makes when you open files from an older version of TestStand in a newer version of TestStand. These automatic conversions occur when TestStand upgrades older versions of built-in, National Instruments-created types and step types and then resolves data format changes that exist between the versions.

This option is disabled by default. When you enable this option, TestStand marks as modified only the files with user-defined changes so you can avoid resaving and revalidating files you did not directly modify. Enabling or disabling this option does not change how TestStand loads the file into memory or saves the file to disk.

This option applies only to National Instruments-created types, step types, and file modifications. Use this option to prevent TestStand from prompting to resave upgraded files, which might require revalidation. When you enable this option, TestStand still marks files as modified when type conflict resolution results in updates to user-defined types and step types in the file. Resave files in the version of TestStand you are using to optimize performance when opening files.

Regardless of the value of this option, opening files from a TestStand version older than the version you are using requires TestStand to perform an in-memory conversion. Resave files in the version of TestStand you are using to optimize file loading performance.

Other TestStand Enhancements

TestStand 4.2 includes the following additional enhancements:

  • Use the Set Thread Externally Suspended VI within a code module or step type to enable a calling execution to break while the code module or step type performs a lengthy operation or waits an indeterminate period of time. TestStand considers the calling thread to be suspended if the user requests that the execution break. Refer to the NI TestStand VIs and Functions Help for more information about the Set Thread Externally Suspended VI.
  • Several process model changes support the new reporting features.
  • The TestStand Version Selector no longer requires administrator privileges. You can now change the active version of TestStand while logged in as a user with standard privileges.
  • The TestStand Version Selector includes the following new command-line options:
    • /noprompt—Suppresses prompts while performing activation and launch operations.
    • /installing—Displays a status prompt while activating the specified version without displaying errors. You must use this option with the /version and /noprompt options.

    Click the Help button in the TestStand Version Selector to launch the TestStand Version Selector Help, which includes more information about available command-line options.
  • By default, the sequence editor now allows you to edit read-only files.
  • You can now select Start»All Programs»National Instruments»TestStand x.x»Tools and select the stand-alone tool you want to run outside of the sequence editor, including the Database Viewer, TestStand Deployment Utility, Sequence File Converter, Sequence File Differ, and XML Packaging Utility.
  • You can now use additional results to log output parameters without a variable specified to store the result. TestStand 4.1 did not log an additional result for an output parameter not stored in a variable.
  • The NI TestStand Help and manuals includes updated content. The help files are located in the <TestStand>\Doc\Help directory. The manuals are located in the <TestStand>\Doc\Manuals directory.
  • Chapter 1, Introduction to TestStand, of the Using TestStand manual now contains a Creating a TestStand System section that includes information about creating a TestStand-based test solution, including phases of the development life cycle and the licensing options available for each phase.


Related Links:
KnowledgeBase 4LK9L6T3: What is New for TestStand 4.1?
KnowledgeBase 4LK9E9T3: TestStand 4.1 Known Issues and Bug Fixes
KnowledgeBase 4LK9CPT3: Known Compatibility Issues and API Changes for TestStand 4.1

Attachments:





Report Date: 05/11/2009
Last Updated: 07/10/2009
Document ID: 4XA8R2T3

Your Feedback! poor Poor  |  Excellent excellent   Yes No
 Document Quality? 
 Answered Your Question? 
  1 2 3 4 5
Please Contact NI for all product and support inquiries.submit