1. Improvements to Result Processing
NI TestStand 2012 features several improvements to report generation and database logging, collectively described as result processing. NI TestStand 2012 implements asynchronous result processing, the ability to produce multiple reports and log to multiple databases, and the ability to create a compact raw results file for offline results processing. These result processing features increase test throughput and greatly increase the flexibility in report generation capabilities.
NI TestStand 2012 supports the following new reporting related features:
- Generate reports asynchronous to test execution
- Generate multiple reports of different formats for each device under test
- Improved on-the-fly report generation performance through a redesigned framework
- Support for ATML 5 report format
- Support for a compact raw result format (.tsr) for offline processing
- Generate reports offline using the offline results processing utility
- More easily customize report generation functionality without having to modify the process model files
For detailed information on each of these new result processing features and how to pick the right result processing configuration for your test application, please refer to the whitepaper Choosing the Appropriate NI TestStand Report Generation Strategy.
Below is a sampling of some of main benefits you can expect out of the box.
Asynchronous Result Processing
In previous versions of NI TestStand, result processing occurred synchronously to the test execution, where result processing for one test had to completely finish before the next device could be tested. NI TestStand 2012 introduces asynchronous result processing, which takes advantage of multicore processing so that devices can be tested back to back on one thread while result processing occurs on a separate thread. Through this new format, more devices can be tested in a shorter period of time and makes better utilization of instrument downtime.
Figure 1: Asynchronous result processing in NI NI TestStand 2012 can drastically improve test throughput
Generate multiple reports of different formats for each device under test
NI TestStand 2012 includes the ability to optionally produce multiple reports and log to multiple databases for each unit that is tested. Each report is simply a plug-in that can be enabled and configured independent of the other and can be of different formats. For example, in cases where detailed results need to be stored for post-processing but this detail is not necessary to present to an operator, a simple text report could be created that displays the status of the test for the operator while detailed results are logged to a more verbose ATML report.
Figure 2: NI TestStand 2012 allows generating multiple reports for each device tested through a simple configuration
Compact Raw Result format and Offline Result Processing
With NI NI TestStand 2012, it is possible to produce compact binary "raw results" (.tsr) files that can be processed offline (either at a later time, or even on a different machine) using the new Offline Results Processing Utility. These raw result files contain all the results of a test and can be generated very quickly. With the Offline Results Processing Utility, you can log to databases or generate reports offline from test execution so result processing does not interfere with test performance.
Note: The Offline Result Processing Utility can be invoked via the command line and sent command-line arguments, allowing it to be called from Windows Task Scheduler or even a NI TestStand sequence using the Call Executable step type.
Link in Report to other Files
With the added feature of asynchronous result processing and the ability to produce multiple reports and log to multiple databases, it could be useful to link, for example, a simple report to a detailed report if a user wanted to see more information on a test. With NI TestStand 2012's hyper linking capabilities, this is now possible for ATML, XML, and HTML report formats.
2. Improving Test Throughput
As a result of features such as asynchronous result processing and optimizations made to the most common existing built-in result processors, our internal benchmarks have shown significant improvements in test throughput:
Figure 3: Internal benchmarks show marked improvements comparing the default report (XML) from NI TestStand 2010 with different configurations in NI TestStand 2012
Basic Step Time Report
In order to further optimize test throughput, it is important to first identify the bottlenecks in your current test system.
NI TestStand 2012 ships with several process model plug-ins to help get users started with the new plug-in architecture. One of these plug-ins, Basic Step Time Report, offers a solution to benchmark and analyze the performance of a sequence file. This model plug-in produces a Microsoft Excel report that includes performance statistics such as the average and maximum time it takes to complete executions of sequences and steps. Developers can take advantage of this tool to track the performance of their test sequences and code modules to identify any bottlenecks that may be causing the tests to execute slower than desired.
Figure 4: Sample Basic Step Time report that can be used to identify bottlenecks in test systems
3. New Process Model Plug-in Architecture
The process model is a high level framework sequence responsible for defining basic functionality common to all tests, such as initializing the test station, prompting the operator to enter a serial number before testing and processing the results of the test, whether it is generating a report or logging to a database.
In NI TestStand 2012, we completely re-architected the NI TestStand process models to incorporate a plug-in based architecture. This involved decoupling the process model code from the functionality related to customizing a test program (such as result processing). All of the result processing code has moved from being defined by the process model to being defined in modular plug-ins called process model plug-ins.
There are several benefit of this new architecture that arise from the fact that result processing is now decoupled from the process model. Customizing built-in NI TestStand reports is now easier than ever, and can be done without affecting the rest of the code base or having to override code in the process model, as was previously the case. Creating a completely new report format is simply a matter of creating a new plug-in, or customizing an existing one. Even the ability to create multiple reports per test execution is a result of this new plug-in architecture.
Because much of the functionality related to test program customization was moved out of the process model, the process model is much simpler and easy to navigate. This will be beneficial for upgrading to future versions of NI TestStand because the amount of code needed to migrate is limited. This will reduce potential development time associated with upgrading a system.
Figure 5: Single Pass Execution Entry Point reduced from 45 steps to 14
4. Dynamic Dispatch Support for LabVIEW Classes
NI TestStand 2010 introduced support for LabVIEW projects and classes. Now, in NI TestStand 2012 that support has been expanded to include dynamic-dispatch support for LabVIEW classes, allowing you to take advantage of Hardware Abstraction Layer (HAL) test architecture. Developers can use the new LabVIEW adapter configuration to take advantage of this feature by choosing the Class Member Call Type to gain access to the methods and properties of a class.
Figure 6: Gain access to methods and properties of a class by choosing the "Class Member Call" call type
HALs are used in test systems to overcome instrumentation obsolescence by separating the test application from the instrument hardware. For details on HALs, refer to the whitepaper Addressing Obsolescence with Hardware Abstraction Layers. For example if your HAL consists of a "DMM" class with a specific "PXI-4071" instrument class, when the methods and properties of a generic "DMM" object (that is instantiated as a "PXI-4071") are called, NI TestStand and LabVIEW will dynamically dispatch the call to the specific implementation in the "PXI-4071" class. When the next generation of hardware comes out, the test code does not need to be rewritten because the code instantiating the generic DMM object would simply be redefined to the new DMM. This could continue to be redefined anytime a new digitizer is introduced.
5. LabVIEW Ring Control Support
In previous versions of NI TestStand, LabVIEW ring control items would only be displayed as a numeric values within the NI TestStand environment.
With NI TestStand 2012, you can now pass in and read LabVIEW ring control values in NI TestStand as the value's string representation. Developers will benefit from this by being able to use LabVIEW ring control in NI TestStand in a much easier fashion and can also include these values in a meaningful representation in a report. This also reduces the impact of code changes if the ring control in LabVIEW should change in the future.
Figure 7. View and set LabVIEW Ring Control values using the string representation of the values
6. .NET Adapter Enhancements
NI TestStand 2010 introduced the .NET Invocation Control, a more natural way of calling .NET Assemblies from NI TestStand, allowing developers to chain calls together using the common 'dot' notation. NI NI TestStand 2012 further improves the .NET Invocation Control by allowing developers to simultaneously view all the parameters for all calls in a .NET call chain. (In NI TestStand 2010, parameters for a call could only be viewed by highlighting that particular call in the call chain).
Figure 8: Chain .NET Calls while simultaneously viewing all the parameters of every call with the enhanced .NET Invocation Control
7. Sequence Editor Enhancements
NI TestStand 2012 includes several sequence editor improvements.
Drag and Drop Code Module Support
Developers can now drag and drop code module files into the sequence editor to automatically create steps. Steps created using this method are automatically configured with a Step Name and VI Path, which reduces time configuring each module.
Figure 9: Drag and drop a code module file from windows explorer onto the Sequence Editor to automatically create and configure a step
Array and String Manipulation
NI TestStand 2012 includes several improvements to how arrays can be manipulated. Developers can now visually re-arrange array elements by selecting the element they want to reorder and dragging it to the new location in the array. To further enable developers to manipulate arrays programmatically in NI TestStand, array manipulation functions have been expanded to include functions such as Max and Min. String manipulation functions have also been expanded to include Split and Trim functions.
Password Protecting Types
The sequence editor improvements includes the ability to password protect custom types, including steps and data types. Framework developers will benefit from this by being able to safely create custom types and deploy them to test developers for use as tools. This feature will eliminate confusion as to which data types are available to customize for a specific test program versus those types that are protected for use in all test programs.
Figure 10: Password protect custom step types and custom data types
8. Migration Utility
With the introduction of the new NI TestStand 2012 process model plug-in architecture, we wanted to provide a seamless method for developers to upgrade their existing test code and configurations into NI TestStand 2012. For developers upgrading from NI TestStand 2010, the migration utility will handle report and database options by migrating them to the NI TestStand 2012 format for result processing configuration options.