Creating Configurable Test Steps in TestStand

In TestStand, you can create your own configurable test steps to fit your specific testing needs. The goal of a configurable test step is to enable the user to configure test parameters during sequence editing, without additional programming. Configurable test steps provide the user with a graphical user interface (GUI) to configure and visualize the test parameters. When the user configures a configurable test step using the graphical user interface, the user can set test parameters while visualizing how those parameters affect the Pass/Fail test status.

In a manufacturing environment, the ability to make quick changes to the test system is very valuable. With a traditional test approach, a test developer would generate a test sequence for the technician or operator to execute on the production floor. When a change was needed in that test sequence, it was very difficult for the technician to modify the test procedure and visualize how that change would affect the production line.

Configurable test steps provide a robust alternative for making quick changes to a test, either in a development or production situation. A configurable test step provides a graphical user interface to the user for modifying required parameters while giving the user a visual aide to see the impact of those changes. Configurable test steps can speed up the process of creating new test sequences or procedures, and provide an easy-to-use mechanism for making modifications.

TestStand not only provides the flexibility to create custom step types that meet your specific needs, but also abstracts implementation details from the final user, which is the objective of creating a configurable step type.

This application note focuses on creating a configurable test step to perform audio testing. Specifically, it shows how to create a configurable total harmonic distortion (THD) test step. THD can be defined as the total distortion, including the rms sum of all harmonics as a percentage compared to the amplitude of the fundamental signal.

When you create a configurable test step, you must complete the following:

• Define how the test will be performed, including all of its inputs and outputs.
• Create a custom step type that contains all of the parameters needed for the test.
• Create a configuration interface so the user can set and visualize test parameters.
• Create a menu palette to organize the test steps.

Defining How a Test Will Be Performed

Defining how the test will be performed is the most important task of creating a configurable test step. This task requires not only identifying how the test will be executed, but also how data will be acquired and stored. Depending on the type of test, you can design your step types to acquire data in different ways. The most common approaches are the following:

• Each test step is self-contained. This means that each step is responsible for acquiring its own data, analyzing it, and evaluating it to a Pass/Fail status.
• Each step analyzes data acquired by a previous step. This means that you will design an Acquire step that will be in charge of performing the acquisition of and storage of data in some variable for other steps to use. Then you will create a Test step that reads and analyzes the data in that variable.
  
  When you use this approach, you also have to think of the way your steps will share the data. You could specify a particular variable for each step to read and write to. In fact you could dynamically create this variable so that the user doesn’t worry about those details. This variable could be a local, sequence file global, or station global variable, depending on the scope you want your steps to have. You can even create the variable as a temporary global variable so the variable is totally transparent to the final user.
  

There are both advantages and disadvantages to each approach and no one approach is better than the other. Depending on your application, you must decide which approach works best for you. For this application note, assume that your THD test step is self-contained, meaning that the step acquires and analyzes the data.

Once you have determined the step architecture, you need to determine the flow of execution. At a very high level, the flow of the THD test step is as follows:

Based on this flow, it should be evident that the following modular components are needed to:

• Configure the test and acquisition parameters.
• Perform the data acquisition.
• Apply the THD algorithm to the acquired data.
• Evaluate the results to generate the Pass/Fail status.

Identifying the components is as important as identifying how to implement them. It is very important to make sure that your implementation fits the TestStand architecture. One approach is to create the components as independent code modules and call them directly from the step. The acquisition module can be the main code module of the step, while the module that calculates the THD can be called as a Post Step substep. The acquisition module would have to store the acquired values in the step properties, and the THD calculation module must read in the acquired values again to perform the calculation.

A second approach is to create one code module that acquires the data and performs the THD calculation. The correct choice depends on your design and your needs. The second method is faster because it does not have to access the step property twice. The drawback is that combining the acquisition and calculation modules provides less flexibility and modularity. The best approach is the one that fits your needs for flexibility or performance.

You should always calculate the Pass/Fail status using TestStand. In general, test steps should return a value to TestStand so that TestStand can determine the step status. Following this approach guarantees modularity and flexibility.

For this application note, assume that the THD step follows the second approach, which contains a code module that performs both the acquisition and the THD calculation. It returns the THD value to TestStand to compare it against defined limits.

Creating the Code Modules

For the THD step type, you need the following two code modules:

• Configuration code module – executes at edit time.
• Test code module – executes at run time.

With the Configuration code module, the user configures all of the test properties and parameters. The Test code module performs the appropriate test, based on the parameters configured through the Configuration code module.

Note: It is good practice to store all code modules in a file structure under <TestStand>\Components\User\StepTypes to help maintainability and distribution. The following figure shows the file structure for the THD test.



Test Code Module
The THD test contains one code module that performs both the acquisition and the THD calculation. This code module can be implemented in any programming language, such as LabVIEW, LabWindows/CVI, and Visual Basic. The flow of execution for a Test code module is as follows:

It is important to note that the link between the Configuration code module, the Test code module, and TestStand is through TestStand step properties. The step properties hold the necessary information so that it can be accessed at different stages of the step execution (configuration and test execution).

When you create a Test code module, it is important to make every step property accessible to it. It is recommended that you pass the step properties as parameters to the code module, or pass the Sequence Context so that the code module can access the parameters it needs.

Configuration Interface (Configuration Code Module)
A Configuration Interface is a module with which the user can interactively configure the parameters of a test, through a graphical user interface. Normally this interface runs the specific test in a While loop so the user can visualize how the modification of parameters affects the test. They generally include a Pass/Fail indicator that helps the user set and visualize the tolerances in the test.

A good way to determine the look and feel of a configuration interface is to analyze the inputs and outputs of the test. For example, the THD Test requires the fundamental frequency, the highest harmonic, and the THD high limit as inputs. The THD test then provides the THD calculation as an output. Given that information, you could create a program in any language where the user inputs these parameters and interactively visualizes the response.

It is important to note that this program should be running a THD test continuously with either real or simulated data so that the user can visualize the effect of changing the parameters. If your design is modular, you could even reuse the Test code module in a loop to perform the continuous testing while the step is being configured.

It is good practice to include some level of simulation in configuration interfaces because it is useful for demonstration purposes or when no hardware is available. The flow of execution of a configuration interface is as follows:

The configuration interface you create sould perform the following functions:

1. Read all the necessary properties from the current step.
2. Update the GUI with the properties read from the step. This allows multiple instances of the same step type within the same sequence. Every time a configuration interface is invoked, it will show the parameters associated with that particular instance of the step.
3. Run the test continuously so the user can see how changing the parameters alters the results of the test.
4. When the user closes the GUI, all current parameter settings must be stored in corresponding step properties or TestStand variables. It is important to include a Cancel button on the configuration interface in case the user decides to ignore the current settings and go back to the previous ones.
   

Remember that the purpose of the configuration interface is to expose the relevant properties of the step so that the user can configure the appropriate test values.

One possible configuration interface for a THD test step is shown in the following figure.

It’s important to emphasize that the configuration interface is continuously acquiring data and performing THD evaluations. If the user modifies any parameter, it will immediately be reflected in the graph as well as in the Pass/Fail.

Creating a Configurable Test Step Type

You should consider the following questions when you create a custom step type.

• How will the step store configuration and test data?
• How will the user configure the step parameters?
• What is the step execution flow?
• How will the step evaluate a Pass/Fail status?
  

Follow the steps below to create a configurable test step type.

1. Create a new TestStand type palette. The type palette is very useful in keeping your step types organized. For example, you could have an Audio Test type palette and a Motion Test type palette. Each type palette contains several configurable step types that perform a specific action. To create a new type palette, follow the steps below:
   1. Click the type palette icon on the Tool bar of the TestStand sequence editor.
   2. Using the Palette ring control in the Type Palette window select the Customize option. The Configure Type Palettes dialog box appears showing all of the currently existing palettes. Notice that the default TestStand palettes contain the NI_ prefix to differentiate them from custom created palettes.
   3. Click the Create button and name your new type palette. The name should resemble the palette functionality. For example, Audio_Test_Palette.
   4. Click OK to close the Configure Type Palettes dialog box and return to the Type Palette window. Verify that the type palette you just created is currently selected in the Palette ring control.
2. Add a new step by right-clicking in the right side of the Type Palette window and selecting the Insert Step Type option.
3. Name the new step type THD.

At this moment, the new step type is a generic type. You could start creating the THD step from scratch; however, it is a good idea to take advantage of the step type features already available to you in TestStand.

By now, you should have determined that the THD test step acquires its own data, performs the calculation, and returns the value to TestStand. This set of requirements is very similar to the default behavior of a Numeric Limit Test step type in TestStand. Instead of starting from scratch and reproducing the capability of this step type, it is more efficient to combine your new step type with the existing Numeric Limit Test step type. To combine these steps, right-click the newly created THD step and select Combine With Step Type»Tests»Numeric Limit Test from the context menu as shown in the following figure.



It is recommended that you review the step types included in TestStand so that you can select which one best fits your application. For example, if your test returns a string it is a good idea to combine it with a String Value Test. In other cases, calculating the status may be complicated, so it is a good idea to combine your step with the Pass/Fail Test step type and create a code module that performs the calculation as a Post Step substep. The code module should return a Boolean (True/False) value so TestStand can evaluate the step status. It is a good idea to have a separate code module to evaluate complex status expressions, instead of adding this code into the main test code module. By keeping the code modules separate, and calling the status code module as a Post Step substep, the system becomes more flexible and modular because you can reuse both the Status and Test code modules when implementing future Configurable step types.

Next, you must add to the step as many step properties as the test requires. Remember that step properties serve as local variables to a step. All these properties will be configured at edit time and read in at run time. It is very important to understand all of the necessary inputs and outputs of the test, so you can map them to the appropriate step properties.

Because the THD test step type acquires its own data, it needs parameters to configure the acquisition as well as some properties to store the results. For the test itself, there are also some required parameters. Because the THD test step inherits from the Numeric Limit Test, all of the properties for storing the results and the limits are already created.

To add a new property, follow the steps below:

1. Click the step to select it.
2. Right-click in the right side of the Type Palette window and select the Insert Field option from the context menu.
3. Select the data type best suited for your application and insert as many properties as needed.

Sometimes it may be beneficial to create new data types, such as containers, to group common properties together. This will depend entirely on your design. The following figure shows the properties added to the THD step.



Now that you have added the necessary step properties, configure the step behavior and appearance using the following steps:

1. Right-click the step and select Properties from the context menu.
2. In the THD Properties dialog box, select the General tab. On the General tab, specify the Default Step Name Expression and Default Description Expression. It is also a good idea to specify an Icon that provides a visual aid to identify your custom step type.
3. Click the Menu tab to specify the menu item name for your step.

For more information about step types, refer to the Creating and Modifying Custom Step Types section in the TestStand User Manual.

Creating the Test Step

Once you create a step type and implement the code modules, you are ready to assemble and configure the Configurable step type you created so that it calls the appropriate code modules. The Test code module must be the main module of the step, while the Configuration code module must be called from an Edit substep.

1. From the Type Palette window, right-click the step type and select Properties from the context menu. The Step Properties dialog box will appear.
2. Click the Specify Module button on the Step Properties dialog box.
3. On the General tab, enable the Designate an Adapter option and then select the adapter appropriate for the language in which your test module was created – for example, LabVIEW, LabWindows/CVI, DLL, or Active X.
4. Click the Specify Module button and select the test code module you created. Make sure that you pass all the necessary parameters to it. For example, the Sequence Context.

For more information about specifying code modules, refer to the Module Adapters section of the TestStand User Manual.

In general, configurable test steps should not allow the user to specify a code module, because the whole idea is that the step itself performs all the work without any further coding. The recommended approach is to specify which test module to call during the creation of the step type. To prevent the user from calling a different code module than the one the step is designed to work with, you must disable the Specify module menu item. You can do this by enabling the Can Specify Module option on the Disable Properties tab in the Step Properties dialog box.

Now, specify the configuration interface. The Configuration Interface is launched from an Edit substep within the custom step type. With an Edit substep, the user can call a specific code module when right-clicking the step and selecting the appropriate menu entry.

To configure the step substeps, complete the following steps:

1. Click the Substeps tab of the Step Properties dialog box. Because the THD test step inherited from the Numeric Limit Test step, there is a defined Edit substep already. This substep is used to configure the step limits. Because the THD configuration interface already accounts for entering the limits, this Edit substep is no longer needed. You may not encounter this situation if your step inherited from a different step type.
2. Create a new Edit substep by clicking the Add button. Verify that you have selected the adapter that matches the language in which you built your configurator.
3. Under the Substep Info option, enter an expression with the menu item name you want to display. For the THD test step, enter the expression Configure THD Test.
4. Click the Specify Module button and select the configuration module you previously created. Make sure you pass to it all appropriate parameters. When you have finished, close all of the dialog boxes.

The configurable test step is now ready to use.

1. Open a new sequence file and insert your step type.
2. Right-click the step type to configure it.
3. Run the step type using any option from the Execute menu.

An instance of the THD test is shown in the following figure.

Creating a Menu Group for the Customized Step Types

When you have finished creating your configurable test steps, you should group them together in the TestStand menu. This makes your custom step types look native to the environment for everyone to use. To create a menu group for your steps, follow the steps below.

1. Select the Type Palette window and then select your step type.
2. Right-click the step and select Step Type Menu Editor. In the Step Type Menu Editor, you can configure the step palette that appears when the user right-clicks a sequence and selects Insert Step.
3. In the Step Type Menu Editor, click the Add Group button and name the new group Audio Tests.

Now, you can drag and drop your step types into that group. At any time, you can click the Preview Menu button to see the appearance of the menu. The final palette for the Audio Test, that includes several configuration step types is shown in the following figure.

Reader Comments | Submit a comment »