Passing Data to Subsequences Using Parameters in TestStand

In TestStand, subsequences often need input values from the calling sequence to perform their tasks. **Parameters** provide a clear and structured way to pass this data. They define exactly what information a subsequence requires and how data flows between sequences, similar to wiring terminals in a LabVIEW subVI or passing arguments to a C function.

This article explains how to create and use parameters in subsequences, how TestStand handles data passing, and how parameters can be automatically generated or derived from prototypes.

Understanding Sequence Parameters

Each sequence can define its own set of parameters, which act as the inputs and outputs for subsequence calls. When a sequence is called, the caller must provide values (or references) for these parameters. You can also assign default values, which the caller may override.

For more information, refer to the Sequence Parameters section of the TestStand Help.

To illustrate the concept, let’s look at the Computer Motherboard Test Sequence (LabVIEW)—a classic demonstration sequence shipped with TestStand that many users are already familiar with. This makes it easy to follow along or reproduce the steps on your own system. The same approach applies if you created your sequence from scratch. For more information on creating sequences and subsequences, refer to the KB Creating Test Sequences in TestStand.

In this example, the MainSequence passes the value of the boolean variable Locals.CPUFail to the CPUTest subsequence using its CPUFail parameter.

The CPUTest subsequence then uses this value to configure a test step.

Here, you can see how data flows from the MainSequence to a specific test step within a subsequence.

Creating Parameters Manually

To create parameters in a subsequence:

1. Open the subsequence.
2. In the Variables pane, right‑click under Parameters.
3. Choose Insert Parameter.
4. Select a data type and name the parameter.

TestStand highlights this location with a “<Right click to insert Parameter>” hint.

The screenshot below demonstrates the creation of a string parameter named ComponentID in the CPUTest subsequence.

Updating Existing Sequence Calls After Adding Parameters

If you add a new parameter to a subsequence that is already being called elsewhere, TestStand flags the mismatch:

• The Sequence parameter in the Sequence Call step shows a red exclamation mark.
• Hovering over the icon displays a message indicating the parameter list is out of sync.

To fix it, click the red icon. TestStand updates the call and displays the new parameter, ready for configuration.

Parameters vs. File Globals

When passing data between sequences, Parameters are the recommended mechanism. They make subsequences self‑contained, reusable, and easy to understand. For example, a test that needs a measured voltage should receive that value through a parameter so that any caller can provide the appropriate measurement.

Using File Globals for this purpose can make subsequences depend on shared state, reducing portability and making debugging more difficult. For instance, if the voltage were stored in a File Global and read directly by the subsequence, that subsequence would only work in sequence files that define that specific variable.

As a best practice, choose the narrowest necessary scope:

1. Locals for internal data.
2. Parameters for caller–callee data exchange.
3. File Globals only when data must be shared broadly within a sequence file.

This approach leads to cleaner, more maintainable TestStand architectures.