Top 5 TestStand Tips and Tricks

Publish Date: Feb 18, 2014 | 3 Ratings | 4.33 out of 5 | Print

Overview

NI TestStand is a powerful test management and sequencing program that puts hundreds of tools and operations in the hands of new developers.

These five tricks are some of the most important for new users to become more efficient and effective with NI TestStand:

Table of Contents

  1. Begin Every Project With a Workspace
  2. Design Code Modules for Reuse
  3. Compare Limits in NI TestStand, and Not in Your Test Code
  4. Use Model Callbacks
  5. Take Advantage of Search Directories
  6. Additional Resources

1. Begin Every Project With a Workspace

Developers sometimes start a coding project without much attention to the organization of files. They plan to come back and organize their files in the future. However, as many test engineers can attest, projects that are poorly organized from the beginning can be a pain to clean up later. This is especially true of large-scale test frameworks like those that many customers build in NI TestStand.


To develop test systems that are easier to maintain and understand, take advantage of NI TestStand workspaces. A workspace is a collection of one or more NI TestStand projects that contain and organize your sequence files, code modules, and any additional documentation.

There are three main advantages of using NI TestStand workspaces in your projects:

 

Easily Manage Files

When building an NI TestStand application, one of the challenges developers face as projects evolve is keeping track of both code modules that are directly called in a sequence and other file dependencies. Workspaces give you the ability to organize all the files in an application into projects and folders. In addition, workspaces can reduce code module load times by using search directories. With search directories, you can search files in a workspace before any other file, thus minimizing load times and guaranteeing that the correct file is loaded into memory.

 

Take Advantage of Source Code Control (SCC)

Using NI TestStand workspaces also makes integration possible with SCC software by giving you the ability to easily check out and check in files from a predefined SCC provider. If you add a code module or sequence to a workspace, you can right-click on the file and select to check out or check in from your SCC provider.


Simplify Deployment

Workspaces simplify the deployment of test systems using the NI TestStand Deployment Utility. This utility uses the list of files in a workspace to find their dependencies and create an installer that can then be distributed to other machines.

 

Back to Top

2. Design Code Modules for Reuse

Rather than develop code to accommodate specific tests, a good test engineer should be looking for opportunities to create general test code modules that can be used in a number of test instances. Although NI TestStand does not force you to program for modularity, it does provide an architecture in which you can execute code modules and easily change their functionality based on different input parameters.  

 

Use Controls as Opposed to Constants

You should carefully consider which inputs and constants of your code modules may change in the future. Coding that uses constants to set parameters in code modules prevents you from being able to acquire from a different channel or device when calling the code. If all of the inputs in an NI LabVIEW code module were controls, the code module could be used for multiple different channels and devices.

Figure 1.Using controls as opposed to constants in code gives you the ability to use the same piece of code for many situations.

 

Log Parameters More Easily

Passing inputs and outputs to NI TestStand as parameters gives you the ability to easily add the information to reports and databases by checking the Log checkbox on the Module tab of the Step Settings.
  

Figure 2. Logging additional results is as easy as checking the proper field.

 

Organize Inputs and Outputs

The NI LabVIEW programming environment  and ANSI C/C++ languages  give you the ability to group related inputs and outputs. Using clusters in LabVIEW means that code modules  deliver multiple related pieces of information in a single container. Using clusters saves connector pane terminals and provides users context for the code. ANSI C and C++ languages use structs to group related data that can be passed to NI TestStand.

 

You must also be careful not to add too many parameters to code modules. Passing unnecessary parameters to or from NI TestStand can clutter the parameter view and make the test step difficult to use and maintain. Strike a balance between modularity and complexity to ensure that your code not only meets today and tomorrow’s needs, but also is as simple and self-documenting as possible.

 

 

Back to Top

3. Compare Limits in NI TestStand, and Not in Your Test Code

You can also create more reusable code modules by performing limit comparisons in NI TestStand rather than in your test code. Embedding test limits in code modules restricts the reusability of code modules and can increase the time needed to update test systems by requiring code changes. Below are a few tasks to perform in NI TestStand and the reasons why:  

 

Limit Testing

One of the easiest ways to use NI TestStand functionality is to remove limit testing from code modules. NI TestStand has multiple steps types to perform limit testing including numeric limit, pass/fail, string, and multiple numeric limit tests by default. Another advantage of letting NI TestStand handle limit testing is that the high and low limits as well as the actual measurement can be automatically logged to the report or database.

 

Figure 3. As opposed to adding complexity to code modules, you can use the logical test steps in NI TestStand.

 

Custom Step Types

Do you have complex limits that the above tests can’t handle? You can create custom step types to perform custom analysis and comparisons that can then be reused by others.  

 

Property Loader

NI TestStand also allows for simplified limit loading using the Property Loader tool or step types. NI TestStand Property Loader gives you the ability to load or save limits in text files, spreadsheets, and databases. Instead of embedding test limits in code modules, define test limits in the sequence file and use the parameter list to pass the limits to the code modules, if necessary. With NI TestStand 4.x and later, you can save sequence files in a locked binary format to reduce the risk of tampering on the target computer.

 

 

Back to Top

4. Use Model Callbacks

The NI TestStand process model contains callback sequences that handle common tasks in the execution of a sequence. For example, the PreUUT callback executes before you run each unit under test (UUT) and displays a dialog box to get the UUT serial number from the operator. Although this is the default functionality of this callback, you can customize it to meet the specific requirements of a certain application. For example, the PreUUT callback can be overridden to get the UUT serial number from a bar code scanner or a company database, or download a model-specific sequence file from a configuration management database.

 

Figure 4. You can modify the code module in the PreUUT callback to a more efficient and reliable process.

 

You have two options when customizing functionality in a process callback: override a callback in a particular sequence file or make the changes directly in the process model.

 

Overriding Callbacks

This should be done when implementing functionality that is specific to a particular UUT or UUT model. Overriding callbacks consists of creating sequences within a sequence file with the same name as callbacks in the process model. When the process model sees these sequences within the sequence file, it executes them instead of the sequences contained in the process model. For example, if you add a sequence in your sequence file called PreUUT, this sequence is called instead of the PreUUT sequence in the process model.

 

Because overriding callbacks in a sequence file gives you the ability to specify the behavior for each set of sequences, this methodology should be used when the behavior applies to only a certain set of sequences or UUTs. For example, if certain models of a product contain their serial number in an RFID chip, while others contain it in a bar code on the printed circuit board (PCB), the PreUUT callback should be customized using an overriding callback.

 

Customize Process Model

Assume that your UUTs always have their serial numbers documented on a bar code on the PCB. In this case, consider customizing the PreUUT callback directly in the process model. This causes all sequences to acquire the serial number using a bar code scanner. Changes to the process model are shared across all stations running the process model. By implementing this feature in the process model, you can guarantee that all stations implement the same functionality and facilitate the deployment of changes to production.

 

You should be aware that changes to a process model are permanently saved. Always save a copy of the model that will be modified to ensure that the default models can be restored if necessary.

 

 

Back to Top

5. Take Advantage of Search Directories

A challenge NI TestStand developers face with sequences deployed to test machines is specifying the path to a code module so that it is valid both in development and deployment. NI TestStand includes the ability to specify absolute paths and paths relative to a search directory. Search directories are the set of directories that NI TestStand searches to find code modules and other files. When searching for files, NI TestStand searches each directory in this list in order until the file is found.

 

Search Directories.png

Figure 5. An easily accessible settings window gives you the ability to prioritize and exclude directories from the overall NI TestStand search directory.

 

Along with the benefits provided by search directories, this feature does include some caveats:

  • Be judicious when adding new directories to the list of search directories. If there is a long list of search directories, NI TestStand has to search through multiple directories before finding the necessary code module, which can have a substantial impact on performance. It is best to remove search directories in cases where they might not be necessary. 

  • Avoid using the “search subdirectories” option for search directories. You could guarantee that NI TestStand finds a code module by setting the search directories to look in the C: directory and its subdirectories. However, NI TestStand would then search the entire C: directory when searching for files, which would impact performance.

  • The search directories that are addressed first should be the ones that are used the most or that contain the highest number of code modules.

Back to Top

6. Additional Resources

 

Back to Top

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit