1. NI TestStand Sequence Analyzer
The NI TestStand Sequence Analyzer operates under a static code analyzer premise similar to one with which many developers are already familiar. Using the Sequence Analyzer, developers can quickly gain edit-time insight into their sequences and files. To identify the most common situations that can cause run-time failures, the Sequence Analyzer operates using a built-in set of rules and analysis modules to examine specified files to quickly isolate errors, enforce conformity to development guidelines or best practices, or even deliver statistical information to the developer.
Developers can use the Sequence Analyzer as a framework for building their own rules and analysis modules specific to their development practices and application requirements. A rules violation is organized into one of three severity levels, as shown in Figure 1, allowing categorization of results. After completing the analysis, developers can export Sequence Analyzer results to an XML report file for viewing in an external application.
Figure 1. The NI TestStand Sequence Analyzer reports results from rule violations in three severity levels – Error, Information, and Warning.
For an in-depth look at the new NI TestStand Sequence Analyzer, see Reduce Development Time With the NI TestStand 2010 Sequence Analyzer.
2. NI TestStand File Differ Application
Previous versions of NI TestStand included a differ application for comparing and merging the differences between two sequence files. NI TestStand 2010 provides the new NI TestStand File Differ Application, which features an improved user interface, as shown in Figure 2, and the ability to compare both sequence files and type palette files. Furthermore, the File Differ Application helps developers merge differences among three sequence files. This is ideal for engineers collaborating in sequence file development; two different developers can contribute individual changes to a base sequence file, and all three files can be merged into one resultant file.
Differences or merges can be documented and exported in the form of an XML report, and the new File Differ Application can easily integrate with source code control (SCC) providers.
Figure 2. The improved user interface in the NI TestStand File Differ Application helps developers compare differences in up to three sequence files and merge them into a resultant file.
3. Redesigned .NET Adapter
The completely redesigned .NET Adapter in NI TestStand 2010 improves both usability and performance. .NET programmers can take advantage of the flexibility of the new .NET Invocation Control – a part of the .NET Module tab on the Step Settings pane – which enables chained .NET calls through dot notation, as shown in Figure 3.
In prior versions of NI TestStand, calling a member several layers deep within a .NET object hierarchy required at least one NI TestStand step per layer of the hierarchy and intermediate storage of class instances from subclass properties; with NI TestStand 2010, the same can be accomplished with a single NI TestStand step. This yields not only usability improvements but also, in most cases, significant performance improvements over the same procedure in NI TestStand 4.2.1.
With the new .NET Adapter, developers also can manipulate NI TestStand strings through .NET string class members and store .NET variables in NI TestStand object references.
Figure 3. The new .NET Invocation Control on the .NET Module tab of the Step Settings pane enables chained .NET calls through dot notation, which in most cases results in significant performance improvements.
4. Support for NI LabVIEW Projects and Classes
The LabVIEW Module tab of the Step Settings pane now supports specification of a LabVIEW project, so developers can run LabVIEW VIs under LabVIEW projects. Once developers specify a project, they can choose a VI to run from that project, as shown in Figure 4. VIs run under LabVIEW projects can use project-specific settings and components such as conditional compilation or NI-DAQmx tasks, channels, and scales.
NI TestStand 2010 also supports directly passing and receiving the LabVIEW Class data type when calling a VI, which simplifies the process of passing LabVIEW Class data as compared to previous versions of NI TestStand. NI TestStand 2010 stores this data type as an NI TestStand object reference. With access to LabVIEW Classes, developers can more easily take advantage of hardware abstraction layers (HALs), a key strategy in combating the effect of hardware obsolescence. For more information on the benefits of using HALs as part of test architectures, see How to Mitigate Hardware Obsolescence in Next-Generation Test Systems.
Figure 4. LabVIEW VIs run under LabVIEW projects can access project components and settings.
5. LabVIEW Packed Project Libraries
LabVIEW 2010 introduced the LabVIEW packed project library, which packages multiple files related to LabVIEW in a single file with a *.lvlibp extension. With NI TestStand 2010, developers can target VIs within LabVIEW packed project libraries from the LabVIEW Module tab of the Step Settings pane, as shown in Figure 5.
NI TestStand developers may gain several efficiencies from the integration of LabVIEW packed project libraries. First and foremost, developers can use LabVIEW packed project libraries to create more modular architectures from their test code because VIs that call public VIs stored within LabVIEW packed libraries do not need to recompile to adapt to memory allocation changes from the VI contained within the LabVIEW packed library. Packed libraries have an MSI-recognized version resource, making it easier to make partial updates to a system. Also, because packed libraries are contained within a single file, they reduce the number of files and time required for deployment creation. In addition, developers can use the NI TestStand Deployment Utility to build packed project libraries from LabVIEW VIs when creating a deployment (see Figure 5).
For more information on the benefits of using LabVIEW packed project libraries with NI TestStand, see Chapter 7 of the Using LabVIEW and LabWindows™/CVI with NI TestStand manual.
Figure 5. NI TestStand 2010 integrates fully with the LabVIEW packed project library. Developers can call VIs within packed libraries from NI TestStand, and the NI TestStand Deployment Utility can create packed libraries while building deployments.
6. Improved Deployment Experience
In addition to improved logging, developers using the NI TestStand 2010 Deployment Utility can take advantage of several enhancements to the deployment creation process. Instead of deploying only workspace files, the Deployment Utility can now deploy files using a directory structure (including subdirectories), as shown in Figure 6. This option is ideal for developers keeping project files within one organized directory on disk.
The Deployment Utility also takes full advantage of functionality introduced in LabVIEW 2010. Using the utility, developers can build packed project libraries from their LabVIEW VI code modules, deploy VIs in the context of a LabVIEW project, or remove block diagram source code from their VIs and deploy noneditable versions of code modules.
Because deployment is an important part of the test software development process, stay tuned for the announcement of the new, task-based National Instruments documentation on the NI TestStand deployment process, which releases shortly after NI TestStand 2010.
Figure 6. One of the biggest enhancements to the NI TestStand Deployment Utility is the ability to deploy files from a directory structure on disk.
7. Enhanced Symmetric Multiprocessing (SMP)
LabVIEW abstracts multithreading from the developer and automatically uses multiple threads to execute code written in parallel where no dataflow dependencies exist. In prior versions of NI TestStand, however, LabVIEW VIs executing after being called from NI TestStand used only one execution thread and did not follow expected multithreading execution patterns unless configuration changes were made to LabVIEW VI code modules.
In NI TestStand 2010, developers can use the LabVIEW Adapter Configuration dialog box, shown in Figure 7, to specify the multithreading behavior of all VIs executed from NI TestStand regardless of the configuration in the VI’s properties. Because of this, developers can control the number of threads used and whether LabVIEW execution threads adopt the thread affinity of the NI TestStand execution thread.
Figure 7. Developers can control the multithreading behavior of all LabVIEW code modules from within the LabVIEW Adapter Configuration dialog box.
8. Support for 64-Bit Integers and Pointer Data Types
NI TestStand 2010 features support for directly passing 64-bit integer data types as parameters with all adapters except the HTBasic adapter as long as the application development environment supports 64-bit integers. This includes using the adapter to create and edit code modules that use 64-bit integers and verifying prototypes that use these data types.
Additionally, a new pointer/handle data type featured in the LabWindows/CVI and C/C++ DLL adapters is ideal for developers previously storing pointer or handle parameters as numeric data types in NI TestStand. NI TestStand stores pointer/handle parameters in NI TestStand object reference variables. This reduces the amount of refactoring necessary for future upgrades to 64-bit versions of code modules and applications.
Figure 8. NI TestStand 2010 features support for 64-bit integer and pointer/handle data types.
9. Autodetect Versions of the LabVIEW Run-Time Engine
In previous versions of NI TestStand, developers could select only one version of the LabVIEW run-time engine with which to execute all VI code modules. Unfortunately, if some modules were created using a different version of the LabVIEW run-time engine than specified in the Adapter Configuration dialog box, NI TestStand returned errors.
Shown in Figure 9, the Adapter Configuration dialog box now includes the capability to automatically use the LabVIEW run-time engine version that corresponds to a VI code module to run the VI. This reduces errors and debugging time when VIs have been saved in multiple versions of LabVIEW.
Figure 9. Developers can reduce debugging time by automatically detecting run-time engine versions when code modules have been saved using different versions of LabVIEW.
10. Learn More Today
The mark LabWindows is used under a license from Microsoft Corporation. Windows is a registered trademark of Microsoft Corporation in the United States and other countries.