100% found this document useful (1 vote)

1K views322 pages

Teststand User Manual Teststand Example Programs 2024-03!21!12!44!25

Uploaded by

Ana cristina Uribe chairez

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

100% found this document useful (1 vote)

1K views322 pages

Teststand User Manual Teststand Example Programs 2024-03!21!12!44!25

Uploaded by

Ana cristina Uribe chairez

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 322

TestStand

User Manual

2024-03-21
TestStand User Manual

Contents
TestStand Example Programs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Examples for Built-In Step Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Database Step Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Flow Control Step Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
IVI Step Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Message Popup Step Type - Automatically Dismissing. . . . . . . . . . . . . . . . . . . . . 16
Message Popup Step Type - Get User Input. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Multiple Numeric Limit Test Step Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Multiple Numeric Limit Test Step Type - LabWindows/CVI. . . . . . . . . . . . . 20
Multiple Numeric Limit Test Step Type - LabVIEW. . . . . . . . . . . . . . . . . . . . . 22
Multiple Numeric Limit Test Step Type - LabVIEW NXG. . . . . . . . . . . . . . . . 24
Multiple Numeric Limit Test Step Type - .NET. . . . . . . . . . . . . . . . . . . . . . . . 27
Property Loader Step Type - Loading Limits from a Database. . . . . . . . . . . . . . . 29
Property Loader Step Type - Loading Limits from a File Containing Alias. . . . . 31
Property Loader Step Type - Loading Limits from a Microsoft Excel File. . . . . . 32
Property Loader Step Type - Loading Limits for Multiple Sequences. . . . . . . . . 34
Property Loader Step Type - Loading Limits from Multiple Sources. . . . . . . . . . 35
Property Loader Step Type - Loading Limits from Two Different Text Files. . . . 37
Statement Step Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Synchronization Step Types - Auto Schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Synchronization Step Types - Batch Synchronization. . . . . . . . . . . . . . . . . . . . . . 42
Synchronization Step Types - Lock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Synchronization Step Types - Notification and Wait. . . . . . . . . . . . . . . . . . . . . . . 46
Synchronization Step Types - Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Synchronization Step Types - Rendezvous and Semaphore. . . . . . . . . . . . . . . . 50
Examples for Custom Step Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Agilent VEE Step Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
ATLAS Step Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Edit ATLAS Call Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Error Codes and Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Java Step Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Edit Java Call Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Error Codes and Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

2 ni.com
TestStand User Manual

Examples for Customizing Result Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Adding Custom Data to a Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Adding Custom Images to a Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Displaying Graphs in a Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Including Hyperlinks in a Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Including Hyperlinks in a Report - TDMS File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Model Plug-in - Basic Step Time Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Model Plug-in - Simple Text Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Examples for Demos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Computer Motherboard Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Computer Motherboard Test Sequence - HTBasic. . . . . . . . . . . . . . . . . . . . 92
Computer Motherboard Test Sequence - LabWindows/CVI. . . . . . . . . . . . 94
Computer Motherboard Test Sequence - LabVIEW. . . . . . . . . . . . . . . . . . . . 97
Computer Motherboard Test Sequence - LabVIEW NXG. . . . . . . . . . . . . . . 99
Computer Motherboard Test Sequence - .NET. . . . . . . . . . . . . . . . . . . . . . 101
Computer Motherboard Test Sequence - Python. . . . . . . . . . . . . . . . . . . . 103
Mobile Device Test Demo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Parallel Test Strategies Demo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Examples for Fundamentals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Calling Dynamic Dispatch VIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Developing Platform Independent Test Systems. . . . . . . . . . . . . . . . . . . . . . . . . 111
Launching a Modal Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Launching a Modal Dialog - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Launching a Modal Dialog - LabVIEW NXG. . . . . . . . . . . . . . . . . . . . . . . . . . 114
Launching a Modal Dialog - MFC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Launching a Modal Dialog - .NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Launching an MFC Dialog with ActiveX Controls. . . . . . . . . . . . . . . . . . . . . . . . . . 118
Overriding Engine Callbacks - SequenceFilePostStepFailure. . . . . . . . . . . . . . 119
Overriding Engine Callbacks - SequenceFilePostStepRuntimeError. . . . . . . . 121
Passing Clusters to Code Modules - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Passing Structs to Code Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Passing Structs to Code Modules - C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Passing Structs to Code Modules - LabWindows/CVI. . . . . . . . . . . . . . . . . 129
Passing Structs to Code Modules - LabVIEW DLL. . . . . . . . . . . . . . . . . . . . . 131

Passing Structs to Code Modules - .NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Pausing Executions with Running Code Modules. . . . . . . . . . . . . . . . . . . . . . . . . 136
Pausing Executions with Running Code Modules - LabWindows/CVI. . . 136
Pausing Executions with Running Code Modules - LabVIEW. . . . . . . . . . 138
Pausing Executions with Running Code Modules - .NET. . . . . . . . . . . . . . 139
Interpreter Session Management in Python. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Passing Data between TestStand and Python. . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Sequence File Translators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Structure of TestStand Executions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Termination Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Termination Monitor - LabWindows/CVI. . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Termination Monitor - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Termination Monitor - LabVIEW NXG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Termination Monitor - .NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Using Data Streams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Using Data Streams - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Using Data Streams - .NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Using Sweep Loops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Using Sweep Loops - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Using Sweep Loops - .NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Sweep Loop Strategies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Using TestStand Enumerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Using TestStand Enumerations - CVI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Using TestStand Enumerations - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . 169
Using TestStand Enumerations - .NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Examples for Interfacing with Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Instrument Control Step Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
InstrumentStudio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Measure Efficiency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Measure Quiescent Current. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Interfacing with NI-Hardware drivers using Python Custom step and Python
Adapter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Session Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Session Manager - LabWindows/CVI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

4 ni.com
TestStand User Manual

Session Manager - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Switch Executive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Characterization of a Transistor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Examples for Modifying Process Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Dynamically Set the Client Sequence File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Overriding PreUUT Model Callbacks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Overriding PreUUT and PostUUT Parallel Model Callbacks. . . . . . . . . . . . . . . . 199
Overriding PreUUT and PostUUT Batch Model Callbacks. . . . . . . . . . . . . . . . . . 201
Overriding PreBatch and PostBatch Model Callbacks. . . . . . . . . . . . . . . . . . . . . 203
Examples for Modifying User Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Building a TestStand UI with Native Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Building a TestStand UI with Native Controls - LabWindows/CVI. . . . . . 204
Building a TestStand UI with Native Controls - LabVIEW. . . . . . . . . . . . . . 206
Building a TestStand UI with Native Controls - LabVIEW NXG. . . . . . . . . 208
Building a TestStand UI with Native Controls - .NET. . . . . . . . . . . . . . . . . 209
Connecting UI Controls Demo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Creating a Basic User Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Creating a Basic User Interface - LabWindows/CVI. . . . . . . . . . . . . . . . . . . 213
Creating a Basic User Interface - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . 214
Creating a Basic User Interface - LabVIEW NXG. . . . . . . . . . . . . . . . . . . . . . 216
Creating a Basic User Interface - .NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Handling UI Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Handling UI Messages - LabWindows/CVI. . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Handling UI Messages - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Handling UI Messages - LabVIEW NXG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Handling UI Messages - .NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Updating the Status Bar Using UI Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Updating the Status Bar Using UI Messages - LabWindows/CVI. . . . . . . 229
Updating the Status Bar Using UI Messages - LabVIEW. . . . . . . . . . . . . . . 231
Updating the Status Bar Using UI Messages - LabVIEW NXG. . . . . . . . . . . 233
Updating the Status Bar Using UI Messages - MFC. . . . . . . . . . . . . . . . . . . 235
Updating the Status Bar Using UI Messages - .NET. . . . . . . . . . . . . . . . . . . 237
Examples for Parallel Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Comparing Resource Usage Strategies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Executing Code Modules in Parallel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Executing Sequences in Parallel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Testing UUTs in Parallel - Batch Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Testing UUTs in Parallel - Parallel Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Examples for the TestStand API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Accessing Arrays Using API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Accessing Arrays Using API - HTBasic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Accessing Arrays Using API - LabWindows/CVI. . . . . . . . . . . . . . . . . . . . . . 254
Accessing Arrays Using API - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Accessing Arrays Using API - LabVIEW NXG. . . . . . . . . . . . . . . . . . . . . . . . . . 258
Accessing Arrays Using API - MFC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Accessing Arrays Using API - .NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Accessing Properties Using API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Accessing Properties Using API - LabWindows/CVI. . . . . . . . . . . . . . . . . . . 263
Accessing Properties Using API - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . 265
Accessing Properties Using API - LabVIEW NXG. . . . . . . . . . . . . . . . . . . . . . 267
Accessing Properties Using API - MFC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Accessing Properties Using API - .NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Accessing Properties Using API - TestStand Expressions. . . . . . . . . . . . . . 273
Building a Sequence Using API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Building a Sequence Using API - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . 275
Building a Sequence Using API - .NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Building a Sequence Using API - TestStand Expressions (INI). . . . . . . . . 278
Building a Sequence Using API - TestStand Expressions (XML). . . . . . . . 280
Creating and Deleting Users Using API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Creating New Properties Using API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Creating New Properties Using API - LabWindows/CVI. . . . . . . . . . . . . . . 284
Creating New Properties Using API - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . 286
Creating New Properties Using API - LabVIEW NXG. . . . . . . . . . . . . . . . . . 289
Creating New Properties Using API - .NET. . . . . . . . . . . . . . . . . . . . . . . . . . 291
Creating New Properties Using API - TestStand Expressions. . . . . . . . . . 293
Executing Sequences Using API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Executing Sequences Using API - LabWindows/CVI. . . . . . . . . . . . . . . . . . 296
Executing Sequences Using API - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . 298

6 ni.com
TestStand User Manual

Executing Sequences Using API - LabVIEW NXG. . . . . . . . . . . . . . . . . . . . . 300

Executing Sequences Using API - .NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Executing Sequences Using API - TestStand Expressions. . . . . . . . . . . . . 305
Type Casting API Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Type Casting API Classes - LabWindows/CVI. . . . . . . . . . . . . . . . . . . . . . . . 307
Type Casting API Classes - LabVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Type Casting API Classes - LabVIEW NXG. . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Type Casting API Classes - .NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Type Casting API Classes - TestStand Expressions. . . . . . . . . . . . . . . . . . . 314
Examples for TestStand Debugging Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Benchmarks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Custom Analyzer Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Generating Output Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

TestStand Example Programs

TestStand includes a variety of example programs that you can use to help you learn
key concepts or to serve as a starting point for applications you create.

You can browse the examples in the following ways:

■Open the Examples.tsw workspace file located in the <TestStand

Public>\Examples directory.
■Open an example sequence file from the subdirectories of the <TestStand
Public>\Examples directory.
Related concepts:
■
TestStand Directory Structure
Related information:
■ TestStand Featured Examples

Examples for Built-In Step Types

The Built-In Step Types examples demonstrate how to use the default step types
provided in the TestStand insertion palette. This directory includes the following
example programs.

Database Step Types

Purpose
This example demonstrates how to use the Database step types to delete and create
tables in a database, as well as how to modify the records in the database.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Database Step Types\Database
Step Types.seq

8 ni.com
TestStand User Manual

Highlighted Features
Database step types

Major API
None

Prerequisites
(32-bit TestStand) You must have the Microsoft Jet 4.0 Object Linking and
Embedding Database (OLE DB) Provider installed. (64-bit TestStand) You must have
the Microsoft Access Database Engine 2010 Redistributable installed. Visit ni.com/
info and enter the Info Code 64TSaccdb to access the NI support article, Using
Microsoft Access Databases with 64-bit TestStand, for more information about
installing this provider.

How to Use This Example

Complete the following steps to use this example.
1. Review the following steps in the MainSequence:
a. The Find Access MDB File step, which is a Statement step, attempts to
locate the Microsoft Access database file (.mdb) and store its path in the
MDBFilePath local variable.
b. The Open Database step opens the database for use in TestStand,
returns a handle, and stores the handle in the DatabaseHandle local
variable.
c. The Drop Table step, which is an Open SQL Statement step, drops the
TEST_TABLE database table, if it exists.
d. The Create Table step, which is an Open SQL Statement step, creates the
TEST_TABLE table.
e. The Open SQL Statement step selects all columns in the TEST_TABLE
table.

f. The SQL Action - Set Values step, which is a Data Operation step, adds
data to the TEST_TABLE table and loops 10 times because the Goto step
that follows the SQL Action - Set Values step targets the Start Loop step,
which is a Label step, and specifies a post action and precondition that
starts and stops the loop.
g. The Start Loop 2 step starts a second loop that uses Data Operation
steps to obtain the values and strings written to the TEST_TABLE table.
h. The Cleanup step group contains Close SQL Statement and Close
Database steps.
2. Select Execute»Single Pass to run the sequence.
3. When execution completes, select Tools»Database Viewer to launch the
TestStand Database Viewer application.
4. Select File»Open, browse to <TestStand
Public>\Examples\Database\Access.mdb, and click OK.
5. Right-click the TEST_TABLE table and select View Data from the context
menu to display the data contained in the TEST_TABLE table.
Related concepts:
■ Databases and Tables
■ TestStand Directory Structure
■
Step Groups

Flow Control Step Types

Purpose
This example demonstrates using the Flow Control step types to control sequence
flow. These step types include If, Else If, Else, For, For Each, While, Do While, Select,
Case, Break, Continue, and End.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Flow Control Step Types\Flow
Control Step Types.seq

10 ni.com
TestStand User Manual

Highlighted Features
Flow Control step types

Major API
None

Prerequisites
None

How to Use This Example

The example sequence file demonstrates several methods for controlling sequence
flow.

If, Else If, and End

The Prompt for option for If/ElseIf/Else step prompts you to click one of three
buttons, and each launches its own message popup that indicates the button you
clicked. The If step determines whether you clicked the Option A button. If the step
evaluates to True, the sequence executes the steps that immediately follow the If
step. If the step evaluates to False, the sequence continues to the first Else step,
which in this case is an Else If step.
The Else If step behaves the same as the If step and determines whether you clicked
the Option B button. If the step evaluates to True, the sequence continues
executing until it encounters another Else step or encounters an End step. If the Else
If step evaluates to False, the sequence executes the next Else step or continues to
an End step if no additional Else steps exist.
When a sequence encounters an Else step, the sequence always executes all steps
that follow the Else step. You can only use one Else step for each If step, but you can
use multiple Else If steps.

Select and Case

The Prompt for option for Select/Case step prompts you to click one of three
buttons, and each launches its own message popup that indicates the button you
clicked. The Select step determines which button you clicked. Two or more Case
steps always follow a Select step. You can specify multiple values for a single case
using an array, such as {"y","yes"}. All the steps contained in a Case block execute,
depending on the value the Select step evaluates. The End steps specify the end of a
Case block or a Select structure.

For
The For step executes a block of steps multiple times. The For Loop edit tab on the
Step Settings pane specifies that the For step begins with the Locals.index variable
set to 0. The loop continues until the value of the Locals.index variable is greater
than or equal to the value you specify. Each time the For step executes, the
Locals.index variable increments by 1. Therefore, the Beep at done determined by
loop index step in the For block executes the specified number of times and uses the
increasing index.

For Each
The For Each step behaves like the For step but iterates over every element in an
array rather than iterate depending on a specified condition. The
Locals.CurrentMembers variable is an array that specifies three elements, so the
steps in the For Each block execute three times. The current element that the loop is
iterating on is stored in the Locals.CurrentName property. This setting is specified in
the ForEach loop tab of the step settings of the For Each step.

Do While
The Do While step defines a block of steps that always execute at least once. The
DoWhile Loop edit tab on the Step Settings pane specifies an expression that the Do
While step evaluates after all the steps in the Do While block execute. If the
expression evaluates to True, the steps in the Do While block execute again. If the
expression evaluates to False, the sequence continues to the next step.

12 ni.com
TestStand User Manual

While
The While step defines a block of steps that execute when an expression specified
on the While Loop edit tab on the Step Settings pane evaluates to True. If the
expression evaluates to False, the sequence continues to the next step. The While
loop differs from the Do While loop because the While loop evaluates its expression
before each iteration and not after each iteration. Therefore, the steps in the While
block might never execute.

Break and Continue

The Break step terminates a For, For Each, While, or Do While loop or a Case block.
When a sequence encounters a Break step, the sequence exits the block and
continues to the next step.
The Continue step terminates the current iteration of a For, For Each, While, or Do
While loop and prompts the sequence to begin the next iteration of the loop.
In addition to Flow Control step types, you can also use preconditions or post
actions step properties to control sequence flow.
An advantage of using step properties is that the sequence can use fewer steps. In
addition, the flow control logic is attached to the step. For example, if you specify a
precondition of Locals.PowerSupplyOn == True for a step, the precondition remains
attached to the step even if you move or copy the step to a new location. A
disadvantage is that the sequence flow logic is not immediately visible when
viewing the sequence. You can make flow control more visible by using
preconditions on separate Goto steps and using Label steps as branch targets.
However, the functionality you create in this way, such as loops or conditionally-
executed blocks of steps, is embedded in the precondition expressions and branch
targets, and requires anyone who reads the sequence to review the preconditions
and branch targets to understand the flow control.
An advantage of using separate Flow Control steps is that the flow control logic is
visible in the sequence it is expressed in separate steps that identify the flow control
operations the steps perform. In addition, applications typically display the flow
control structures you create with Flow Control steps with indentation and grouping
bars that improve the readability of the sequence. Furthermore, because Flow

Control steps operate on blocks of steps demarcated with separate End steps, you
do not need to specify specific steps as branch destinations, so you can more easily
edit and rearrange steps because you do not need to update branch destinations.
You can use step properties, separate Flow Control steps, or both, depending on
which functionality best suites the requirements of an application.
Related concepts:
■
TestStand Directory Structure

IVI Step Types

Purpose
This example demonstrates how to use IVI step types to configure and take
measurements from IVI instruments with the following logical names: SampleDMM,
SampleScope, SampleFGen, SamplePowerSupply, and SampleSwitch. This example
contains Setup steps that initialize the logical names in simulation mode and
prevent interactive simulation for measurement values. Visit ni.com/ivi for more
information about IVI.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\IVI Step Types\IVI Step Types.seq

Highlighted Features
■ IVI step types
■ NI Session Manager

Major API
None

Prerequisites
Complete the following steps to install the required software and IVI-compliant
instrument drivers.

14 ni.com
TestStand User Manual

1. Install the following additional components from the NI Device Driver DVD
that comes with TestStand:
a. NI Measurement & Automation Explorer (MAX)
b. IVI Compliance Package (ICP)
2. Refer to the Instrument Driver Network at ni.com/idnet to download and
install IVI-compliant instrument drivers for each of the IVI classes this example
uses. Search for the manufacturer or type of instrument you want to
download. Some basic IVI-compliant instrument drivers you can use with this
example include the following:
■ Dmm—hp34401a
■ Scope—tkds30xx
■ Fgen—hp33120a
■ Switch—age1442a
■ PowerSupply—hp66xxbc
In MAX, the driver installer automatically creates a driver session entry under
the Driver Sessions item and populates the software module information
under the Instrument Driver Software Module item in the Advanced
folder.
3. Complete the following steps to create a logical name for each instrument
driver.
a. In MAX, expand the IVI Drivers category to the left.
b. Right-click the Logical Names item in the configuration tree and select
Create New from the context menu.
c. Complete the configuration panel for the new logical name. Logical
names are case-sensitive.

Note Class drivers display simulation dialog boxes if interactive

simulation is enabled. These dialog boxes might not have taskbar items
and can go behind the TestStand Sequence Editor. In addition, the IVI soft
front panels remain visible until you close the Execution window.

How to Use This Example

This example communicates with each type of instrument driver, one after the
other. In each case, the sequence configures the instrument and takes a
measurement. The sequence contains Label steps denote the beginning of steps
that communicate with each type of IVI instrument.
Review the edit tabs on the Step Settings pane for each IVI step to see how the step
configures the instrument and takes measurements.
TestStand stores the logical names the sequence expects as file global variables.
Each variable name must match the logical name created for each driver in MAX.
Related concepts:
■
TestStand Directory Structure
■ Session Manager

Message Popup Step Type - Automatically Dismissing

Purpose
This example demonstrates the following two approaches for creating Message
Popup steps that automatically dismiss after a condition is met:
■ Dismissing the message after a set amount of time
■ Dismissing the message after a set condition is met, such as detecting that a
new UUT has been attached to the test fixture

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Message Popup Step
Type\Message Popup Step Type - Automatically Dismissing.seq

Highlighted Features
■ Message Popup Timeout
■ Creating New Executions

16 ni.com
TestStand User Manual

Major API
Execution.Terminate

Prerequisites
None

How to Use This Example

Complete the following steps to review the sequences and steps in this example:
1. Select the UUT Detected step. In the Step Settings pane, select the Text and
Buttons tab.
2. Observe that Button 1 is specified in the Timeout Button field, and the Time to
wait field is set to three seconds. This setting configures the step to
automatically select Button 1 and dismiss the message box after three
seconds.
3. Select the Prompt for User Action sequence. Observe that this sequence
creates a new execution to launch the dialog. The sequence will dismiss the
dialog by terminating the execution.

Note The Launch Dialog in new Execution step stores a reference to

the new execution in the Locals.messageExecution variable using
the Sequence Call Advanced Settings dialog box.

4. After launching the dialog, the sequence simulates polling for a UUT. In a real
application, this section would typically call a code module which returns
once the condition is met
5. Once the condition is met, the Execution.Terminate method of the TestStand
API terminates the new execution, thereby dismissing the message popup.
Complete the following steps to run the example:
1. Select Execute»Single Pass to run the sequence.
2. Observe that the first message popup dismisses after three seconds.

3. Observe that the second message popup step dismisses once the Check for
UUT condition is met.
Related concepts:
■ TestStand Directory Structure
■
Executions

Message Popup Step Type - Get User Input

Purpose
This example demonstrates how to use Message Popup steps to obtain user input
using the following two methods:
■ Using Buttons
■ Using a Text Field
The example determines what actions to take based on user selections.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Message Popup Step
Type\Message Popup Step Type - Get User Input.seq

Highlighted Features
■ Case steps
■ Error handling
■ Message Popup steps
■ Preconditions
■ Select steps

Major API
None

18 ni.com
TestStand User Manual

Prerequisites
None

How to Use This Example

Complete the following steps to review the steps in the Buttons sequence. This
sequence demonstrates how you can use a message popup step to prompt a user
for input using buttons.
1. Select the Board Test Selection – Buttons step. In the Step Settings pane,
select the Text and Buttons tab.
2. Observe that the button names are specified in the Button 1 through Button 5
fields. The message popup step will display all buttons with specified names.
3. The example uses a Select statement to respond to the user selection. The
Select statement accesses the RunState.Sequence.Main["Board Test Selection
- Buttons"].Result.ButtonHit property to check the button the user chooses.
Complete the following steps to review the steps in the PromptForInput sequence.
This sequence demonstrates how you can use a message popup step to prompt a
user for input using a response text box.
1. Select the Select Board to Test - Text Field step. In the Step Settings pane,
select the Options tab.
2. Observe that the Enable Response Text Box option is enabled. This option
adds a response text box to the message popup to receive user input.
3. The example uses a Select statement to respond to the user selection. The
Select statement uses the expression Val(RunState.Sequence.Main["Select
Board To Test - Text Field"].Result.Response) to check the response the user
enters.
4. If an invalid value is entered, the default case notifies the user of the response.
This step triggers a post action, in which the Select Board To Test - Text Field
step executes again to allow the user to enter a valid response.

Note The Val() expression function converts the text response

string to a number.

Complete the following steps to run the example:

1. Select Execute»Single Pass to run the sequence.
2. When prompted, click a button or enter a value. Notice that the sequence
responds differently based on the input you provide.
Related concepts:
■ TestStand Directory Structure

Multiple Numeric Limit Test Step Type

The <TestStand Public>\Examples\Built-In Step Types\Multiple Numeric Limit Test
Step Type directory contains the following examples.
Related concepts:
■ TestStand Directory Structure
Multiple Numeric Limit Test Step Type - LabWindows/CVI

Purpose
This example demonstrates how to use a Multiple Numeric Limit Test step with a
LabWindows/CVI code module.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Multiple Numeric Limit Test Step
Type\CVI\Multiple Numeric Limit Step Type.seq

Highlighted Features
Multiple Numeric Limit Test steps

20 ni.com
TestStand User Manual

Major API
None

Prerequisites
You must have the LabWindows/CVI Run-Time Engine installed and you must
configure the LabWindows/CVI Adapter to execute steps in-process. If you want to
use the Execute Steps in an External Instance of CVI option, you must have the
LabWindows/CVI development environment installed.

How to Use This Example

This example contains four Multiple Numeric Limit Test steps. The first three steps
obtain four measurement values and compare them to the following high and low
values specified on the Limits tab of the Step Settings pane:

Measurement Comparison Low Value High Value

VOLTAGE 0 GELE (>= <=) 3 5
VOLTAGE 1 GELE (>= <=) 3 5
FREQUENCY GELE (>= <=) 110 125
RMS GELE (>= <=) 0.5 1.0
Each step demonstrates a different way of using the Multiple Numeric Limit Test
step functionality.
■ The first step, Multiple Numeric Limit Test 1, calls a code module that inserts
the measurement values one element at a time into the Step.NumericArray
property. For example, the step inserts the value for the VOLTAGE 0
measurement in Step.NumericArray[0], inserts the value for the VOLTAGE 1
measurement in Step.NumericArray[1], and so on, as shown on the Data
Source tab of the Step Settings pane.
■ The second step, Multiple Numeric Limit Test 2, calls a code module that
writes a single numeric array to the Step.NumericArray property instead of
writing the four array elements individually.

■ The third step, Multiple Numeric Limit Test 3, uses the <None> Adapter and
therefore does not call a code module. The Data Source tab of the Step
Settings pane for this step shows that the step obtains measurement values
from local variables such as Locals.Voltage0, Locals.Voltage1, and so on
instead of from the Step.NumericArray property. The Statement steps in the
Setup step group use expressions to assign these variables.
■ The fourth step, Multiple Numeric Limit Test 4, is similar to the third step,
but demonstrates the new EQ+/- comparison type supported by TestStand
2016 and later. See the table below for more information about this step's
threshold values.

Measurem Compariso Threshold Nominal Lower Upper Computed Computed

ent n Value Threshold Threshold Low Limit High Limit
VOLTAGE 0 EQ (==+/-) Percentage 4 25 25 3 5
VOLTAGE 1 EQ (==+/-) PPM 4 250000 250000 3 5
FREQUENC EQ (==+/-) Delta Value 115 5 10 110 125
Y
RMS EQ (==+/-) Delta Value 0.75 0.25 0.25 0.5 1
For a Multiple Numeric Limit Test step to pass, every test in the step must pass. You
can try changing a limit to cause a test to fail, but ensure that you do not save any
changes to the sequence file before executing the sequence or closing the sequence
file.
Related concepts:
■ TestStand Directory Structure
■ Step Groups
Multiple Numeric Limit Test Step Type - LabVIEW

Purpose
This example demonstrates how to use a Multiple Numeric Limit Test step with a
LabVIEW code module.

22 ni.com
TestStand User Manual

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Multiple Numeric Limit Test Step
Type\LabVIEW\Multiple Numeric Limit Step Type.seq

Highlighted Features
Multiple Numeric Limit Test steps

Major API
None

Prerequisites
You must have the LabVIEW development system installed and you must configure
the LabVIEW Adapter to use the LabVIEW development system.

How to Use This Example

Measurement Comparison Low Value High Value

measurement in Step.NumericArray[1], and so on, as shown on the Data

Source tab of the Step Settings pane.
■ The second step, Multiple Numeric Limit Test 2, calls a code module that
writes a single numeric array to the Step.NumericArray property instead of
writing the four array elements individually.
■ The third step, Multiple Numeric Limit Test 3, uses the <None> Adapter and
therefore does not call a code module. The Data Source tab of the Step
Settings pane for this step shows that the step obtains measurement values
from local variables such as Locals.Voltage0, Locals.Voltage1, and so on
instead of from the Step.NumericArray property. The Statement steps in the
Setup step group use expressions to assign these variables.
■ The fourth step, Multiple Numeric Limit Test 4, is similar to the third step,
but demonstrates the new EQ+/- comparison type supported by TestStand
2016 and later. See the table below for more information about this step's
threshold values.

Measurem Compariso Threshold Nominal Lower Upper Computed Computed

24 ni.com
TestStand User Manual

Purpose
This example demonstrates how to use a Multiple Numeric Limit Test step with a
LabVIEW NXG code module.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Multiple Numeric Limit Test Step
Type\LabVIEW NXG\Multiple Numeric Limit Step Type.seq

Highlighted Features
Multiple Numeric Limit Test steps

Major API
None

Prerequisites
You must have the LabVIEW NXG development system installed and you must
configure the LabVIEW NXG Adapter to use the LabVIEW NXG development system.

How to Use This Example

Measurement Comparison Low Value High Value

VOLTAGE 0 GELE (>= <=) 3 5
VOLTAGE 1 GELE (>= <=) 3 5
FREQUENCY GELE (>= <=) 110 125
RMS GELE (>= <=) 0.5 1.0

Each step demonstrates a different way of using the Multiple Numeric Limit Test
step functionality.
■ The first step, Multiple Numeric Limit Test 1, calls a code module that inserts
the measurement values one element at a time into the Step.NumericArray
property. For example, the step inserts the value for the VOLTAGE 0
measurement in Step.NumericArray[0], inserts the value for the VOLTAGE 1
measurement in Step.NumericArray[1], and so on, as shown on the Data
Source tab of the Step Settings pane.
■ The second step, Multiple Numeric Limit Test 2, calls a code module that
writes a single numeric array to the Step.NumericArray property instead of
writing the four array elements individually.
■ The third step, Multiple Numeric Limit Test 3, uses the <None> Adapter and
therefore does not call a code module. The Data Source tab of the Step
Settings pane for this step shows that the step obtains measurement values
from local variables such as Locals.Voltage0, Locals.Voltage1, and so on
instead of from the Step.NumericArray property. The Statement steps in the
Setup step group use expressions to assign these variables.
■ The fourth step, Multiple Numeric Limit Test 4, is similar to the third step,
but demonstrates the EQ+/- comparison type supported by TestStand 2016
and later. See the table below for more information about this step's
threshold values.

Measurem Compariso Threshold Nominal Lower Upper Computed Computed

26 ni.com
TestStand User Manual

■ TestStand Directory Structure

■ Step Groups
Multiple Numeric Limit Test Step Type - .NET

Purpose
This example demonstrates how to use a Multiple Numeric Limit Test step with
a .NET assembly code module.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Multiple Numeric Limit Test Step
Type\DotNET\Multiple Numeric Limit Step Type.seq

Highlighted Features
Multiple Numeric Limit Test steps

Major API
None

Prerequisites
None

How to Use This Example

Measurement Comparison Low Value High Value

VOLTAGE 0 GELE (>= <=) 3 5
VOLTAGE 1 GELE (>= <=) 3 5
FREQUENCY GELE (>= <=) 110 125

Measurement Comparison Low Value High Value

RMS GELE (>= <=) 0.5 1.0
Each step demonstrates a different way of using the Multiple Numeric Limit Test
step functionality.
■ The first step, Multiple Numeric Limit Test 1, calls a code module that inserts
the measurement values one element at a time into the Step.NumericArray
property. For example, the step inserts the value for the VOLTAGE 0
measurement in Step.NumericArray[0], inserts the value for the VOLTAGE 1
measurement in Step.NumericArray[1], and so on, as shown on the Data
Source tab of the Step Settings pane.
■ The second step, Multiple Numeric Limit Test 2, calls a code module that
writes a single numeric array to the Step.NumericArray property instead of
writing the four array elements individually.
■ The third step, Multiple Numeric Limit Test 3, uses the <None> Adapter and
therefore does not call a code module. The Data Source tab of the Step
Settings pane for this step shows that the step obtains measurement values
from local variables such as Locals.Voltage0, Locals.Voltage1, and so on
instead of from the Step.NumericArray property. The Statement steps in the
Setup step group use expressions to assign these variables.
■ The fourth step, Multiple Numeric Limit Test 4, is similar to the third step,
but demonstrates the new EQ+/- comparison type supported by TestStand
2016 and later. See the table below for more information about this step's
threshold values.

Measurem Compariso Threshold Nominal Lower Upper Computed Computed

28 ni.com
TestStand User Manual

changes to the sequence file before executing the sequence or closing the sequence
file.
Related concepts:
■ TestStand Directory Structure
■
Step Groups

Property Loader Step Type - Loading Limits from a Database

Purpose
This example demonstrates how to use the Property Loader step type to load step
properties, such as limits for Numeric Limit Test steps, from a database.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Property Loader Step
Type\Property Loader - Loading Limits From a Database.seq

Highlighted Features
■ Database step types
■ Database Viewer Application
■ Property Loader steps

Major API
None

Prerequisites
TestStand loads the property values from the Access.mdb file located in the same
directory as the sequence file. (32-bit TestStand) You must have the Microsoft Jet 4.0
Object Linking and Embedding Database (OLE DB) Provider installed. (64-bit
TestStand) You must have the Microsoft Access Database Engine 2010
Redistributable installed. Visit ni.com/info and enter the Info Code 64TSaccdb to

access the NI support article, Using Microsoft Access Databases with 64-bit
TestStand, for more information about installing this provider.

How to Use This Example

This example uses a Property Loader step to load property values, including local
variable values and step limits, from a Microsoft Access database file. The Property
Loader step applies these values to the sequence before the test steps execute,
which demonstrates how the limits and variables can be loaded each time a
sequence executes.
Complete the following steps to review the Property Loader step settings.
1. On the Steps pane, select the Property Loader step in the Setup step group.
2. On the Step Settings tab of the Steps pane, review the items in the sources
table. In this table, the database is configured as the properties source.
3. On the Target File and Source Settings tab, review the properties selected in
the Property Tree control. The step loads the Comp, Limits.Low, and
Limits.High values for each step specified, as well as a local and file global
variable.
Complete the following steps to run this example.
1. Select Execute»Single Pass to run the sequence.
2. When execution completes, review the report on the Report pane. The report
indicates that the Video step failed because the test result of 65 was not within
the acceptable limits.
3. Complete the following steps to edit the database to include an acceptable
value.
a. Select Tools»Database Viewer to launch the TestStand Database
Viewer application.
b. Select File»Open, browse to <TestStand Public>\Examples\Built-In
Step Types\Property Loader Step Type\Access.mdb, and click OK.
c. Right-click the STEP_PROPERTIES table in the Database Explorer pane
and select View Data.
d. Right-click the table and select Edit Data.

30 ni.com
TestStand User Manual

e. Change the value of the LIMITS_LOW field for the video record from 71
to 60. Click the Submit button to submit the values to the database.
f. Close the Database Viewer application.
4. Select Execute»Single Pass to run the sequence again.
5. When execution completes, review the report on the Report pane. The report
indicates that the Video step passed because the test result is now within the
acceptable limits.
Related concepts:
■ TestStand Directory Structure
■ Step Groups

Property Loader Step Type - Loading Limits from a File

Containing Alias
Purpose
This example demonstrates using the Property Loader step type to load the
properties from a source containing alias names instead of property lookup strings.
These aliases and corresponding properties are defined in a separate .pla file. The
example loads properties at the beginning of the MainSequence.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Property Loader Step Type\
Property Loader - Loading Limits From File Containing Alias.seq

Highlighted Features
■ Property Loader steps
■ ReportOptions callback

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to review the sequence functionality.
1. On the Steps pane, select the Property Loader step in the Setup step group.
2. On the Target File and Source Settings tab, observe that the file
AliasNames.pla is specified for the Alias Location field. This file specifies alias
names for various properties, making it easier to identify them in a limits file.
Open the file in a text editor to review the contents.
3. On the Step Settings tab in the Step Settings pane, click the View Source File
button in the sources table to open the properties file. Observe that the
properties in the file are specified using the aliases defined in the alias file.
Complete the following steps to run this example.
1. Select Execute»Single Pass to run the sequence.
2. When execution completes, review the report on the Report pane. Ensure that
the limits were changed based on the property loader step configuration.
Related concepts:
■ TestStand Directory Structure

Property Loader Step Type - Loading Limits from a Microsoft Excel

File
Purpose
This example demonstrates how to use a Property Loader step type to load limits
from a Microsoft Excel spreadsheet file. This example uses the LabWindows/CVI
Adapter for Numeric Limit Test steps.

32 ni.com
TestStand User Manual

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Property Loader Step
Type\Property Loader - Loading Limits From Excel.seq

Highlighted Features
■ Property Loader steps
■ ReportOptions callback

Major API
None

Prerequisites
You must have Microsoft Excel installed.

How to Use This Example

The Property Loader step starts reading data from the START LIMITS marker and
reads data until it encounters the END LIMITS marker.
Complete the following steps to review the sequence functionality.
1. On the Steps pane, select the Property Loader step in the Setup step group.
2. On Target File and Source Settings tab in the step settings pane, review the
properties selected in the Property Tree control. The step loads the Limits.Low
and Limits.High values for each step.
3. On the Step Settings tab of the Steps pane, click the View File button in the
sources table to open <TestStand Public>\Examples\Built-In Step
Types\Property Loader Step Type\Limits.xls in Excel. The columns in the Excel
file specify the properties to import, and the rows specify the names of the
steps in the sequence.
Complete the following steps to run this example.
1. Select Execute»Single Pass to run the sequence.

2. When execution completes, review the report on the Report pane. The report
indicates that TestStand updated the limits of the steps based on the values in
the Excel file.
3. In the Limits.xls file, change the Flow Rate value from 1 to 1.1 and save the file.
4. Select Execute»Single Pass to run the sequence again.
5. When execution completes, review the report on the Report pane. The report
indicates that the results have changed because of the updated step limits.
Related concepts:
■ Programming with the TestStand API in LabWindows/CVI
■
TestStand Directory Structure
■ Step Groups

Property Loader Step Type - Loading Limits for Multiple

Sequences
Purpose
This example demonstrates using the Property Loader step type to load the
properties for multiple sequences in a client sequence file. The example loads
properties at the beginning of the MainSequence.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Property Loader Step
Type\Property Loader - Loading Limits For Multiple Sequences.seq

Highlighted Features
Property Loader steps

Major API
None

34 ni.com
TestStand User Manual

Prerequisites
None

How to Use This Example

Complete the following steps to change properties that already exist in a sequence.
1. Select the MainSequence.
2. On the Steps pane, select the Property Loader step.
3. On the Step Settings pane, click the Step Settings tab. Click the View File
button in the sources table to open propertyData.txt, which is located in the
same directory as the example sequence file and is the file the Property
Loader step is using to specify property values. The text file specifies a data
block for each sequence in the sequence file so the step can load different
values for the same property in different sequences. The Start and End of Data
markers for the data block include the name of the sequence. In the text file,
the Properties for Sequence 1 section specifies the limits for the Numeric
Limit Test step as 15 for Limits.Low and 20 for Limits.High. The text file
contains very specific formatting to which you must adhere for the Property
Loader step to function correctly. The best method for generating a file for use
with a Property Loader step is to specify the properties in the sequence file
and then select Tools»Import/Export Properties to launch the Import/
Export Properties dialog box, in which you can generate a file that a Property
Loader step can use.
4. Select Execute»Single Pass to run the sequence.
5. When execution completes, review the report on the Report pane. Notice that
the limit values in each subsequence have changed to the values specified by
the property file.
Related concepts:
■ TestStand Directory Structure

Property Loader Step Type - Loading Limits from Multiple

Sources

Purpose
This example demonstrates using the Property Loader step type to load data from
multiple property loader sources. The example loads properties from GenericLimits
to load limits for Voltage and Temperature and loads properties from
SpeacializedLimits to override the limits for Voltage.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Property Loader Step Type\
Property Loader - Loading Limits From Multiple Sources.seq

Highlighted Features
■ Property Loader steps
■ ReportOptions callback

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to review the sequence functionality.
1. On the Steps pane, select the Property Loader step in the Setup step group.
2. On the Step Settings tab in the Step Settings pane, observe that two source
locations are specified in the source table. This indicates that properties will
be loaded from multiple sources, in this case two text files.
3. Navigate to the <TestStand Public>\Examples\Built-In Step Types\Property
Loader Step Type directory and review the GenericLimits.txt and
SpecializedLimits.txt files. Observe that both files have properties defined for

36 ni.com
TestStand User Manual

the voltage test. In this case, the file specified last in the source table will take
precedence.
Complete the following steps to run this example.
1. Select Execute»Single Pass to run the sequence.
2. When execution completes, review the report on the Report pane. Ensure that
the limits were changed based on the property loader step configuration.
Related concepts:
■ TestStand Directory Structure

Property Loader Step Type - Loading Limits from Two Different

Text Files
Purpose
This example demonstrates how to use the Property Loader step to dynamically
load step limits from different text files depending on user input.
In the Setup step group of the MainSequence, the Message Popup step launches a
dialog box to prompt the user to choose which file TestStand uses to load limits
values. The Select Limit File Statement step in the Setup step group selects the limit
file. The expression for this step uses a conditional operation in which TestStand
loads limits from RevisionALimits.txt when the value of the Result.ButtonHit
property equals 1. The expression specifies that TestStand loads limits from
RevisionBLimits.txt for all other cases.
When you write a sequence in which the user must choose between three or more
limit files, use a Property Loader step for each limit file and use a precondition for
each step that checks for user input. For example, when the Message Popup step
specifies four buttons, each Property Loader step can check which button was
clicked in the precondition.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Property Loader Step
Type\Property Loader - Loading Limits From Different Files.seq

Highlighted Features
■ Property Loader steps
■ ReportOptions callback

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to review the sequence functionality.
1. On the Steps pane, select the Property Loader step in the Setup step group.
2. On the Step Settings tab of the Step Settings pane, confirm that the source
location in the sources table specifies the Locals.LimitFileToLoad variable. The
value of this variable at run time determines which file TestStand loads.
3. Navigate to the <TestStand Public>\Examples\Built-In Step Types\Property
Loader Step Type directory and review the RevisionALimits.txt and
RevisionBLimits.txt files. Each file specifies a different set of limit values for
the sequence.
4. On the Steps pane, select the Select Limit File step, which is an instance of a
Statement step type. This step sets the Locals.LimitFileToLoad variable to the
correct value depending on which file the user selects.
Complete the following steps to run this example.
1. Select Execute»Single Pass to run the sequence.
2. When prompted, select the Revision A Limits option.
3. When execution completes, review the report on the Report pane. The report
indicates that all steps passed.
4. Select Execute»Single Pass to run the sequence again.

38 ni.com
TestStand User Manual

5. When prompted, select the Revision B Limits option.

6. When execution completes, review the report on the Report pane. The report
indicates that not all steps passed because of the different set of limit values.
The step results have not changed.
Related concepts:
■
Step Groups
■ TestStand Directory Structure

Statement Step Type

Purpose
This example demonstrates how to use an expression in a Statement step to
dynamically change the high and low limits of a Numeric Limit Test step.

Note NI typically recommends that you use expressions when you

configure a Numeric Limit Test step or to use a Property Loader step to
change limits, but this example demonstrates how to change step
properties.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Statement Step Type\Statement
Step Type.seq

Highlighted Features
Expressions

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to use this example.
1. On the Steps pane, select the Numeric Limit Test step.
2. On the Step Settings pane, click the Limits tab. The comparison type for the
step is currently GELE (>= <=), with a high value of 10 and a low value of 0.
When accessed from the Numeric Limit Test step, the numeric limits for the
Numeric Limit Test step are Step.Limit.High and Step.Limit.Low. However,
another step cannot access the variables Step.Limit.High and Step.Limit.Low,
as shown in this example. Instead, you must explicitly specify the step that
specifies the properties you want to access.
3. On the Steps pane, select the A Statement that changes the numeric
limits step, which is a Statement step.
4. On the Step Settings pane, click the Expression edit tab. The Expression tab
contains two expressions, separated by a comma, that specify the high limit
as 11 and the low limit as 0: RunState.Sequence.Main["Numeric Limit
Test"].Limits.High = 11, RunState.Sequence.Main["Numeric Limit
Test"].Limits.Low = 0The expressions specify that you want to use the Numeric
Limit Test step to specify the properties you want to access. Alternatively, you
could use the following expression: 'RunState.NextStep.Limits.High'
5. Select Execute»Single Pass to run the sequence.
6. When the execution completes, review the report. For the Numeric Limit Test
step, the High Limit value is 11, and the Low Limit value is 0.
Because the Statement step executed before the Numeric Limit Test step in the
sequence, changing the limits after the Numeric Limit Test executes does not
change the limit values.
Related concepts:
■ TestStand Directory Structure
■ Expressions

Synchronization Step Types - Auto Schedule

40 ni.com
TestStand User Manual

Purpose
This example demonstrates the Auto Schedule and Use Auto Scheduled Resource
step types. These step types are used to dynamically determine the order in which a
UUT uses its required resources to minimize delays that occur while the UUT waits
for a resource to become available.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Synchronization Step
Types\Synchronization Step Types - Auto Schedule.seq

Highlighted Features
■ Auto Schedule step type
■ Use Auto Scheduled Resource step type
■ Batch process model

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to review the sequences and steps in the example.
1. On the Sequences pane, select the MainSequence. The Auto Schedule step
at the beginning of the test defines a block of Use Auto Scheduled Resource
sub-blocks. When the test sequence executes, each test socket executes each
Use Auto Scheduled Resource sub-block once. The order in which the sub-
blocks execute can vary between test sockets to improve execution time.
2. Select one of the Use Auto Scheduled Resource steps and navigate to the Auto
Scheduled Resource Settings Edit Tab on the Step Settings pane. Notice that

at least one resource name is defined in the Resource Lock Alternatives list.
The UUT does not execute the test steps in this Use Auto Scheduled Resource
sub-block until it has exclusive access to the resources in this list.
3. Select each of the Use Auto Scheduled Resource steps to compare the settings
for the Resource Lock Alternatives. You can specify multiple resource lock
alternatives to indicate that the sub-block can execute if any of the
alternatives are available. To lock access to all of these resources before
executing the sub-block, use an array of lock names to specify that a section
must lock multiple resources. In this case, no locks are reserved unless all
resources are available.
Complete the following steps to run the example.
1. Select Execute»Single Pass to run the sequence.
2. A prompt appears that describes the Resource Usage Profiler, which is a tool
to monitor the status of synchronization objects in a test sequence. You can
use this tool to observe the execution order of test steps in a test sequence
with Auto Schedule steps. You can choose to launch the tool to view
additional details during the test.
3. As the test sequence executes, dialog boxes indicate the current status of the
tests. Notice that each UUT is only able to execute a Use Auto Scheduled
Resource sub-block if it is able to gain exclusive access to the required
resources.
4. Once execution completes, you can examine the test report for each UUT to
notice the order of execution. The Auto Schedule steps do not guarantee a
specific execution order for each test step. The order can vary among test
sockets and among executions. You can run the test sequence additional
times to compare the execution order among different test runs.
Related concepts:
■ TestStand Directory Structure
■ Batch Process Model

Synchronization Step Types - Batch Synchronization

42 ni.com
TestStand User Manual

Purpose
This example demonstrates the Batch Synchronization step types and step settings
available when you use the Batch process model. Use Batch synchronization to
coordinate test operations among all test sockets in a batch and and to execute test
steps selectively, concurrently, or sequentially.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Synchronization Step
Types\Synchronization Step Types - Batch Synchronization.seq

Highlighted Features
■ Batch Synchronization step type
■ Batch Synchronization step settings
■ Batch process model

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to review the sequences and steps in the example.
1. On the Sequences pane, select the MainSequence. The MainSequence
contains four Sequence Call steps that correspond to the different approaches
demonstrated in this example. When executed, the Batch process model
executes four instances of this sequence, referred to as sockets 0 through 3.
2. On the Sequences pane, select the Voltage Tests sequence. This sequence
uses the Batch Synchronization step settings to synchronize execution of
individual steps. Observe that the two Apply Voltage Stimulus steps enable

the One thread only option on the Synchronization pane of the step
settings, indicating that only a single test socket execute these steps during
execution. The two Voltage Response steps enable the Parallel option on the
Synchronization pane of the step settings, indicating that all test sockets
execute these steps concurrently.
3. On the Sequences pane, select the Temperature Tests sequence. This
sequence uses the Batch Synchronization step type to define a block of steps
that execute serially, meaning that only one socket executes each test at a
time but that all sockets execute both test steps. Execution does not continue
beyond the Batch Synchronization block until all sockets have completed the
block.
4. On the Sequences pane, select the Stress Tests sequence. This sequence
uses the Batch Synchronization step type to define blocks of steps that
execute in parallel. For each block, all test sockets concurrently execute the
test steps. Execution does not continue beyond the block until all sockets
have completed all test steps within the block.
5. On the Sequences pane, select the Current Tests sequence. The steps in this
sequence do not have any Batch Synchronization settings applied, meaning
that each test socket executes these steps as soon as the execution reaches
this sequence. It is not necessary to specify Batch Synchronization settings for
every step in a sequence file using the Batch process model.
Complete the following steps to run the example.
1. Select Execute»Single Pass to run the sequence.
2. As the test sequence executes, dialog boxes indicate the current status of the
tests. Notice that the tests execute concurrently, serially, or only on a single
socket according to the Batch Synchronization settings for each step.
Related concepts:
■ Batch Process Model
■ TestStand Directory Structure

Synchronization Step Types - Lock

44 ni.com
TestStand User Manual

Purpose
This example demonstrates how to use the Lock synchronization step to restrict
execution flow in a sequence file that uses the Batch process model. When a lock is
active, only one thread at a time can access the steps the lock contains.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Synchronization Step
Types\Synchronization Step Types - Lock.seq

Highlighted Features
■ Batch process model
■ Lock step type

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to review the sequence functionality.
1. Select Edit»Sequence File Properties to launch the Sequence File
Properties dialog box. On the Advanced tab, the Model File control specifies
the Batch process model, which will run the test sequence in multiple parallel
executions (test sockets).
2. On the Sequences pane, select the MainSequence.
3. Review the steps in the MainSequence. The steps specify the following
behaviors:

■ The sequence uses Lock steps to ensure that only one test socket is
executing the single-threaded steps at a given time, which is useful in cases
where the step requires a shared resource, such as an instrument, that only
one step at a time can use.
■ In section one, the sequence first creates and then performs the lock
operation in the Create and Lock "Lock 1" step. Once one test socket calls
the Lock "Lock 1" step, all other test sockets wait at the step until the
original socket releases the lock in the Unlock "Lock 1" step.
■ In section three, for the Single-threaded Test 5 step, notice that the
Synchronization panel of the Properties tab of the Step Settings pane
contains a Use Lock to Allow Only One Thread at a Time to Execute
the Step option, which is enabled. This option applies a lock for the step
without the need for lock steps.
■ In section four, the Create Lock step stores the lock reference in a local
variable. The lock operation uses this variable to identify the lock, and
stores a reference to the lock operation in a second variable.
Complete the following steps to run this example.
1. Select the Execute menu and confirm that a checkmark appears next to the
Tracing Enabled option.
2. Select Execute»Single Pass to run the sequence. TestStand creates three
test sockets, and each test socket executes the MainSequence. The multi-
threaded steps execute simultaneously across all test sockets. Observe that
the locked code runs only on a single socket at any given time.
Related concepts:
■ Batch Process Model
■ TestStand Directory Structure

Synchronization Step Types - Notification and Wait

Purpose
This example demonstrates how to use the Notification and Wait synchronization
steps in a sequence file to specify that one test socket waits to receive a notification

46 ni.com
TestStand User Manual

from another step before continuing the execution. A Notification step can send
messages between multiple test sockets and can optionally contain data.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Synchronization Step
Types\Synchronization Step Types - Notification & Wait.seq

Highlighted Features
■ Notification step type
■ Wait step type

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to review the sequence functionality.
1. On the Sequences pane, select the MainSequence.
2. Complete the following steps to review the steps in the MainSequence.
a. Select the Notification step. On the Notification Settings edit tab,
notice that the Create operation is selected. This step creates a new
notification and names it "Event 1".
b. Select the Wait for Notification step. On the Notification Settings edit
tab, notice that the Wait operation is selected. This step waits until
TestStand calls the Set operation on the "Stimulus Started" notification
from the "Start Stimulus" execution. On the Preconditions panel of the
Properties tab of the Step Settings pane, the Precondition Expression

control contains an expression that ensures that only Test Socket 1

waits for the notification. The other test socket skips this step.
c. Open the Start Stimulus sequence. Select the Initialize Stimulus step.
The Wait Settings edit tab specifies that the Wait step introduces a 2-
second delay in the sequence to simulate starting the stimulus.
d. Select the Set "Stimulus Starting" Notification step. On the
Notification Settings edit tab, notice that the Set operation is selected.
This step sends the notification. If another thread is waiting for the
notification, that thread may now continue execution.
Complete the following steps to run this example.
1. Select Execute»Single Pass to run the sequence.
2. Notice that the main execution waits for the initialization to complete before
entering the Main step group.
3. 2.3. Notice that the Wait for "Stimulus Started" Notification step does not
complete until the “Start Stimulus” sequence sets the notification indicating
that the stimulus has started.
Related concepts:
■ TestStand Directory Structure

Synchronization Step Types - Queue

Purpose
This example demonstrates how to use the Queue synchronization step in a
sequence file that uses the Batch process model. You can use a Queue step to pass
data between threads or across executions while avoiding race conditions.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Synchronization Step
Types\Synchronization Step Types - Queue.seq

48 ni.com
TestStand User Manual

Highlighted Features
■ Batch process model
■ Queue step type

Major API
None

Prerequisites
None

How to Use This Example

The Queue step is similar to a Notification step in that you can send data between
multiple test sockets. Queue steps can contain multiple data values. This example
demonstrates how to complete the following tasks for a queue:
■ Enqueue—Add an element to a queue.
■ Dequeue—Remove an element from a queue or store the data from the
element.
■ Get Status—Obtain information about the current state of the queue.
■ Flush—Empty the queue and optionally obtain all the elements from the
queue.
Complete the following steps to review the sequence functionality.
1. Select Edit»Sequence File Properties to launch the Sequence File
Properties dialog box.
2. On the Sequences pane, select the MainSequence.
3. Complete the following steps to review the steps in the MainSequence.
a. In section one, select the Create Queue 1 step. On the Queue Settings
edit tab, notice that the Create operation is selected. This step creates a
new queue named "Queue 1".

b. Select the Enqueue One Element sequence, then select the Enqueue
Data step. On the Queue Settings edit tab, notice that the Enqueue
operation is selected. This step adds a new element, the value of the
Locals.EnqueueData variable, to the queue.
c. Select the Dequeue Data step. On the Queue Settings edit tab, notice
that the Dequeue operation is selected. This step removes an element
from the queue. If the queue is empty, the step waits until data is
available to dequeue, as shown in section two.
d. In section three, select the Get Status step. This step uses the Get
Status operation places the current contents of the queue into the
Locals.QueueStatus variable without modifying the state of the queue.
e. Select the Flush Queue step. On the Queue Settings edit tab, notice
that the Flush operation is selected. This step removes all data from the
queue. TestStand places the data in the location specified in the
Location to Store Array of Queue Elements control. In this case,
TestStand places the data in the Locals.FlushedQueue variable.
Complete the following steps to run this example.
1. Select Execute»Single Pass to run the sequence.
2. Read the text in each section popup message for information about the
behavior of that section.
Related concepts:
■ Batch Process Model
■ TestStand Directory Structure
■ Synchronization Step Types - Notification and Wait

Synchronization Step Types - Rendezvous and Semaphore

Purpose
This example demonstrates how to use the Rendezvous and Semaphore
synchronization steps to control multi-threaded execution flow between threads or
across executions in a sequence file that uses the Batch process model.

50 ni.com
TestStand User Manual

■ A Rendezvous step will make a set number of threads wait until all threads
specified are at the same point and ready to proceed. Unlike batch
synchronization, rendezvous steps can be used to synchronize any TestStand
threads or executions, without requiring the batch process model.
■ A Semaphore step is similar to the Lock step in functionality, except that you
can specify any number of threads instead of just one.

Example File Location

<TestStand Public>\Examples\Built-In Step Types\Synchronization Step
Types\Synchronization Step Types - Rendezvous & Semaphore.seq

Highlighted Features
■ Batch process model
■ Rendezvous step type
■ Semaphore step type

Major API
None

Prerequisites
None

How to Use This Example

This example uses the Rendezvous or Semaphore steps to synchronize four test
sockets in a batch test.
Complete the following steps to review the sequence functionality.
1. Select Edit»Sequence File Properties to launch the Sequence File
Properties dialog box. On the Advanced tab, the Model File control specifies
the Batch process model, which will run the test sequence in multiple parallel
executions (test sockets).

2. On the Sequences pane, select the MainSequence.

3. Complete the following steps to review the steps in the MainSequence.
a. Select the Create Semaphore 1 step. On the Semaphore Settings edit
tab, notice that the Create operation is selected. This step creates a new
semaphore named "Semaphore 1". The Initial Semaphore Count control
specifies a value of 2, which indicates that two test sockets can execute
the semaphore section at any given time. The Acquire Semaphore 1
step and Release Semaphore 1 step represent the start and end of the
semaphore section.
b. Select the Create Rendezvous 1 step. On the Rendezvous Settings
edit tab, notice that the Create operation is selected. This step creates a
new rendezvous named "Rendezvous 1". The Number of Threads per
Rendezvous control specifies a value of 4, which indicates that when
one test socket reaches the Start Rendezvous step, the socket waits for
the other three sockets before continuing execution.
Complete the following steps to run this example.
1. Select Execute»Single Pass to run the sequence. TestStand creates four test
sockets, and each test socket executes the MainSequence. When the
executions reach the Acquire Semaphore 1 step, two test sockets enter the
semaphore section and the remaining two sockets wait. When the first two
test sockets execute the Release Semaphore 1 step, the remaining two test
sockets enter the semaphore section. When the test sockets reach the
Rendezvous step, the test sockets wait until all test sockets reach the step
before execution continues.
Related concepts:
■ Batch Process Model
■ TestStand Directory Structure

Examples for Custom Step Types

The Custom Step Types examples extend TestStand with additional custom step
types to call different types of test code. This directory includes the following
example programs.

52 ni.com
TestStand User Manual

Agilent VEE Step Types

Purpose
This example uses ActiveX to call Agilent VEE code from TestStand using custom step
types, which you can use to execute the user functions of VEE user libraries.

Example File Location

<TestStand Public>\Examples\Custom Step Types\Agilent VEE Step Types\Agilent
VEE Computer Motherboard Test.seq

Highlighted Features
Custom step types

Major API
N/A

Prerequisites
VEE Evaluation, Development, or Run-Time Environment version 6.0 or later.

Note (64-bit TestStand) 64-bit TestStand does not support Agilent VEE
step types.

How to Use This Example

The example sequence file, Agilent VEE Computer Motherboard Test.seq, contains a
SequenceFileLoad callback that TestStand automatically executes when you open
the sequence file and that performs the following necessary actions:
■ Copies the TestStand example file VEE_StepType.dll, which implements the
step type functionality, from the <TestStand Public>\Examples\Custom Step
Types\Agilent VEE Step Types directory to the <TestStand
Public>\Components\StepTypes\Agilent VEE directory and registers the DLL.

Note VEE_StepType.dll was created using Microsoft Visual Basic.

The example directory includes the VEE_StepType.vbp Visual Basic
project file, which you can use to recompile VEE_StepType.dll.

■ Copies the <TestStand Public>\Examples\Custom Step Types\Agilent VEE

Step Types\compMotherBoard.bmp file to the default Bitmaps subdirectory of
the VEE installation directory. The SimulationDialog VEE user function
displays the bitmap on its view panel. When using a bitmap on a VEE view
panel, you can reference the bitmap using an absolute path or you can place
the bitmap in the Bitmaps subdirectory of the VEE installation directory.
When you open <TestStand Public>\Examples\Custom Step Types\Agilent VEE Step
Types\Agilent VEE Computer Motherboard Test.seq in the TestStand Sequence
Editor, the VEE step types appear in the VEE group on the Insertion Palette. You can
make the VEE step types available for any sequence file by copying the VEE step
types from Computer.seq in the Types window to a type palette, such as
MyTypes.ini.
When you insert a VEE step type into a sequence, you must configure the step by
clicking the Specify VEE Module button on the Step Settings pane to launch the
Edit VEE Module dialog box. For the VEE Library to Load control, specify a valid VEE
library. The step automatically populates the VEE Function ring control with user
functions the VEE user library exports. When you select an exported function, the
step automatically populates the input and output arguments of the function. The
VEE step types currently support the following data types and data shapes for
arguments of VEE user functions:
■ Scalar:
■ Signed 32-bit integer
■ 64-bit real number (double)
■ String
■ 1D-Array:
■ Signed 32-bit integer
■ 64-bit real number (double)
■ String

54 ni.com
TestStand User Manual

You can select each input and output argument from the Argument control of the
Input section and the Output section, respectively, and set a corresponding
TestStand property path. The step uses the value of the property as input for input
arguments or receives the output value for output arguments.
The VEE step types also support debugging. You can step into a VEE user function
and use the VEE debug functionality to debug the user function.
This example includes VB_VEE_Action, VB_VEE_NumericLimitTest,
VB_VEE_PassFailTest, and VB_VEE_StringValueTest step types. The
VB_VEE_NumericLimitTest, VB_VEE_PassFailTest, and VB_VEE_StringValueTest step
types combine the functionality of the VB_VEE_Action step with the built-in Numeric
Limit Test, Pass Fail Test, and String Value Test step types, respectively, to call VEE
functions in addition to the functionality of the built-in steps. For example, the
VB_VEE_NumericLimitTest step returns a number from a VEE user function and
compares the number to numeric limits.
Related concepts:
■
TestStand Directory Structure
■
Custom Step Types

ATLAS Step Type

Purpose
This example demonstrates a custom step type for calling an Abbreviated Test
Language for All Systems (ATLAS) test program set (TPS), which is created in the
PAWS Developer Studio. The ATLAS custom step type integrates with the PAWS Run-
Time System (RTS) to execute TPS files (.PAWS). These examples require the TYX
PAWS RTS Server to run the provided test program sets.
The ATLAS custom step type example includes the following example sequence files:
■ A parameter passing example that demonstrates passing parameters
between TestStand and a TPS.
■ A manual intervention example that demonstrates support for handling a
request for manual intervention by the PAWS RTS Server.

Example File Location

<TestStand Public>\Examples\Custom Step Types\ATLAS Step Types\Parameter
Passing Example.seq
<TestStand Public>\Examples\Custom Step Types\ATLAS Step Types\Manual
Intervention Example.seq

Highlighted Features
Custom step types

Major API
N/A

Prerequisites
TYX PAWS RTS 1.22 or later

How to Use This Example

The example sequence files contain a SequenceFileLoad callback that TestStand
automatically executes when you open either sequence file. The SequenceFileLoad
callback copies the ATLAS_StepType.dll file from the <TestStand
Public>\Examples\Custom Step Types\ATLAS Step Types directory to the <TestStand
Public>\Components\StepTypes\ATLAS directory and registers the DLL. The ATLAS
custom step type calls functions within ATLAS_StepType.dll to configure and handle
interactions between TestStand and PAWS.
You must install the PAWS RTS with the TPS Server before you can build the
accompanying project. You must contact TYX Corporation for more information
about obtaining the PAWS RTS.
The project assumes you have installed the PAWS RTS in the default location of
C:\usr. If you installed the PAWS RTS in a different location, modify the path in the
following lines of code, located in <TestStand Public>\Examples\Custom Step
Types\ATLAS Step Types\ATLAS\StdAfx.h, to reflect the new location:

56 ni.com
TestStand User Manual

■ Change the line#import "C:\usr\tyx\com\rtsax.dll" raw_interfaces_only

to#import "<New Location>\tyx\com\rtsax.dll" raw_interfaces_only
■ Change the line#import "C:\usr\tyx\com\ComUtil.dll" raw_interfaces_only
to#import "<New Location>\tyx\com\ComUtil.dll" raw_interfaces_only
When you set the paths correctly, you can build the ATLAS custom step type project
with Microsoft Visual C++ 6.0.
The ATLAS custom step type creates the PAWS RTS and executes a TPS through the
PAWS TPS COM Server, and communicates with the TPS server by calling methods
within the NI ATLAS Step Type ActiveX server located in ATLAS_StepType.dll. The
server contains the IExecuteTPS class, which includes the following methods:
■ Edit Step—Sets up a TPS to call and the parameter to pass to the TPS.
■ Execute TPS—Creates the PAWS RTS and executes a TPS.
The ATLAS custom step type supports the use of the TestStand numeric, Boolean,
and string types. You can use parameters of these types to pass data between
TestStand and the TPS server. Data is exchanged through COM boundaries between
the ATLAS custom step type in TestStand, the NI ATLAS Step Type server, and the
TPS server, which monitors the PAWS RTS server, as shown in the following figure.
COM COM Process / Machine
Boundary Boundary Boundary

ATLAS NI ATLAS PAWS PAWS

TestStand
Custom Step Type TPS RTS
Sequence
Step Type Server Server Server

Parameter Passing Example

When you open the ParameterPassingExample.seq example sequence file, the
SequenceFileLoad callback copies the required files to the appropriate directories.
When TestStand executes the Main step group of the MainSequence, TestStand
launches a dialog box that requests a numeric value to pass to the sample TPS.
TestStand passes the numeric value, along with various other parameters, the TPS
server. The sample TPS modifies the numeric value and parameters and shows the
modified values when execution returns to TestStand.

Manual Intervention Example

When you open the ManualInterventionExample.seq example sequence file, the
SequenceFileLoad callback copies the required files to the appropriate directories.
When TestStand executes the Main step group of the MainSequence, the ATLAS step
calls a TPS that simulates and tests several devices. When the TPS simulates the
DMM, TestStand launches a dialog box that prompts for the simulated voltage. If you
enter a voltage that is within the acceptable range of 21 to 23 V, the test passes.
Otherwise, the test fails.
During execution, the TPS server also simulates a manual intervention request, in
which you can pause the execution while the TPS server resolves the condition that
caused the request. The simulated manual intervention launches a dialog box on
the same computer on which TestStand is running to inform you that manual
intervention has been requested. Click Continue in the dialog box to resume TPS
execution from TestStand.

Using the ATLAS Step in New Sequence Files

You can call an ATLAS TPS using step instances of the ATLAS custom step type. The
example sequence files contain ATLAS steps preconfigured to call a sample TPS. You
can execute these sequences without making changes. You can also use the ATLAS
custom step type in your own sequence files to call an ATLAS TPS. You can insert an
ATLAS step into a sequence in one of the following ways:
■ Copy an ATLAS step from one of the example sequence files to the new
sequence.
■ Copy the ATLAS custom step type from one of the example sequence files to
the new sequence.
■ Add the ATLAS custom step type to a type palette file and use the Insert Step
submenu in the Steps Pane context menu to create an instance of an ATLAS
step.
Before you can execute a sequence that contains an ATLAS step, you must configure
the step to call the appropriate TPS and pass any desired parameters. Click the Edit
ATLAS Step button on the Step Settings pane to launch the Edit ATLAS Call dialog

58 ni.com
TestStand User Manual

box, in which you can specify the TPS the step executes and the parameters passed
between TestStand and the TPS.
You can then execute the sequence that contains the steps. The ATLAS custom step
type fails on an ATLAS step if any faults are reported when the TPS executes. The
ATLAS custom step type also propagates and reports any errors the TPS server
encounters to TestStand. If the TPS server encounters no errors or faults, the step
passes.
When TestStand first executes an ATLAS step, the ATLAS custom step type loads an
instance of the RTS, or attaches to an existing RTS if one already exists. TestStand
stores a reference to this instance as a temporary global variable in the TestStand
Engine. Future executions of the ATLAS custom step type use the same reference for
TPS executions. The engine releases the reference when it shuts down.

Note TestStand updates properties referred in the Value Expression

control in the Edit ATLAS Call dialog box with the parameter values the TPS
server passes after TestStand calls the TPS server when executing an
ATLAS step.

Limitations
The following are known limitations of the ATLAS custom step type:
■ The step type does not support passing TestStand arrays, containers, or
object references as parameters.
■ You can execute only one ATLAS step at a time for each local or remote
computer. The ATLAS steps are locked globally with respect to the name of the
local or remote computer. A sequence might contain multiple ATLAS steps
that pertain to the same local or remote computer, but the step executions are
sequential. You can execute ATLAS steps that pertain to different computers
simultaneously.
■ The TestStand Deployment Utility does not automatically copy and register
ActiveX servers. You must add ATLAS_StepType.dll to the list of deployment
files to deploy the ATLAS custom step type. When you deploy the step type,
you must register the NI ATLAS Step Type ActiveX server. Refer to the

SequenceFileLoad callback sequence in either ATLAS example sequence file

for an example of registering an ActiveX server.

Error Codes and Descriptions

You might receive some error codes when using this example.
Related concepts:
■ TestStand Directory Structure
■ Custom Step Types
■
Type Palette Files
■ Edit ATLAS Call Dialog Box
■ Deploying TestStand Systems
■
Error Codes and Descriptions
Edit ATLAS Call Dialog Box
Select an ATLAS step in a sequence and click the Edit ATLAS Step button on the
Step Settings pane to launch the Edit ATLAS Call dialog box, in which you can specify
the test program set (TPS) the step executes and the parameters passed between
TestStand and the TPS.
The Edit ATLAS Call dialog box contains the following options:
■ TPS—The file path to the TPS the step executes. The control below the TPS
control shows the complete file path of the selected TPS and indicates
whether the file was found.
■ Run TPS on a Remote Computer—When enabled, the TPS executes on
a remote computer. When disabled, the TPS executes on the local computer.
This option is disabled by default.
■ Remote Host Name Expression—The name of the remote computer.
This option is available only when you enable the Run TPS on a Remote
Computer option. You can enter the name in the control or click the
Network Browser Dialog Box button to launch the Browse for Computer
dialog box and select the remote computer. If you enter the name in the
control, you must use quotes around the name because the content of the

60 ni.com
TestStand User Manual

control is a TestStand expression. You can specify a TestStand expression

instead of a hard-coded name. TestStand evaluates the expression at run
time to resolve the name of the remote computer. You can click the
Expression Browser Dialog Box button to launch the Expression
Browser dialog box, in which you can construct the expression.
■ Parameters—The parameters passed between TestStand and the ATLAS
TPS. TestStand parameters correspond to PAWS global variables, parameters,
and results. You must specify parameters to pass only when you pass data
between TestStand and the TPS.
■ Add Parameter—Adds a new parameter to the list of parameters to pass.
Use the Parameter Details section to configure the new parameter.
■ Delete Parameter—Deletes the selected parameter from the list of
parameters.
■ Move Parameter Up—Moves the selected parameter up in the list of
parameters.
■ Move Parameter Down—Moves the selected parameter down in the list
of parameters.
■ Parameter Details—Specifies the following information for the selected
parameter in the list of parameters:
■ Name—The name of the parameter.
■Type—The data type for the number. The type can be a number, string, or
Boolean.
■ Mode—Specifies if the data type mode is read, write, or read and write.
■ Global Variable—When enabled, the parameter is a PAWS global
variable or a PAWS parameter/result.
■ Value Expression—The value expression for the parameter. The
sequence context used to evaluate parameter values is the step context.

Note

■ If you can specify the file path to the TPS using relative or absolute
paths, TestStand launches a File Not Found dialog box that contains
options for specifying the file location.
■ You must properly configure the DCOM settings for the PAWS Run-Time
Server (RTS) on both the host and remote computers for remote
execution to work. Refer to PAWS documentation for more information
about configuring the PAWS RTS for remote execution.
■ You must specify the name of the parameter value exactly as the TPS
and TPS server expect. The TPS server allows verification of parameter
names prior to execution. The ATLAS custom step type generates an
error if the parameter cannot be read or written.
■ TestStand updates properties referred in the Value Expression control
with the parameter values the TPS server passes after TestStand calls the
TPS server when executing an ATLAS step.

Related concepts:
■
ATLAS Step Type
■
Sequence Context
Error Codes and Descriptions
The following table lists possible error codes you might receive while using the
ATLAS step type example and the corresponding descriptions.

Error Code Description

-17001 The test program set (TPS) cannot continue
execution because the NI ATLAS Step Type
ActiveX server is in an unrecognized state.
Unload the server from TestStand and restart
the execution.
-17205 The TPS cannot be executed because the PAWS
Run-Time System (RTS) is in a bad state or
cannot be initialized. Terminate the current
instance of the PAWS RTS and run the TPS
again.

62 ni.com
TestStand User Manual

Error Code Description

-17208 The specified TPS file was not found. Ensure
that the file path is correctly specified so
TestStand can locate the file and its directory.
-17401 The TPS cannot be executed because another
TPS exists and is currently running on the
requested host. Only one instance of the PAWS
RTS can exist on a host at any time. Wait for the
currently running TPS to complete execution or
terminate the execution before executing
another TPS.
-17500 The execution failed because the RTS reported
an error. The RTS error displays as part of the
error message.
-17501 An unexpected error occurred.
-17600 The TPS cannot be loaded because the RTS was
interrupted during the load process. Check the
TPS and PAWS RTS for errors and try running
the TPS again.
-17601 No TPS file was specified for execution. Use the
Edit ATLAS Call dialog box to select a file to call
before executing the step.

Related concepts:
■ ATLAS Step Type
■ Edit ATLAS Call Dialog Box

Java Step Types

Purpose
This example demonstrates custom step types for calling methods in Java classes.
The step types call compiled Java class files (.class) using the Java Native Interface
(JNI) and permit the invocation of methods located within the classes.

Example File Location

<TestStand Public>\Examples\Custom Step Types\Java Step Types\Java Computer
Motherboard Test.seq

Highlighted Features
Custom step types

Major API
Engine.UnloadAllModules

Prerequisites
Java Runtime Environment (JRE) version 6 update 16, which you can download
from the Oracle website. The Java step types are likely compatible with earlier and
later versions of the JRE but have not been tested in JRE versions other than version
6 update 16.

How to Use This Example

The example sequence file, Computer.seq, contains a SequenceFileLoad callback
that TestStand automatically executes when you open the sequence file. The
SequenceFileLoad callback copies the JavaCall.dll and JavaCall.uir files from the
<TestStand Public>\Examples\Custom Step Types\Java Step Types directory to the
<TestStand Public>\Components\StepTypes\Java directory. The Java step types call
functions within JavaCall.dll, which must be located in a TestStand search directory
for the step types to locate the DLL.

Note You must install the JRE before you can build the accompanying
project.

The Java step types support the creation and cleanup of the Java virtual machine
(JVM) and the manipulation of objects that exist within the JVM through method
calls. The step types support the use of all Java primitive types and strings, which
you can use to pass data between TestStand and Java objects. The step types rely
on JavaCall.dll, which is a LabWindows/CVI library, for TestStand to interface with
Java. The library communicates with TestStand using an ActiveX interface and
communicates with Java through the JNI.

64 ni.com
TestStand User Manual

Java uses the JNI to call compiled code written in C/C++ and to access Java code
from C/C++. Refer to the Java Native Interface website for more information about
JNI technology.
When you open <TestStand Public>\Examples\Custom Step Types\Java Step
Types\Java Computer Motherboard Test.seq in the TestStand Sequence Editor, the
Java step types appear in the following groups on the Insertion Palette:
■ StartStop—Contains steps that start and destroy the JVM.
■ Methods—Contains steps that call a particular Java method in a specified
class.
■ Static Methods—Contains steps that call a particular static class method
in a specified class.
The CallStaticJavaMethod and CallJavaMethod steps consist of Numeric Limit Test,
String Value Test, Pass Fail Test, and Action steps.
Use a Java step type to call JavaCall.dll, which extracts information about the step
type from TestStand using ActiveX calls and then calls the appropriate method in
the JVM using the JNI. For example, use the CallJavaMethod step to call the
InvokeJavaMethod function JavaCall.dll, which calls the TestStand Engine to extract
the class, method, and parameter information and instantiate the class within the
existing JVM. The step identifies and calls the method with parameter values
retrieved from TestStand. The JavaCall.dll file then passes the return value back to
TestStand.

StartStop Steps
Use the StartJVM and DestroyJVM steps, located under the StartStop group on the
Insertion Palette, in pairs around other Java steps to call methods for the contained
steps. A typical sequence structure begins with a StartJVM step, which you place in
the Setup step group, followed by a number of Methods or Static Methods steps,
which you place in the Main step group. Place the DestroyJVM step in the Cleanup
step group.
Configure the StartJVM step to provide the class path, which is the path of the Java
classes to access. Select the StartJVM step in a sequence and click the Edit Java
Class Path Location button on the Step Settings pane to launch the Set Class Path

dialog box, in which you can specify the class path. You must include all Java classes
that are accessed in the path. If you leave the path empty, the JVM cannot locate the
user-written Java classes. Click Browse in the Set Class Path dialog box to launch
the Select Paths dialog box, in which you can add directories that contain the Java
classes to call.

Methods and Static Methods Steps

The Static Methods steps call static class methods and the Methods steps call other
methods of the class. The Methods steps automatically load the appropriate class
and create new instances of the class before making the call to the method. The
Static Methods steps do not create new instances of the class before making the call.
Methods and Static Methods steps include the following steps:
■ Numeric Limit Test—Used to call methods that return a numeric value,
such as a byte, integer, short, long, float, or double. You can compare the
value returned to a set of limits to determine whether the step passed.
■ String Value Test—Used with a method that returns a string value. The
step compares the returned value to the expected value.
■ Pass/Fail Test—Used with Boolean return values.
■ Action—Used with any type of return value.
You can configure Methods and Static Methods steps by selecting a step in the
sequence and clicking the Edit Call or Edit Static Call button on the Step Settings
pane to launch the Edit Java Call dialog box, in which you can configure the step to
call the appropriate Java method.

Tips for Using the Java Step Types

Keep the following tips in mind when you use Java step types in TestStand:
■ Before calling any Java methods, you must create the JVM. Call the StartJVM
step before you call any of the Methods or Static Methods steps.
■ The Methods steps automatically load the appropriate class and allocate an
object of that type. The Static Methods steps load only the appropriate class.

66 ni.com
TestStand User Manual

Neither step type automatically calls the constructor of the class. The example
does contain a sample .
■ Because Java is case-sensitive, the class name and method names must use
the same case as the Java class file specifies.

Compatible Types
The following table shows how data types in TestStand are compatible with certain
data types in Java. The Java step types automatically handle the conversion
between types.

TestStand Type Java Types

Number byte, short, int, long, float, double
String char, string
Boolean Boolean

Computer Motherboard Example

When you open the Computer.seq example sequence file, the SequenceFileLoad
callback copies the required files to the appropriate directories. When TestStand
executes the Setup step group of the MainSequence, the sequence first obtains the
TestStand directory and locates the Java classes to call. The StartJVM step
automatically sets the class path and passes it to the JVM. TestStand then calls a
static Java method called Start, which creates a new computer object by calling the
constructor of the Computer class, to launch a dialog box. You can dismiss the
dialog box, and TestStand reads the tests you select to fail from the Java class one
call at a time because Java supports only calls by value semantics.
When the calls are complete, the steps in the Main step group call the Java methods.
The steps supply a value to the methods that determine whether the test passes or
fails. Depending on the supplied value, the method returns a result. If a single step
fails, TestStand skips all remaining steps.
The step in the Cleanup step group destroys the JVM.

Limitations
The following are the known limitations of the Java step types:
■ The step types currently do not support Java reference types, such as arrays
and objects.
■ You cannot access the same instantiated object multiple times. Each time a
step calls a method on an object, a new object is created. Therefore, all states
must be maintained in class variables as static members.
■ The step types cannot directly call constructors. The example does contain a
sample .
■ The step types are not thread-safe. Do not use the step types with the
Parallel and Batch process models.

Known Issues
Because you cannot unload the JVM once you load it in a process without exiting the
process, the DestroyJVM step does not actually destroy the JVM. Instead, the
DestroyJVM step only detaches the current thread, which indicates that the JVM is
no longer referenced, so that the JVM can unload in future versions, if required.
Refer to the DestroyJavaVM API documentation on the Oracle website for more
information about this issue.
You cannot unload the JVM once you load it in a process, and you cannot unload
JavaCall.dll when you call the Engine.UnloadAllModules method of the TestStand
API. You can unload JavaCall.dll only by exiting the process by closing the sequence
editor or user interface. Once you load a Java class file, you must restart the process
by restarting the sequence editor or user interface to force the JVM to load any
changed or recompiled versions of the Java class.
You cannot change the class search path once TestStand loads the JVM. When
TestStand calls the StartJVM step with a given class path, you cannot change the
class search path by calling the StartJVM step again with a new class path. You can
change the class path only by exiting the process by closing the sequence editor or
user interface. You must set the required class paths in the first StartJVM step.

68 ni.com
TestStand User Manual

Error Codes and Descriptions

You might receive some error codes when using this example.
Related concepts:
■
TestStand Directory Structure
■
Custom Step Types
■ Edit Java Call Dialog Box
■ Error Codes and Descriptions
Edit Java Call Dialog Box
Select a Java Methods and Static Methods step in a sequence and click the Edit Call
or Edit Static Call button on the Step Settings pane to launch the Edit Java Call
dialog box, in which you can configure the step to call the appropriate Java method.
The Edit Java Call dialog box contains the following options:
■ Java Class to Load—The Java class that contains the method to call. If
TestStand cannot locate the file, TestStand launches the File Class Not Found
dialog box. Select the Add the directory containing the file you selected
to the list of search directories option and click OK. Do not select Use an
absolute path for the file you selected. The control below the Java Class
to Load control displays the complete file path of the specified class. If the file
is incorrect, add the appropriate directory to the list of TestStand search
directory paths or move the directory up to a higher position in the list of
search paths.

Note Always use a relative path for the Java class to load. If you
specify an absolute path, the Java virtual machine (JVM) cannot
locate the class name and you receive a -1000 Class Not Found error.

■ Java Method—The name of the method to call. Specify the name after you
select the Java class that contains the method.
■ Parameters—Contains the following options for creating and configuring
parameters to pass to the specified method:

■ Method Parameter—The list of parameters to pass to the specified

method. Select a parameter from the ring control to specify the argument
type and value expression for the parameter. The order of parameters must
match the order the Java method header uses in the parameter list. If no
parameters are to be passed, delete all parameters from the list.
■ New—Adds a new parameter to the list of parameters.
■ Argument Type—The type of the parameter. The available types are the
Java types represented in the Java method header.
■ Delete—Deletes the selected parameter from the list of parameters.
■ Value Expression—The value expression for the parameter. If the value
to be passed is stored in a TestStand variable, click Browse to locate the
variable. Otherwise, enter the value of the parameter. You must verify that
the type of the value or TestStand variable is compatible with the Java
parameter type.

Note Enclose literal strings and characters in double quotes.

■ Return Value—Contains the following options for specifying a return value
for the specified method:
■ Return Value—The return value.
■ Argument Type—The type of the return value. The type must match the
variable that stores the return value, or the return value must be compatible
for the appropriate comparisons to occur. For example, the Numeric Limit
Test steps require the return value to be stored in Step.Result.Numeric, the
String Value Test steps require the return value to be stored in
Step.Result.String, and the Pass Fail Test steps require the return value to be
stored in Step.Result.PassFail. For Action steps, select void for the argument
type if no return value exists.
■ Value Expression—The value expression for the return value, which
TestStand stores in a variable. Click Browse to locate the variable. You must
verify that the type of the value or TestStand variable is compatible with
Java types.

70 ni.com
TestStand User Manual

Related concepts:
■ Java Step Types
■
Search Directories
Error Codes and Descriptions
The following table lists possible error codes you might receive while using the Java
step types example and the corresponding descriptions.

Error Code Error Message Explanation

-1001 Could not launch JVM The creation of the Java virtual
machine (JVM) failed. Refer to
the Sun website at
java.sun.com for information
about the possible causes of
the failure. Verify that jvm.dll
was found and is not corrupt,
and ensure that the class path
is valid.
-1001 Could not attach thread to JVM The current thread was
detached from the JVM. Restart
TestStand and ensure that the
Java run-time environment is
installed correctly.
-1001 Could not detach current The current thread could not be
thread detached from the JVM. Restart
TestStand and ensure that the
Java run-time environment is
installed correctly.
-1002 Could not launch JVM The current thread was
detached from the JVM. Restart
TestStand and ensure that the
Java run-time environment is
installed correctly.
-1003 Could not launch JVM A Java Native Interface (JNI)
version error occurred. The
wrong version of the JVM was
found. Ensure that the Java

Error Code Error Message Explanation

run-time environment is
installed correctly.
-1004 Could not launch JVM Insufficient memory to create
the JVM.
-1005 Could not launch JVM The JVM already exists in
memory.
-1006 Could not launch JVM Invalid arguments are passed.
Verify that the class path is
correct and ensure that the
Java run-time environment is
installed correctly.
-1500 Cannot find class The specified class name was
not found in the class path.
Verify the class name and that
the file that contains the class
exists in the class path.
-2000 Incorrect class name The specified class name is
incorrect. Re-enter the class
name in the Edit Java Call
dialog box.
-3000 Cannot find method The specified method was not
found in the specified class.
Verify that the method name is
correct and that it exists in the
specified class.
-3500 Too many arguments passed Too many arguments are
for void method passed for a void method.
-4000 Error reading returned string The string returned from Java is
corrupt. Verify that the return
type of the Java method is a
string value.
-5000 Invalid return type found The return type of the Java
method does not match the
return type specified in
TestStand. Ensure that the
variable types in TestStand are
compatible with the Java types.

72 ni.com
TestStand User Manual

Error Code Error Message Explanation

-6000 JVM not invoked The JVM was not created. Verify
that TestStand calls the
StartJVM step before this step.
-7000 Unable to find registry key for The registry key that contains
Java run time the entry for the Java run-time
environment cannot be found.
The JVM installer registers the
key. Reinstall the JVM.
-7500 Unable to find registry keys for The registry entry that specifies
Java the location of jvm.dll was not
found. The Java run-time
environment installs the entry.
Reinstall the JVM.
-8000 Unable to find run-time DLL for The registry entry for jvm.dll
Java points to an invalid location,
which indicates that the DLL
was not found at the location.
Reinstall the JVM.
-9000 Unable to find CreateJavaVM The jvm.dll file does not
function jvm.dll contain the CreateJavaVM
function, which indicates that
the DLL is invalid. Reinstall the
JVM.
-10000 Cannot allocate memory The system is low on resources
and memory allocation failed.

Related concepts:
■ Java Step Types
■
Edit Java Call Dialog Box

Examples for Customizing Result Processing

The Customizing Result Processing examples demonstrate common approaches for
customizing default TestStand result processing plug-ins, and for creating custom
result processing plug-ins. This directory includes the following example programs.

Adding Custom Data to a Report

Purpose
You must complete the following tasks to add additional data to a report:
■ Configure the desired property to be logged as a result. Results are stored in
the Locals.ResultList array.
■ Configure the result to be added to the report. This is typically
accomplished by enabling the \IncludeInReport\ flag.
This example demonstrates the following approaches for adding custom data to a
report:
■ Using the UUT.AddtionalData container to add data to the report header
■ Using the API method Execution.AddExtraResult
■ Creating a custom property and setting the IncludeInReport flag
■ Creating a custom step type with custom properties in the Step.Result
container
■ Using the Additional Results step type or property setting

Example File Location

<TestStand Public>\Examples\Customizing Result Processing\Adding Custom Data
To a Report\Adding Custom Data To a Report.seq

Highlighted Features
■ TestStand API
■ PreUUT Callback
■ Custom step types

Major API
■ Execution.AddExtraResult
■ PropertyObject.SetValString
■ PropertyObject.SetFlags

74 ni.com
TestStand User Manual

Prerequisites
None

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Single Pass to execute the sequence.
2. As the example executes, read the message popups for information about
each method demonstrated.
Complete the following steps to review the sequences and steps in this example.
1. Select the PreUUT Callback in the sequences pane. Note that the statement
steps create new properties in the Parameters.UUT.AdditionalData container,
which will appear in the report header. The PropertyObject.SetFlags method
is used to configure the property to display in the report.
2. Select the AddExtraResult sequence. This sequence calls the
Execution.AddExtraResult method to add the Step.MessageExpr property to
the Result list. For the property to appear in the report, the IncludeInReport
flag must be enabled for this property.
3. Select the CustomProperty sequence. This sequence uses the
PropertyObject.SetValString method to create a new property in a Numeric
Limit Test step. The sequence then calls PropertyObject.SetFlags to enable
the IncludeInReport flag for the new property so that it is displayed in the
report.
4. Select the CustomStepType sequence. This sequence calls a step type
which has an additional property in the results container. The IncludeInReport
flag for this property is enabled in the step type definition, so you do not need
to enable it for each instance of the type.
5. Select the AdditionalResults sequence. This sequence uses the Additional
Results step to log additional data to the report. It also uses the Log option for
parameters in the Calculate Area of Circle code module to log the parameter
values

Related concepts:
■ Storing Additional Information for UUTs and Test Stations in Process Models
■
TestStand Directory Structure
■ Custom Step Types

Adding Custom Images to a Report

Purpose
This example is identical to the computer.seq example included in the <TestStand
Public>\Examples\Demo directory except that it demonstrates how to modify the
report of any failed diagnostic test steps to include HTML hyperlinks. When you are
using an HTML-compatible report viewer, scroll down in the report to view any failed
tests.

Note You can enable report generation in the ReportOptions callback.

Example File Location

<TestStand Public>\Examples\Customizing Result Processing\Adding Custom
Images To a Report\Adding Custom Images To a Report.seq

Highlighted Features
Generating a test report

Major API
None

Prerequisites
None

76 ni.com
TestStand User Manual

How to Use This Example

Note Before you run this example, click the Toggle Analyze File
Before Executing button on the Sequence Analyzer toolbar to specify
that you do not want the TestStand Sequence Analyzer to analyze the
sequence file before TestStand executes the sequence. If you leave
sequence analysis enabled and you run the sequence, TestStand returns
an error because the sequence file generates some variables dynamically
at run time. If you do encounter this error, you can select the Continue
Execution option to continue sequence execution.

Complete the following steps to use this example.

1. Select Execute»Single Pass to run the sequence. TestStand launches the
Test Simulator dialog box, in which you select a computer motherboard test
that you want to fail.
2. Select at least one test to fail and click Done. After execution completes,
TestStand displays the report on the Report pane.
3. Review the report. The Failure Section of the report lists the steps that failed
and, for each failed step, includes an HTML hyperlink that links to the section
of the report with more information about the step.
4. Close the Report pane.
5. In the Sequence File window, select the second If step. The If Condition edit
tab specifies an expression that determines whether any test in the sequence
failed. If a test failed, the sequence checks the status of each test and calls
computer.dll, located in the <TestStand Public>\Examples\Customizing Result
Processing\Adding Custom Images To a Report\HTMLDiagnosticLinks
directory, to determine what information to add to the report. TestStand
passes value by reference so the DLL can update the report.
This example uses a DLL to maintain modular and reusable code, but you can also
configure each step that fails to add HTML content directly to the report.
Related concepts:

■ TestStand Directory Structure

Displaying Graphs in a Report

Description
This example demonstrates how to include an array from a step that calls a code
module in the test report.

Example File Location

<TestStand Public>\Examples\Customizing Result Processing\Displaying Graphs In a
Report\Displaying Graphs In a Report.seq

Highlighted Features
Custom step types

Major API
None

Prerequisites
None

How to Use This Example

To execute the sequence, select Execute»Single pass.
The Methods of Logging Array Data section of the MainSequence demonstrates
the following two approaches for adding array data to the report:
■ Log Array using Custom Action Step is an instance of a custom step
type that specifies the custom property Step.Result.ResultArray. The Custom
Action Step calls a code module that generates an array and writes it to
Step.Result.ResultArray. TestStand step types set the IncludeInReport
property flag on a subset of their result properties to specify that these
properties automatically appear in the report. The IncludeInReport flag has
been enabled for the Step.Result.ResultArray property so that TestStand

78 ni.com
TestStand User Manual

automatically adds the values of ResultArray to the report during report

generation.
■ Log Array using Additional Results uses the Log field to specify that a
parameter should be in the report. This field is configured in the Parameters
pane, located in the module tab of the step settings pane. The log field allows
you to easily log data with no further customization.
You can customize how TestStand displays the array in the report with the Include
Arrays option on the Contents tab of the Report Options dialog box. TestStand can
insert arrays as tables or graphs. In this example, the ReportOptions callback sets
arrays to display as graphs.
In the Using Graph Attributes section of the example, you can customize the
graph of an array by using the attributes of the array property, Locals.OutputData.
To view or edit the attributes of a property, right click the property, then select
Advanced»Edit Attributes . To customize the appearance of a graph, use the
DataLayout and DataOrientation attributes, as described in the Displaying Array
Data as Graphs help topic.
Review the comments for the Set Graph Attributes and Log steps for more
information about the graph behavior for each value of the DataLayout and
DataOrientation attributes.
Related concepts:
■ TestStand Directory Structure
■
Custom Step Types

Including Hyperlinks in a Report

Purpose
This example demonstrates how to include hyperlinks in reports that TestStand
generates. You can use the Path type, with the attribute TestStand.Hyperlink set to
True, to convert any path displayed in the report to a hyperlink.

Example File Location

<TestStand Public>\Examples\Customizing Result Processing\Including Hyperlinks
in a Report\Including Hyperlinks in a Report.seq

Highlighted Features
Path data type

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to run the example.
1. To link to an image, select the Create a link to an image on disk step. This
step stores an image path in a local variable and adds this variable to the
report as an additional result. This data must be stored in a TestStand
property before logging so that the hyperlink attribute can be set to True for
the property. Click Edit Attributes next to the local variables to view this
attribute.
2. To link to a web page, select the Create a link to a webpage step. This step
stores a URL in a local variable and adds this variable to the report as an
additional result.
3. Select the CPU Test step. If this step fails, an additional result is logged to link
to an HTML file that contains troubleshooting instructions for the operator.
4. Select Execute»Single Pass.
5. When the execution completes, review the report, which contains links to the
image, web page, and local HTML file.
6. Click the links to open the corresponding locations.

80 ni.com
TestStand User Manual

Related concepts:
■ TestStand Directory Structure
■
Path

Including Hyperlinks in a Report - TDMS File

Purpose
This example demonstrates how to use the NI_TDMSReference and Path data types
to include hyperlinks to files in reports TestStand generates.

Example File Location

<TestStand Public>\Examples\Customizing Result Processing\Including Hyperlinks
in a Report\Including Hyperlinks in a Report - TDMS File.seq

Highlighted Features
■ NI_TDMSReference data type
■ Path data type

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to use this example.
1. Select the Provide links to TDMS file and Image in the generated
report step. This step adds the TDMSRef and ImagePath variables to the
ResultList using the Additional Results feature.
2. Select Execute»Single Pass.

3. When the execution completes, review the report, which contains links to the
TDMS file and the image. Text reports do not include hyperlinks.
4. Click the links to open the corresponding files. TestStand uses the default
application you specify for the file format to open the file when you click the
link in the report.
Related concepts:
■
NI_TDMSReference
■
Path
■ TestStand Directory Structure

Model Plug-in - Basic Step Time Report

Purpose
This example demonstrates how to a basic step time report for each UUT so you can
benchmark and analyze the performance of a sequence file. The example generates
a summary report, a file of unprocessed data, and a report in format that includes
processed time data. You can also run a stand-alone executable to a basic step time
report in .csv format to Excel format. You can basic step time reports in Excel format
for multiple UUTs.

Example File Location

<TestStand Public>\Examples\Customizing Result Processing\Model Plugin - Basic
Step Time Report\Install Basic Step Time Report Plugin.seq

Highlighted Features
Process model plug-in architecture

Major API
None

82 ni.com
TestStand User Manual

Prerequisites
You must have Microsoft Office Excel 2007 SP2 or later installed on the computer to a
basic step time report in Excel format and to run the executable to a .csv file to Excel
format. If Excel is not installed on the computer, this custom reporting plug-in
generates only a .csv file.

How to Use This Example

You can use this example to a basic step time report. The example generates a
summary report, a file of unprocessed data, and a report in format that includes
processed time data. You can also run a stand-alone executable to a basic step time
report in .csv format to Excel format. You can basic step time reports in Excel format
for multiple UUTs.

Generating a Basic Step Time Report

Complete the following steps to use this example to generate a basic step time
report.
1. Open <TestStand Public>\Examples\Customizing Result Processing\Model
Plugin - Basic Step Time Report\SetupBasicStepTimeReportGenerator.seq,
click OK in the About This Example dialog box to copy the example and
support files to the <TestStand Public>\Components\Models\ModelPlugins
directory, and click Yes in the Setup Simple Text Report Example Files dialog
box.
2. Open a sequence file for which you want to generate a basic step time report.
3. Select Configure»Result Processing to launch the Result Processing dialog
box.
4. Select Basic Step Time Report from the context menu to add the Basic Step
Time Report plug-in to the active configuration.
5. Enable the checkbox in the Display column of the Basic Step Time Report
plug-in to display the HTML summary report in the Report pane.
6. Click the icon in the Options column of the Basic Step Time Report plug-in to
launch the Basic Step Time Report Configuration dialog box, in which you

specify the directory in which to store the report and specify whether to
launch the report in Excel.
7. Click OK in the Basic Step Time Report Configuration dialog box and in the
Result Processing dialog box to return to the Sequence File window.
8. Execute the sequence file and view the reports.

Convert a .csv File to Excel Format

Complete the following steps to use a stand-alone application to convert a .csv file
to Excel format.
1. Launch <TestStand Public>\Examples\Customizing Result Processing\Model
Plugin - Basic Step Time Report\CsvToBasicStepTimeReportGenerator.exe.
2. Specify the path to the .csv file you want to convert in the Path of CSV
Report control and specify the path to the Excel file you want to create in the
Path of Basic Step Time Report control.
3. Enable the Launch Basic Step Time Report to open the report in Excel
option and click OK.
4. View the report in Excel.
You can also use command-line arguments to launch the stand-alone application,
specify the path to the .csv file, specify the path of the Excel file you want to create,
and optionally display the file in Excel as follows:
CsvToBasicStepTimeReportGenerator.exe <Path of CSV Report> <Path of Excel File to
Create> [/display]

Aggregating Basic Step Time Reports in Excel Format for Multiple UUTs
Complete the following steps to aggregate basic step time reports in Excel for
multiple UUTs. The value in the ID column of the Raw Data worksheet must be
unique across all the reports you want to aggregate.
1. Open the reports you want to combine in Excel.
2. In the main report file into which you want to aggregate all the data,
unprotect the Raw Data worksheet.

84 ni.com
TestStand User Manual

3. Complete the following steps for each report file you want to aggregate into
the main report file.
a. From the Raw Data worksheet, copy the rows that correspond to the
steps you want to include in the main report file.
b. Paste the data you copied into the Steps section of the Raw Data
worksheet of the main report file.
4. In the Raw Data worksheet of the main report file, click the Regenerate
Processed Data and Graphs button update and overwrite the existing data
and graphs in the Step, Sequence, and Sequence File worksheets.

Reports the Basic Step Time Report Generator Plug-In Creates

The Basic Step Time Report Generator plug-in generates a single report file for each
UUT in , , and formats using the following filename format:
[Station ID][Sequence File Name][Test Socket Index][Batch Serial Number][UUT
Serial Number][Time][Date].[html|csv|xls]
Microsoft Windows and Excel limit the number of characters in a file path. If the
length of the file path for generated reports is less than 218 characters, the Basic
Step Time Report Generator plug-in generates reports in HTML, .csv, and Excel
format. If the length of the file path for generated reports is between 218 and 260
characters, the Basic Step Time Report Generator plug-in generates reports only in
HTML and .csv formats. If the length of the file path for generated reports exceeds
260 characters, the Basic Step Time Report Generator plug-in does not generate any
report and returns an error before executing the sequence file.
The Basic Step Time Report plug-in uses an underscore (_) in the place of the #
character and invalid filename characters in a UUT or batch serial number.

HTML
TestStand displays the HTML report in the Report pane, and the HTML report links to
the .csv and Excel reports.
The HTML report includes the following information for each UUT in the report
header:

■ Station ID
■ Operator
■ UUT Part Number (if non-empty)
■ UUT Serial Number
■ Batch Serial Number (if using the Batch model)
■ TestSocket Index (if using the Batch or Parallel model)
■ Date
■ Time
■ Execution Time
■ UUT Result
■ TSR Filename (if using the TestStand Offline Results Processing Utility)
■ TSR ID (if using the TestStand Offline Results Processing Utility)
■ TSR File Closed (if using the TestStand Offline Results Processing Utility)

.csv
The .csv report includes the following information for each UUT in the report
header:
■ Station ID
■ Operator
■ UUT Part Number (if non-empty)
■ UUT Serial Number
■ Batch Serial Number (if using the Batch model)
■ TestSocket Index (if using the Batch or Parallel model)
■ Date
■
Time
■ Execution Time
■ UUT Result
■ CSV File Format Version
■ TSR Filename (if using the TestStand Offline Results Processing Utility)

86 ni.com
TestStand User Manual

■ TSR ID (if using the TestStand Offline Results Processing Utility)

■ TSR File Closed (if using the TestStand Offline Results Processing Utility)
For each step, the report includes the following information:
■ Sequence Filename—Name of the sequence file that contains the step
■ Sequence Name—Name of the sequence that contains the step
■ Step Group—Name of the step group that contains the step
■ Step ID—Unique ID of the step
■ Step Name—Name of the step
■ Parent ID—ID of the parent sequence call step
■ Step Type—Type of the step
■ ID—Unique execution ID of the step
■ Status—Execution status of the step
■ Start Time—Execution start time of the step
■ Total Time—Total time the step takes to complete execution
■ Module Time—Time the code module of the step takes or empty if the step
uses the None adapter
■ Sequence Call Sequence Filename—Path of the sequence file a non-
asynchronous Sequence Call step calls
■ Sequence Call Sequence Name—Name of the sequence a non-
asynchronous Sequence Call step calls
■ Number of Loops—Number of loops the step executes or empty if the step
does not use looping
■ Ending Loop Index—Index of the last iteration of the loop for the step or
empty if the step does not use looping
■ Loop Index—Index of the current iteration of the loop for the step or empty
if the step does not use looping
■ UUT Serial Number—Serial number of the UUT
■ Batch Serial Number—Serial number of the batch that contains the UUT
■ TestSocket Index—Index of the test socket the UUT uses

Note The Sequence File, Sequence, and Parent ID columns are empty for
the MainSequence Callback step from process model files.

Excel
The Excel report includes the following information for each UUT in an Excel
workbook with the following worksheets:
■ Step—Contains the following processed data for the steps used to test the
UUT and graphs to show the average total time of the steps and the
cumulative total time of the steps. You can modify the data and graphs in this
worksheet.
■ Step Name
■ Step ID
■ Cumulative Total Time (of the step)
■ Cumulative Module Time (of the step)
■ Number of Execution
■ Average Total Time
■ Average Module Time
■ Max Total Time
■ Max Module Time
■ Min Total Time
■ Min Module Time

Note This worksheet does not contain information for the

MainSequence Callback step from process model files.

■ Sequence—Contains the following processed data for the sequences used to

test the UUT and graphs to show the average total time of the sequences and
the percentage of the cumulative total time of the sequences. You can modify
the data and graphs in this worksheet.
■ Sequence File Name

88 ni.com
TestStand User Manual

■ Sequence Name
■ Cumulative Total Time (of each Sequence Call step that calls the
sequence, including subsequence time)
■ Cumulative Total Time (of each Sequence Call step that calls the
sequence, excluding subsequence time)
■ Number of Times Sequence Call Steps Call into the Sequence
■ Average Total Time (excluding subsequence time)
■ Max Total Time (excluding subsequence time)
■ Min Total Time (excluding subsequence time)

Note This worksheet contains information only for non-

asynchronous Sequence Call steps. You can modify the source code
to insert data for Post Action Sequence Call, callback sequence, and
asynchronous Sequence Call steps.

■ Sequence File—Contains the following processed data for the sequence files
used to test the UUT and graphs to show the cumulative total time of the
sequence files and the percentage of total time for the sequence files. You can
modify the data and graphs in this worksheet.
■ Sequence Filename
■ Cumulative Total Time (of Sequence Call steps calling any sequence in the
sequence file)
■ Raw Data—Contains all the data from the .csv file in protected mode. Click
the Regenerate Processed Data and Graphs button to update and
overwrite the existing data and graphs in the Step, Sequence, and Sequence
File worksheets.
Related concepts:
■ TestStand Directory Structure
■ Process Model Plug-In Architecture

Model Plug-in - Simple Text Report

Purpose
This example demonstrates how to implement a result processing process model
plug-in using LabVIEW, LabWindows/CVI, and Microsoft Visual C#.

Example File Location

<TestStand Public>\Examples\Customizing Result Processing\Model Plugin - Simple
Text Report\Install Simple Text Report Plugin.seq

Highlighted Features
Process model plug-in architecture

Major API
N/A

Prerequisites
None

How to Use This Example

You can use the <TestStand Public>\Examples\Customizing Result Processing\Model
Plugin - Simple Text Report\SetupExamplePlugin.seq example sequence file to
install a result processing process model plug-in that generates a simple text report
you can use for system monitoring and debugging. NI recommends using the
Microsoft Visual C# version if you intend to use the simple text reporting
functionality only as provided.

LabVIEW
Complete the following steps to build and use the LabVIEW version of this example.
1. Open the <TestStand Public>\Examples\Customizing Result Processing\Model
Plugin - Simple Text Report\LabVIEW\SimpleTextPlugin.lvproj file in LabVIEW.
2. Build the Build Simple Text Plugin build specification.

90 ni.com
TestStand User Manual

3. Confirm that the following files exist:

■<TestStand
Public>\Components\Models\ModelPlugins\NI_SimpleTextReport_LabVIEW\SimpleTex
■<TestStand
Public>\Components\Models\ModelPlugins\NI_SimpleTextReport_LabVIEW.seq
4. Add and enable an instance of the LabVIEW simple text report process model
plug-in in the Result Processing dialog box.

LabWindows/CVI
Complete the following steps to build and use the LabWindows/CVI version of this
example.
1. Open the <TestStand Public>Examples\Customizing Result Processing\Model
Plugin - Simple Text Report\CVI\SimpleTextReport.cws file in LabWindows/
CVI.
2. Select Build»Create Debuggable Dynamic Link Library.
3. Copy the <TestStand Public>\Examples\Customizing Result Processing\Model
Plugin - Simple Text Report\CVI\NI_SimpleTextReport_CVI.seq file to the
<TestStand Public>\Components\Models\ModelPlugins directory.
4. Confirm that the <TestStand
Public>\Components\Models\ModelPlugins\NI_SimpleTextReport_CVI\NI_SimpleTextRep
file exists and has been overwritten by the version you just built.
5. Add and enable an instance of the LabWindows/CVI simple text report process
model plug-in in the Result Processing dialog box.

Microsoft Visual C#
Complete the following steps to build and use the Microsoft Visual C# version of this
example.
1. Open and build the <TestStand Public>\Examples\Customizing Result
Processing\Model Plugin - Simple Text Report\DotNet\SimpleTextReport.sln
file.

2. Copy the <TestStand Public>\Examples\Customizing Result Processing\Model

Plugin - Simple Text Report\DotNet\NI_SimpleTextReport_DotNet.seq file to
the <TestStand Public>\Components\Models\ModelPlugins directory.
3. Create the <TestStand
Public>\Components\Models\ModelPlugins\NI_SimpleTextReport_DotNet
directory if it does not already exist.
4. Copy the <TestStand Public>\Examples\Customizing Result Processing\Model
Plugin - Simple Text Report\DotNet\SimpleTextPlugin_DotNet.dll file to the
<TestStand
Public>\Components\Models\ModelPlugins\NI_SimpleTextReport_DotNet
directory.
5. Copy the <TestStand Public>\Examples\Customizing Result Processing\Model
Plugin - Simple Text Report\DotNet\NationalInstruments.TestStand.Utility.dll
file to the <TestStand
Public>\Components\Models\ModelPlugins\NI_SimpleTextReport_DotNet
directory.
6. Add and enable an instance of the Microsoft Visual C# simple text report
process model plug-in in the Result Processing dialog box.
Related concepts:
■ TestStand Directory Structure
■ Process Model Plug-In Architecture

Examples for Demos

The Demo examples provide an overview of TestStand features. You can execute
these examples without installing additional software. This directory includes the
following example programs.

Computer Motherboard Test

The <TestStand Public>\Examples\Demos\Computer Motherboard Test directory
contains the following examples.
Related concepts:
■ TestStand Directory Structure

92 ni.com
TestStand User Manual

Computer Motherboard Test Sequence - HTBasic

Purpose
This example simulates the testing of a computer motherboard using test steps that
use the HTBasic Adapter. The example calls subsequences in the CPU Diagnostic
Sequence.seq and CPU Test Sequence.seq sequence files.

Example File Location

<TestStand Public>\Examples\Demos\Computer Motherboard
Test\HTBasic\Computer Motherboard Test Sequence.seq

Highlighted Features
■ Preconditions
■ Sequence Call steps
■ Test step types

Major API
None

Prerequisites
The example contains sequence files designed to work with HTBasic 8.0.
When you use the demo version of HTBasic, you must configure the HTBasic
Adapter to use the HTBasic demo server. Select the Use HTBasic Runtime Server
option in the HTBasic Adapter Configuration dialog box and specify the path and
filename for HTBwin.exe.

Note (64-bit TestStand) 64-bit TestStand does not support the HTBasic
Adapter.

How to Use This Example

Complete the following steps to use this example.
1. On the Steps pane of the MainSequence, review the steps in the Main step
group.
■ The Powerup Test step, which is a Pass/Fail Test step, simulates a power-
up test. Each of the five test steps that follow the Powerup Test specifies a
precondition expression that executes the step only when the Powerup Test
step passes.
■ The CPU Test step, which is a Sequence Call step, calls the MainSequence
in the CPU Test Sequence.seq sequence file to simulate CPU tests.
■ The ROM Test, RAM Test, Video Test, and Keyboard Test steps simulate
tests. Each of the diagnostic steps
■ The Powerup Diagnostics step, which is a Numeric Limit Test step,
simulates a power-up diagnostics test. Each of the five diagnostic steps that
follow the Powerup Diagnostics step specifies a precondition expression
that executes the step only when the corresponding test step fails.
■ The CPU Diagnostics step, which is a Sequence Call step, calls the
MainSequence in the CPU Diagnostic Sequence.seq sequence file to
simulate CPU diagnostics.
2. Select Execute»Single Pass to run the sequence.
3. When execution completes, review the report on the Report pane to see how
TestStand reports the passed and failed steps.
Related concepts:
■ TestStand Directory Structure
■
Step Groups
Computer Motherboard Test Sequence - LabWindows/CVI

94 ni.com
TestStand User Manual

Purpose
This example simulates the testing of a computer motherboard using test steps that
use the LabWindows/CVI Adapter.

Example File Location

<TestStand Public>\Examples\Demos\Computer Motherboard Test\CVI\Computer
Motherboard Test Sequence.seq

Highlighted Features
■ Flow Control step types
■ Preconditions
■ Sequence Call steps
■ Test step types

Major API
None

Note In order to debug the example code module, you must first rebuild
the source files in the debug configuration within LabWindows/CVI.

How to Use This Example

Complete the following steps to use this example.

1. On the Steps pane of the MainSequence, review the steps in the Setup step
group.
■ The Simulation Dialog step calls a DLL that launches a dialog box to
prompt you to select a test or tests you want to simulate to fail.
■ The Turn Vacuum Table On step, which is an Action step, simulates the
activation of a vacuum table. In the Cleanup step group, the Turn Vacuum
Table Off step deactivates the vacuum table.
2. On the Steps pane, review the steps in the Main step group.
■ The Powerup Test step, which is a Pass/Fail Test step, simulates a power-
up test, and the results of the step determine whether the following If/Else
structure continues testing or executes the Powerup Diagnostics step.
■ The CPU Test step, which is a Sequence Call step, calls the CPU Test
subsequence to simulate CPU tests.
■ The ROM Test, RAM Test, Video Test, and Keyboard Test steps simulate
tests, and if any test fails, the following If structure executes.
■ Each step in the If structure specifies a precondition expression that
executes the step only when the corresponding test step fails.
3. Select Execute»Single Pass to run the sequence.
4. In the Test Simulator dialog box, select the Power On test to fail.
5. When execution completes, review the report on the Report pane. The report
indicates that the test steps after the Powerup Test step did not execute, but
the Powerup Diagnostics step did execute.
6. Select Execute»Restart to run the sequence again.
7. In the Test Simulator dialog box, select any test other than the Power On test
to fail.
8. When execution completes, review the report. The report indicates that the
Powerup Test step passes and TestStand ran the remaining tests, and that
TestStand ran diagnostic steps for any failed test steps but skipped diagnostic
steps for any passed test steps.
Related concepts:
■ Programming with the TestStand API in LabWindows/CVI

96 ni.com
TestStand User Manual

■ TestStand Directory Structure

■ Step Groups
Computer Motherboard Test Sequence - LabVIEW

Purpose
This example simulates the testing of a computer motherboard using test steps that
use the LabVIEW Adapter.

Example File Location

<TestStand Public>\Examples\Demos\Computer Motherboard
Test\LabVIEW\Computer Motherboard Test Sequence.seq

Highlighted Features
■ Flow Control step types
■ Preconditions
■ Sequence Call steps
■ Test step types

Major API
None

Prerequisites
None

Note If you configure the LabVIEW adapter to use the development

system and then run the example, you may receive an error indicating that
the VIs are saved in a later version of LabVIEW. In this case, you can rebuild
the example VIs using the source project located in the source
subdirectory of the example directory. To rebuild the example files, open

the project and rebuild the source distribution in the build specifications
section.

How to Use This Example

Complete the following steps to use this example.
1. On the Steps pane of the MainSequence, review the steps in the Setup step
group.
■ The Simulation Dialog step calls a VI that launches a dialog box to prompt
you to select a test or tests you want to simulate to fail.
■ The Turn Vacuum Table On step, which is an Action step, simulates the
activation of a vacuum table. In the Cleanup step group, the Turn Vacuum
Table Off step deactivates the vacuum table.
2. On the Steps pane, review the steps in the Main step group.
■ The Powerup Test step, which is a Pass/Fail Test step, simulates a power-
up test, and the results of the step determine whether the following If/Else
structure continues testing or executes the Powerup Diagnostics step.
■ The CPU Test step, which is a Sequence Call step, calls the CPU Test
subsequence to simulate CPU tests.
■ The ROM Test, RAM Test, Video Test, and Keyboard Test steps simulate
tests, and if any test fails, the following If structure executes.
■ Each step in the If structure specifies a precondition expression that
executes the step only when the corresponding test step fails.
3. Select Execute»Single Pass to run the sequence.
4. In the Test Simulator dialog box, select the Power On test to fail.
5. When execution completes, review the report on the Report pane. The report
indicates that the test steps after the Powerup Test step did not execute, but
the Powerup Diagnostics step did execute.
6. Select Execute»Restart to run the sequence again.
7. In the Test Simulator dialog box, select any test other than the Power On test
to fail.

98 ni.com
TestStand User Manual

8. When execution completes, review the report. The report indicates that the
Powerup Test step passes and TestStand ran the remaining tests, and that
TestStand ran diagnostic steps for any failed test steps but skipped diagnostic
steps for any passed test steps.
Related concepts:
■
Programming with the TestStand API in LabVIEW
■ TestStand Directory Structure
■
Step Groups
Computer Motherboard Test Sequence - LabVIEW NXG

Purpose
This example simulates the testing of a computer motherboard using test steps that
use the LabVIEW NXG Adapter.

Example File Location

<TestStand Public>\Examples\Demos\Computer Motherboard Test\LabVIEW
NXG\Computer Motherboard Test Sequence.seq

Highlighted Features
■ Flow Control step types
■ Preconditions
■ Sequence Call steps
■ Test step types

Major API
None

Prerequisites
None

How to Use This Example

100 ni.com
TestStand User Manual

TestStand ran diagnostic steps for any failed test steps but skipped diagnostic
steps for any passed test steps.
Related concepts:
■ TestStand Directory Structure
■
Step Groups
Computer Motherboard Test Sequence - .NET

Purpose
This example simulates the testing of a computer motherboard using test steps that
use the .NET Adapter.

Example File Location

<TestStand Public>\Examples\Demos\Computer Motherboard
Test\DotNET\Computer Motherboard Test Sequence.seq

Highlighted Features
■ Flow Control step types
■ Preconditions
■ Sequence Call steps
■ Test step types

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to use this example.

© National Instruments 101

TestStand User Manual

1. On the Steps pane of the MainSequence, review the steps in the Setup step
group.
■ The Simulation Dialog step calls a .NET assembly that launches a dialog
box to prompt you to select a test or tests you want to simulate to fail.
■ The Turn Vacuum Table On step, which is an Action step, simulates the
activation of a vacuum table. In the Cleanup step group, the Turn Vacuum
Table Off step deactivates the vacuum table.
2. On the Steps pane, review the steps in the Main step group.
■ The Powerup Test step, which is a Pass/Fail Test step, simulates a power-
up test, and the results of the step determine whether the following If/Else
structure continues testing or executes the Powerup Diagnostics step.
■ The CPU Test step, which is a Sequence Call step, calls the CPU Test
subsequence to simulate CPU tests.
■ The ROM Test, RAM Test, Video Test, and Keyboard Test steps simulate
tests, and if any test fails, the following If structure executes.
■ Each step in the If structure specifies a precondition expression that
executes the step only when the corresponding test step fails.
3. Select Execute»Single Pass to run the sequence.
4. In the Test Simulator dialog box, select the Power On test to fail.
5. When execution completes, review the report on the Report pane. The report
indicates that the test steps after the Powerup Test step did not execute, but
the Powerup Diagnostics step did execute.
6. Select Execute»Restart to run the sequence again.
7. In the Test Simulator dialog box, select any test other than the Power On test
to fail.
8. When execution completes, review the report. The report indicates that the
Powerup Test step passes and TestStand ran the remaining tests, and that
TestStand ran diagnostic steps for any failed test steps but skipped diagnostic
steps for any passed test steps.
Related concepts:
■ TestStand Directory Structure

102 ni.com
TestStand User Manual

■ Step Groups
Computer Motherboard Test Sequence - Python

Purpose
This example simulates the testing of a computer motherboard using test steps that
use the Python Adapter.

Example File Location

<TestStand Public>\Examples\Demos\Computer Motherboard
Test\Python\Computer Motherboard Test Sequence.seq

Highlighted Features
■ Flow Control step types
■ Preconditions
■ Post Actions
■ Sequence Call steps
■ Test step types

Major API
None

Prerequisites
You must have the required version of CPython interpreter installed and added to
your PATH variable. You must update the Python version to use in the Python
Adapter Configuration dialog box before using the example.

How to Use This Example

Complete the following steps to use this example.

© National Instruments 103

TestStand User Manual

1. On the Steps pane of the MainSequence sequence, review the steps in the
Setup step group.
■ The Simulation Dialog step calls a CVI DLL that launches a dialog box to
prompt you to select a test or tests you want to simulate to fail.
■ The Initialize Computer Test step, which is an Action step, creates an
instance of a Python class that stores the settings the user specifies in the
simulation dialog. TestStand uses the instance of the class to call class
functions which do the testing.
■ The Turn Vacuum Table On step, which is an Action step, simulates the
activation of a vacuum table. In the Cleanup step group, the Turn Vacuum
Table Off step deactivates the vacuum table.
2. On the Steps pane, review the steps in the Main step group.
■ The Powerup Test step, which is a Pass/Fail Test step, simulates a power-
up test, and the results of the step determine whether the following If/Else
structure continues testing or executes the Powerup Diagnostics step.
■ The CPU Test step, which is a Sequence Call step, calls the CPU Test
subsequence to simulate CPU tests.
■ The ROM Test, RAM Test, Video Test, and Keyboard Test steps simulate
tests, and if any test fails, the following If structure executes.
■ Each step in the If structure specifies a precondition expression that
executes the step only when the corresponding test step fails.
3. Select Execute»Single Pass to run the sequence.
4. In the Test Simulator dialog box, select the Power On test to fail.
5. When execution completes, review the report on the Report pane. The report
indicates that the test steps after the Powerup Test step did not execute, but
the Powerup Diagnostics step did execute.
6. Select Execute»Restart to run the sequence again.
7. In the Test Simulator dialog box, select any test other than the Power On test
to fail.
8. When execution completes, review the report. The report indicates that the
Powerup Test step passes and TestStand ran the remaining tests, and that

104 ni.com
TestStand User Manual

TestStand ran diagnostic steps for any failed test steps but skipped diagnostic
steps for any passed test steps.
Related concepts:
■ TestStand Directory Structure
■
Step Groups

Mobile Device Test Demo

Purpose
This example simulates the testing of a cellular phone with test steps that use the
LabVIEW, LabWindows/CVI, and .NET Adapters.

Example File Location

<TestStand Public>\Examples\Demos\Mobile Device Test\Mobile Device Test.seq

Highlighted Features
■ Test step types
■ Flow Control step types
■ Report generation

Major API
None

Prerequisites
None

Note If you configure the LabVIEW adapter to use the development

© National Instruments 105

TestStand User Manual

the project and rebuild the source distribution in the build specifications
section.

How to Use This Example

Complete the following steps to review the sequences and steps in the example.
1. Select the MainSequence in the Sequences pane and review the following
steps in the Steps pane:
■ The Simulation Dialog step launches a dialog box to prompt you to select
a test or tests you want to simulate to fail.
■ Notice that the test steps are configured to use different adapters based
on the implementation of the code module.
2. Many of the tests are contained within a subsequence and are called using
sequence call steps. Double-click a sequence call step to view the
subsequence that it calls.
3. The code modules in this example implement simulated hardware calls and
test functionality. Navigate to the <TestStand
Public>\Examples\Demos\Mobile Device Test directory to view the source
code for the code modules.
Complete the following steps to run the example.
1. Select Execute»Single Pass to run the sequence.
2. Select a UUT configuration in the dialog box.
3. When execution completes, review the report on the Report pane. The report
for this example has been customized to demonstrate the following TestStand
features for report customization:
■ The audio and user input test steps use the additional results feature to
log the simulated data to the report.
■ The LCD Video and RF test steps use the ReportText field to log custom
HTML code that contains an image generated in the code module.
You can run this example using the Batch or Parallel process models. Complete the
following steps to run the example with a different process model.

106 ni.com
TestStand User Manual

1. Select Edit»Sequence File Properties.

2. On the Advanced tab, select Require Specific Model in the Model Option
field.
3. Select ParallelModel.seq or BatchModel.seq in the Model File control.
4. Click OK to close the dialog box.
5. Select Execute»Single Pass to run the sequence. Notice that multiple
instances of the test now execute.
Related concepts:
■ Programming with the TestStand API in LabVIEW
■ Programming with the TestStand API in LabWindows/CVI
■
TestStand Directory Structure

Parallel Test Strategies Demo

Purpose
This example demonstrates how you can use built-in parallel testing features to
improve test throughput. You can use the parallel or batch process models to test
multiple units in parallel on a single test station. TestStand provides a set of
synchronization steps to coordinate parallel and batch testing.
You can use the Auto Schedule step type to further improve the performance of
parallel tests by allowing TestStand to automatically reorder your test steps to
better utilize hardware resources.
This example shows the effects of using these features and how they can improve
the performance of your tests.

Example File Location

<TestStand Public>\Examples\Demos\Parallel Testing Strategies\Parallel Testing
Strategies.seq

Highlighted Features
■ Batch process model

© National Instruments 107

TestStand User Manual

■ Auto Schedule step type

Major API
None

Prerequisites
None

How to Use This Example

To begin the demo, select Execute»Run MainSequence.
When the example starts, a new window appears to show the simulated test steps,
the current instrument usage, and the total test time for each strategy so you can
compare performance. The demo contains the following strategies:
■ Sequential—In turn, each UUT performs a DMM test. Then, in turn, each
UUT performs a Scope test.
■ Parallel—In parallel, each UUT performs a DMM test and then a Scope test.
A UUT locks each instrument it uses to ensure that it has exclusive use of the
instrument.
■ Auto-Scheduled—In parallel, each UUT performs a DMM test and then a
Scope test. A UUT locks each instrument it uses to ensure that it has exclusive
use of the instrument. The order in which the UUT performs the test varies
depending on the availability of the instruments.
■ Parallel with Additional DMM—In parallel, each UUT performs a DMM
test using the first available DMM. Then, each UUT performs a Scope test. A
UUT locks each instrument it uses to ensure that it has exclusive use of the
instrument.
■ Auto-Scheduled with Additional DMM—In parallel, each UUT performs
a DMM test using the first available DMM. Then, each UUT performs a Scope
test. A UUT locks each instrument it uses to ensure that it has exclusive use of
the instrument. The order in which the UUT performs the tests varies
depending on the availability of the instruments.

108 ni.com
TestStand User Manual

Note The first time you execute this example, the auto-scheduled tests
might take longer to execute than the parallel tests due to components
specific to the example. In this case, running the example a second time
provides a more accurate representation of the performance differences.

Related concepts:
■
Parallel Process Model
■ Batch Process Model
■ TestStand Directory Structure

Examples for Fundamentals

The Fundamentals examples demonstrate key concepts for developing TestStand
systems. This directory includes the following example programs.

Calling Dynamic Dispatch VIs

Purpose
This example demonstrates how you can use dynamic dispatch with LabVIEW
classes directly from a TestStand sequence to implement a hardware abstraction
layer (HAL). In this approach, TestStand calls the implementation of each Class VI
corresponding to the class you select in the initial dialog.

Example File Location

<TestStand Public>\Examples\Fundamentals\Calling Dynamic Dispatch VIs\Calling
Dynamic Dispatch VIs.seq

Highlighted Features
■ LabVIEW Adapter - Class Member Call
■ Dynamic Dispatch

Major API
None

© National Instruments 109

TestStand User Manual

Prerequisites
The LabVIEW 2012 Run-Time engine or LabVIEW 2012 or higher development system
is required to execute this example. Dynamic dispatch support in TestStand requires
LabVIEW 2012 or higher.

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Single Pass to execute the sequence.
2. When prompted, select the DMM base class and click OK.
3. When the sequence completes, view the report. Notice that the report text
indicates the class used.
4. Select Execute»Single Pass to execute the sequence again.
5. When prompted, select one of the child classes and click OK.
6. When the sequence completes, view the report. Notice that the report text has
now changed because the steps called the specific VIs in the class you
selected.
Complete the following steps to review the sequences and steps in this example:
1. In MainSequence, select the Select Class VI. This VI returns a reference to a
different LabVIEW class based on the user selection. The VI can return the
parent DMM Base class, or one of two child classes—PCI-4070 or Simulated
DMM.

Note The Initialize, Read, and Close steps are configured using the
Class member call call type in order to call members of the Generic
DMM class. Based on the class selected previously, TestStand
dynamically selects the implementation of the class VI which
matches the class reference. This action allows the sequence to
behave differently based on the type of LabVIEW class reference
selected.

110 ni.com
TestStand User Manual

2. To view the implementation of the LabVIEW classes, open classes.prj, located

in <TestStand Public>\Examples\Fundamentals\Calling Dynamic Dispatch VIs.
Related concepts:
■ TestStand Directory Structure
■
Calling LabVIEW Class Member VIs from TestStand
■ Passing an Instance of a LabVIEW Class Object

Developing Platform Independent Test Systems

Purpose
This example demonstrates how you can create test sequences that can execute in
32-bit TestStand and 64-bit TestStand with no modifications.
The example uses the $(Platform) path macro in the module path to call the correct
version of a LabWindows/CVI DLL and a C++ DLL based on the current bitness of
TestStand.
The example uses a LabVIEW code module with the Separate Compiled Code from
source file option enabled so 32-bit LabVIEW and 64-bit LabVIEW can execute the VI.
The example assembly is built using the Any CPU configuration so that 32-bit
TestStand and 64-bit TestStand can call it.

Example File Location

<TestStand Public>\Examples\Fundamentals\Developing Platform Independent
Test Systems\Developing Platform Independent Test Systems.seq

Highlighted Features
■ $(Platform) path macro
■ Separate Compiled Code from Source File LabVIEW option
■ Any CPU Visual Studio Build Configuration setting

Major API
Engine.Is64Bit property

© National Instruments 111

TestStand User Manual

Prerequisites
None

How to Use This Example

Complete the following steps to run the example:
1. Select the CVI step or the C++ Action step. Observe that the $(Platform) path
macro is present in the Module path. This macro evaluates as win32 or x64 in
the resolved path based on the current TestStand bitness.
2. Select the .NET Action step and click Edit to open the VI. Notice that the
same code module path will be used for 32-bit TestStand and 64-bit
TestStand. Because the assembly is built using the Any CPU Visual Studio
Build Configuration Setting, the module can be called by either bitness of
TestStand.
3. If the LabVIEW development system is installed, select the LabVIEW Action
step and click Edit to open the VI. In LabVIEW, select File»VI Properties.
Notice that the Separate Compiled code from source file option is
enabled. This setting allows the same VI to execute in 32-bit LabVIEW and 64-
bit LabVIEW.
4. Observe that the IF statement uses the Engine.Is64Bit property to determine
the current bitness of TestStand. This property allows you to define different
behavior for 32-bit TestStand and 64-bit the bitness of TestStand.
5. Run the example and notice that the executed code module bitness matches
TestStand.
6. If possible, open the example in the other bitness of TestStand and observe
the difference in behavior.

Note This example uses a LabVIEW NXG code module, which is only
supported in 64-bit TestStand. To ensure the sequence file with LabVIEW
NXG code modules can be used in 32-bit TestStand, load the LabVIEW NXG
code module dynamically and execute the step only if Engine.Is64Bit
returns true.

112 ni.com
TestStand User Manual

Related concepts:
■ TestStand Directory Structure
■
Using the $(Platform) Path Macro to Locate the Correct Code Module in
32-bit TestStand and 64-bit TestStand
■
Executing VIs with Separate Compiled Code
■
AnyCPU Assemblies in 32-bit TestStand and 64-bit TestStand

Launching a Modal Dialog

The <TestStand Public>\Examples\Fundamentals\Launching a Modal Dialog
directory contains the following examples.
Related concepts:
■ TestStand Directory Structure
Launching a Modal Dialog - LabVIEW

Purpose
This example demonstrates how to use LabVIEW to create a dialog box that is modal
to the TestStand main application window.

Example File Location

<TestStand Public>\Examples\Fundamentals\Launching a Modal
Dialog\LabVIEW\Launching a Modal Dialog.seq

Highlighted Features
■ LabVIEW Adapter
■ Modal dialog boxes

Major API
None

© National Instruments 113

TestStand User Manual

Prerequisites
To run this example, you must have the LabVIEW development system installed.

Note The Modal Dialog palette VIs do not require the LabVIEW
development system. This requirement applies only to this example.

How to Use This Example

This example uses a LabVIEW Action step to call VIs configured to function as modal
dialog boxes, just as if the step were calling any other VI.
To review how the VI must be configured, open the dialog.vi located in the
<TestStand Public>\Examples\Fundamentals\Launching a Modal Dialog\LabVIEW
directory. In the VI, the modal dialog starts with the Start Modal Dialog VI and ends
with the End Modal Dialog VI. Each VI requires the sequence context from the calling
TestStand sequence.
Review the instructions documented on the block diagram of the example VI to
achieve proper functionality.
Related concepts:
■ TestStand Directory Structure
■
Programming with the TestStand API in LabVIEW
■ Making Dialog Boxes Modal to TestStand
■ Sequence Context
Launching a Modal Dialog - LabVIEW NXG

Purpose
This example demonstrates how to use LabVIEW NXG to create a dialog box that is
modal to the TestStand main application window.

114 ni.com
TestStand User Manual

Example File Location

<TestStand Public>\Examples\Fundamentals\Launching a Modal Dialog\LabVIEW
NXG\Launching a Modal Dialog.seq

Highlighted Features
■ LabVIEW NXG Adapter
■ Modal dialog boxes

Major API
None

Prerequisites
To run this example, you must have the LabVIEW NXG development system installed.

Note The Modal Dialog palette VIs do not require the LabVIEW NXG
development system. This requirement applies only to this example.

How to Use This Example

This example uses a LabVIEW NXG Action step to call VIs configured to function as
modal dialog boxes.
To review the configuration of the VI, click the edit VI button and observe the block
diagram.
Select modal option to activate the panel window. While the window is open, click
inside the window to ensure that it remains floating. The start modal dialog VI
disables user interaction with the TestStand User Interface. This VI uses the
SequenceContext reference and passes in from the sequence to identify the
TestStand application. The VI waits for the user to click the stop button. When the VI
stops, the end modal dialog reenables user interaction with the TestStand user
interface.

© National Instruments 115

TestStand User Manual

Review the code and execute the sequence file. When the dialog appears, try to
interact with the TestStand user interface. Observe that the TestStand user interface
is not responsive, and the dialog remains in front of the window. Click OK to dismiss
the dialog and observe that the TestStand user interface is again responsive.
Related concepts:
■
TestStand Directory Structure
■ Making Dialog Boxes Modal to TestStand
Launching a Modal Dialog - MFC

Purpose
This example demonstrates how to use C++ and the TestStand API to create a dialog
box that is modal to the TestStand main application window.

Example File Location

<TestStand Public>\Examples\Fundamentals\Launching a Modal
Dialog\MFC\Launching a Modal Dialog.seq

Highlighted Features
■ Modal dialog boxes
■ TestStand API

Major API
■ Engine.NotifyStartOfModalDialogEx
■ Engine.NotifyEndOfModalDialog

Prerequisites
C++ compiler

116 ni.com
TestStand User Manual

How to Use This Example

This example uses a C/C++ DLL Action step to call a function in a C++ DLL to create a
modal dialog box.
To review how the function behaves, open ExampleModalDlg.cpp located in the
<TestStand Public>\Examples\Fundamentals\Launching a Modal Dialog\MFC
directory. The function calls the Engine.NotifyStartOfModalDialogEx method, which
instructs the TestStand Engine that the DLL is creating a modal dialog box. After the
dialog box is dismissed, the function calls the Engine.NotifyEndOfModalDialog
method to end the modal dialog box state.
Related concepts:
■
TestStand Directory Structure
■ Making Dialog Boxes Modal to TestStand
■ Organizing Test Program Files with LabVIEW-Built Shared Libraries
Launching a Modal Dialog - .NET

Purpose
This example demonstrates how to use .NET and the TestStand API to create a
dialog box that is modal to the TestStand main application window.

Example File Location

<TestStand Public>\Examples\Fundamentals\Launching a Modal
Dialog\DotNet\Launching a Modal Dialog.seq

Highlighted Features
■ Modal dialog boxes
■ TestStand API

Major API
■ Engine.NotifyStartOfModalDialogEx

© National Instruments 117

TestStand User Manual

■ Engine.NotifyEndOfModalDialog

Prerequisites
None

How to Use This Example

This example uses a .NET Action step to call a function in a .NET DLL to create a
modal dialog box.
Related concepts:
■
TestStand Directory Structure
■ Making Dialog Boxes Modal to TestStand

Launching an MFC Dialog with ActiveX Controls

Purpose
This example demonstrates how to launch a Microsoft Foundation Classes (MFC)
dialog box that contains an ActiveX control when you call the MFC DLL from
TestStand.

Example File Location

<TestStand Public>\Examples\Fundamentals\Launching an MFC dialog With ActiveX
Controls\Launching an MFC dialog With ActiveX Controls.seq

Highlighted Features
Sequence Call step

Major API
N/A

118 ni.com
TestStand User Manual

Prerequisites
None

How to Use This Example

This example shows how to create and properly initialize a thread so it can launch
an MFC dialog box that contains ActiveX controls. TestStand must initialize all
execution threads for the ActiveX multithreaded concurrency model. MFC requires
that any thread that launches a dialog box that contains ActiveX controls must be
initialized as apartment-threaded. Therefore, to launch such a dialog box, you must
create a temporary worker thread you initialize as apartment-threaded and have the
worker launch the dialog box. Meanwhile, the original thread TestStand uses to call
the function must wait for the worker thread to exit.

Note When an MFC DLL launches a dialog box that contains an ActiveX
control and the DLL does not create a worker thread initialized as
apartment-threaded, you can call the DLL function from a TestStand
execution thread initialized as apartment-threaded. Use a Sequence Call
step to create a new thread and enable the Use Thread Apartment
setting in the Sequence Call Advanced Settings dialog box.

Related concepts:
■
TestStand Directory Structure

Overriding Engine Callbacks - SequenceFilePostStepFailure

Purpose
This example demonstrates how to retry or force failed steps to pass using the
SequenceFilePostStepFailure Engine callback sequence. You can force steps in the
MainSequence or in a subsequence.

© National Instruments 119

TestStand User Manual

Example File Location

<TestStand Public>\Examples\Fundamentals\Overriding Engine
Callbacks\Overriding SequenceFilePostStepFailure Callback.seq

Highlighted Features
Callbacks

Major API
Step.CancelStepCallback

Prerequisites
None

How to Use This Example

Complete the following steps to review the sequences and steps in this example.
1. On the Sequences pane, select the MainSequence. The MainSequence
contains two Numeric Limit Test steps and one Sequence Call step.
2. On the Sequences pane, select the SubSequence sequence. The
SubSequence sequence contains Numeric Limit Test steps, three of which are
designed to fail in the following ways to demonstrate how TestStand behaves
when a step fails:
■ One test fails only the first time
■ One test fails every time
■ One test fails every time but does not cause the sequence to fail
3. On the Sequences pane, select the SequenceFilePostStepFailure callback.
The first step, which uses the ActiveX/COM Adapter, sets the
Step.CancelStepCallback property to True to suppress any other failure
callbacks for a failed step, and a series of Statement steps collects information
about the step failure.

120 ni.com
TestStand User Manual

4. On the Steps pane, select the Choose Action step.

5. On the Step Settings pane, click the Text and Buttons tab. The Message
Expression control specifies an expression that provides information about
the step failure, and the step specifies buttons so you can choose to retry the
test, force the test to pass, continue the execution, or terminate the execution.
The Select step that follows the Choose Action step specifies the following
cases that correspond to the buttons you can click in the message popup that
the Choose Action step creates:
■ Case 1 changes the next step index to retry the step that failed
■ Case 2 forces the failed step to pass
■ Case 3 continues the sequence without taking any other action
■ Case 4 terminates the execution
Complete the following steps to run the example.
1. Select Execute»Single Pass to run the sequence.
2. TestStand launches the Step Failed dialog box for the first step that fails. Click
the Retry button to run the failed step again. The step passes on the second
attempt.
3. TestStand launches the Step Failed dialog box for the next step that fails. Click
the Force to Pass button to force the failed step to pass.
4. TestStand launches the Step Failed dialog box for the next step that fails. Click
the Continue button to allow the step to fail without causing the sequence
fail.
5. When execution completes, review the report on the Report pane. The status
of the first attempt of the Fail only the first time step is Failed, Retrying Step
because you clicked the Retry button after the step failed once. The status of
the Fail every time step is Passed because you clicked the Force to Pass
button when the step failed.
Related concepts:
■ TestStand Directory Structure
■
Callback Sequences

© National Instruments 121

TestStand User Manual

Overriding Engine Callbacks -

SequenceFilePostStepRuntimeError
Purpose
This example demonstrates how to handle run-time errors using the
SequenceFilePostStepRuntimeError Engine callback sequence.

Example File Location

<TestStand Public>\Examples\Fundamentals\Overriding Engine
Callbacks\Overriding SequenceFilePostStepRuntimeError Callback.seq

Highlighted Features
Callbacks

Major API
Step.CancelStepCallback

Prerequisites
None

How to Use This Example

122 ni.com
TestStand User Manual

3. On the Sequences pane, select the SequenceFilePostStepRuntimeError

callback. The first step, which uses the ActiveX/COM Adapter, sets the
Step.CancelStepCallback property to True to suppress any other failure
callbacks for a failed step.
4. On the Steps pane, select the Choose Action step.
5. On the Step Settings pane, click the Text and Buttons tab. The Message
Expression control specifies an expression that provides information about
the step that caused the run-time error, and the step specifies buttons so you
can choose to retry the test, ignore the error, continue to the Cleanup step
group, or terminate the execution. The Select step that follows the Choose
Action step specifies the following cases that correspond to the buttons you
can click in the message popup that the Choose Action step creates:
■ Case 1 ignores the error and changes the next step index to retry the step
that caused the error
■ Case 2 ignores the error and specifies the step status as Error Suppressed.
■ Case 3 sets the RunState.Caller.Runstate.ErrorReported flag to True to
prevent TestStand from displaying a run-time error dialog box because has
already reported the error
■ Case 4 sets the RunState.Caller.Runstate.ErrorReported flag to True to
prevent TestStand from displaying a run-time error dialog box because has
already reported the error and then terminates the execution
Complete the following steps to run the example.
1. Select Execute»Single Pass to run the sequence.
2. TestStand launches the Error dialog box for the first step that causes a run-
time error. Click the Retry button to run the step again. The step passes on
the second attempt.
3. TestStand launches the Error dialog box for the next step that causes a run-
time error. Click the Ignore Error button to continue executing the sequence.
4. When execution completes, review the report on the Report pane. The status
of the first attempt of the Generate a run-time error only the first time step is
Error, Retrying Step because you clicked the Retry button after the step
caused a run-time error once. The status of the Generate a run-time error

© National Instruments 123

TestStand User Manual

every time step is Error Suppressed because you clicked the Ignore Error
button when the step caused a run-time error.
Related concepts:
■
TestStand Directory Structure
■ Callback Sequences
■
Step Groups

Passing Clusters to Code Modules - LabVIEW

This example demonstrates how to pass a TestStand container as a LabVIEW cluster
to a LabVIEW VI. The container consists of several different data types. The VIs are
compiled into a DLL and called as functions.

Example File Location

<TestStand Public>\Examples\Fundamentals\Passing Clusters to Code
Modules\Passing Clusters to Code Modules.seq

Highlighted Features
■ Data types
■ LabVIEW Adapter
■ Local variables

Major API
None

Prerequisites
You do not need to have the LabVIEW development system installed to use this
example, but you must have the LabVIEW development system installed if you want
to review the source VIs.

124 ni.com
TestStand User Manual

How to Use This Example

The sequence specifies ContainerOut and ContainerIn container local variables,
which you can review on the Variables pane. When the sequence runs, TestStand
copies the values in the ContainerOut container to the individual local variables,
and then copies the values again to the ContainerIn container. A VI handles both
operations. Before you run the sequence, the ContainerOut container contains
values, the ContainerIn container contains default values, and the individual local
variables contain default values.
Complete the following steps to use this example.
1. Select Execute»Test UUTs to run the sequence.
2. Enter any serial number in the UUT Information dialog box and click OK.
TestStand launches a Results for Unbundle dialog box that lists values loaded
from the individual local variables, which specified default values before you
executed the sequence.
3. Click OK in the Results for Unbundle dialog box. TestStand launches another
Results for Unbundle dialog box that lists values loaded from the ContainerIn
container, which specified default values before you executed the sequence.
4. Click OK when TestStand informs you that the sequence passed.
5. Click Stop in the UUT Information dialog box to end the execution.
You can review the two Message Popup steps in the sequence to verify that the
appropriate sources are providing values. You can open VI1.vi and VI2.vi, located in
the <TestStand Public>\Examples\Fundamentals\Passing Clusters to Code Modules
directory, to see how the data is being copied. The VI1.vi uses an unbundle function
to separate the values from the cluster, and the VI2.vi uses a bundle function to
combine individual values into a single cluster.
To pass a TestStand container as a cluster to a VI, you must complete the following
tasks:
■ Define the container as a custom data type.
■ Specify that objects of the data type can be passed as clusters.
■ Ensure that the Cluster Item Label for each item in the data type matches
the label of the LabVIEW cluster.

© National Instruments 125

TestStand User Manual

Complete the following steps to use the Types window to review the data type
definition for a container.
1. In the Sequence File window, right-click the ContainerIn container on the
Variables pane and select View»Type Definition from the context menu to
launch the Types window.
2. Right-click the ClusterType data type and select Properties from the context
menu to launch the Type Properties dialog box. Because the sequence is using
a VI, you must enable cluster passing for the data type.
3. Click the Cluster Passing tab. Notice that the Allow Objects of This Type to be
Passed as LabVIEW Clusters option is enabled. The Cluster Item Label option
for each item matches the control labels in the VI.
4. Click OK to close the Type Properties dialog box.
Related concepts:
■ TestStand Directory Structure
■ Standard and Custom Data Types
■
Programming with the TestStand API in LabVIEW
■ Sequence Local Variables

Passing Structs to Code Modules

The <TestStand Public>\Examples\Fundamentals\Passing Structs to Code Modules
directory contains the following examples.
Related concepts:
■ TestStand Directory Structure
Passing Structs to Code Modules - C

Purpose
This example demonstrates how to pass a TestStand container as a C-style struct to
a function in a DLL. This example uses functions to pass the struct by both reference
and value. For a DLL function to change the value of a TestStand container, you must
pass the reference of the container to the function.

126 ni.com
TestStand User Manual

Note When you configure the container as a custom data type, be aware
of the byte-packing the DLL function uses.

Example File Location

<TestStand Public>\Examples\Fundamentals\Passing Structs to Code
Modules\C\Passing Structs to Code Modules.seq

Highlighted Features
■ Calling DLLs from TestStand
■ C/C++ DLL Adapter
■ Local variables
■ Data types

Major API
None

Prerequisites
C compiler or DLL

How to Use This Example

The sequence specifies sPacked8Out and sPacked8In container local variables,
which you can review on the Variables pane. The sequence uses a C DLL to copy the
values from the sPacked8Out container to the sPacked8In container first by
reference and then by value.
Complete the following steps to use this example.
1. Select Execute»Test UUTs to run the sequence.
2. Enter any serial number in the UUT Information dialog box and click OK.
TestStand launches a Get Results dialog box that lists values loaded from the

© National Instruments 127

TestStand User Manual

sPacked8In container, which specified default values before you executed the
sequence.
3. Click OK in the Get Results dialog box. TestStand launches another Get
Results dialog box that lists values loaded from the sPacked8In container. The
GetStructByRef2 step specifies a pre-expression that specifies a value of 0 for
each variable, and then the GetStructByRef2 step specifies new values for
each variable.
4. Click OK when TestStand informs you that the sequence passed.
5. Click Stop in the UUT Information dialog box to end the execution.
You can review the two Message Popup steps in the sequence to verify that the
sPacked8In container is displaying the variable values. The functions the DLL is
using are available in StructTest.cpp, located in the <TestStand
Public>\Examples\Fundamentals\Passing Structs to Code Modules\C directory.
To pass a TestStand container as a struct to a DLL, you must define the container as
a custom data type, and you must specify that objects of the data type can be
passed as structs.
Complete the following steps to use the Types window to review the data type
definition for a container.
1. In the Sequence File window, right-click the sPacked8In container on the
Variables pane and select View»Type Definition from the context menu to
launch the Types window.
2. Right-click the AllDataTypesPacked8 data type and select Properties from
the context menu to launch the Type Properties dialog box. Because the
sequence is using a DLL, you must enable C struct passing for the data type.
3. Click the C Struct Passing tab. Notice that the Allow Objects of This Type to be
Passed as Structs option is enabled. The Packing ring control specifies the 8
Byte Boundary option, which is the packing scheme the DLL uses.
4. Click OK to close the Type Properties dialog box.
5. In the Types window, expand the AllDataTypesPacked8 data type. You can
right-click each property and select Properties from the context menu to
launch the Type Properties dialog box for each property of the data type. You
can review each property to see how it is configured.

128 ni.com
TestStand User Manual

Related concepts:
■ TestStand Directory Structure
■
Calling DLLs from TestStand
■ Organizing Test Program Files with LabVIEW-Built Shared Libraries
■
Sequence Local Variables
■
Standard and Custom Data Types
Passing Structs to Code Modules - LabWindows/CVI

Purpose
This example demonstrates how to pass a TestStand container as a C-style struct to
a function in a LabWindows/CVI DLL. The container consists of several different data
types. For a DLL function to change the value of a TestStand container, you must
pass the reference of the container to the function.

Note When you configure the container as a custom data type, be aware
of the byte-packing the DLL function uses. The default packing scheme in
LabWindows/CVI can be either 1- or 8-byte, depending on the
compatibility mode.

Example File Location

<TestStand Public>\Examples\Fundamentals\Passing Structs to Code
Modules\CVI\Passing Structs to Code Modules.seq

Highlighted Features
■ LabWindows/CVI Adapter
■ Local variables
■ Data types

Major API
None

© National Instruments 129

TestStand User Manual

How to Use This Example

The sequence specifies a CVIStruct container local variable, which you can review on
the Variables pane. When the sequence runs, TestStand copies the values in the
CVIStruct container to the individual local variables, and then assigns new values to
the CVIStruct container. The LabWindows/CVI DLL handles both operations. Before
you run the sequence, the CVIStruct container contains values, and the individual
local variables contains default values.
Complete the following steps to use this example.
1. Select Execute»Test UUTs to run the sequence.
2. Enter any serial number in the UUT Information dialog box and click OK.
TestStand launches a Results for Unpacking dialog box that lists values loaded
from the CVIStruct container and assigned to the individual local variables.
3. Click OK in the Results for Unpacking dialog box. TestStand launches another
Results dialog box that lists values modified and saved back to the CVIStruct
container.
4. Click OK when TestStand informs you that the sequence passed.
5. Click Stop in the UUT Information dialog box to end the execution.
You can review the two Message Popup steps in the sequence to verify that the
appropriate sources are providing values. You can open CVIStructTestSource.c,
located in the <TestStand Public>\Examples\Fundamentals\Passing Structs to Code
Modules\CVI directory, to see how the data is being copied. The
PassStructAndUnpack method accesses the values in the CVIStruct container and
assigns the values to the individual method parameters. The PassStructAndModify
method assigns arbitrary values to the elements of the CVIStruct container by
reference. These assignments modify the container in TestStand. The sequence is

130 ni.com
TestStand User Manual

using CVIStructTest.dll, into which the PassStructAndUnpack and

PassStructAndModify methods were built.
To pass a TestStand container as a struct to a DLL, you must define the container as
a custom data type, and you must specify that objects of the data type can be
passed as structs.
Complete the following steps to use the Types window to review the data type
definition for a container.
1. In the Sequence File window, right-click the CVIStruct container on the
Variables pane and select View»Type Definition from the context menu to
launch the Types window.
2. Right-click the CVIStructExample data type and select Properties from the
context menu to launch the Type Properties dialog box. Because the sequence
is using a DLL, you must enable C struct passing for the data type.
3. Click the C Struct Passing tab. Notice that the Allow Objects of This Type to be
Passed as Structs option is enabled. The Packing ring control specifies the
Default Adapter Packing option, which is the packing scheme the
LabWindows/CVI DLL uses.
4. Click OK to close the Type Properties dialog box.
5. In the Types window, expand the CVIStructExample data type. You can right-
click each property and select Properties from the context menu to launch
the Type Properties dialog box for each property of the data type. You can
review each property to see how it is configured.
Related concepts:
■ TestStand Directory Structure
■
Programming with the TestStand API in LabWindows/CVI
■ Sequence Local Variables
■
Standard and Custom Data Types
Passing Structs to Code Modules - LabVIEW DLL

© National Instruments 131

TestStand User Manual

Purpose
This example demonstrates how to pass a TestStand container as a LabVIEW cluster
to a LabVIEW VI. The container consists of several different data types. The VIs are
compiled into a DLL and called as functions.

Note VIs always use a 1-byte packing scheme when passing clusters as
parameters.

Example File Location

<TestStand Public>\Examples\Fundamentals\Passing Structs to Code
Modules\LabVIEW DLL\Passing Structs to Code Modules.seq

Highlighted Features
■ LabVIEW Adapter
■ Local variables
■ Data types

Major API
None

Prerequisites
You do not need to have the LabVIEW development system installed to use this
example, but you must have the LabVIEW development system installed if you want
to review the source VIs.

How to Use This Example

The sequence specifies StructOut and StructIn container local variables, which you
can review on the Variables pane. When the sequence runs, TestStand copies the
values in the StructOut container to the individual local variables, and then copies

132 ni.com
TestStand User Manual

the values again to the StructIn container. The LabVIEW DLL handles both
operations. Before you run the sequence, the StructOut container contains values,
the StructIn container contains default values, the individual local variables
contains default values.
Complete the following steps to use this example.
1. Select Execute»Test UUTs to run the sequence.
2. Enter any serial number in the UUT Information dialog box and click OK.
TestStand launches a Results for Unbundle dialog box that lists values loaded
from the individual local variables, which specified default values before you
executed the sequence.
3. Click OK in the Results for Unbundle dialog box. TestStand launches another
Results for Unbundle dialog box that lists values loaded from the StructIn
container, which specified default values before you executed the sequence.
4. Click OK when TestStand informs you that the sequence passed.
5. Click Stop in the UUT Information dialog box to end the execution.
You can review the two Message Popup steps in the sequence to verify that the
appropriate sources are providing values. You can open LV DLL 1.vi and LV DLL 2.vi,
located in the <TestStand Public>\Examples\Fundamentals\Passing Structs to Code
Modules\LabVIEW DLL directory, to see how the data is being copied. The LV DLL 1.vi
uses an unbundle function to separate the values from the cluster, and the LV DLL
2.vi uses a bundle function to combine individual values into a single cluster. The
sequence is using LVStructTest.dll, into which LV DLL 1.vi and LV DLL 2.vi were built.
To pass a TestStand container as a struct to a DLL, you must define the container as
a custom data type, and you must specify that objects of the data type can be
passed as structs.
Complete the following steps to use the Types window to review the data type
definition for a container.
1. In the Sequence File window, right-click the StructIn container on the
Variables pane and select View»Type Definition from the context menu to
launch the Types window.

© National Instruments 133

TestStand User Manual

2. Right-click the DType1 data type and select Properties from the context
menu to launch the Type Properties dialog box. Because the sequence is using
a DLL, you must enable C struct passing for the data type.
3. Click the C Struct Passing tab. Notice that the Allow Objects of This Type to be
Passed as Structs option is enabled. The Packing ring control specifies the 8
Byte Boundary option, which is the packing scheme the DLL uses.
4. Click OK to close the Type Properties dialog box.
5. In the Types window, expand the DType1 data type. You can right-click each
property and select Properties from the context menu to launch the Type
Properties dialog box for each property of the data type. You can review each
property to see how it is configured.
Related concepts:
■
TestStand Directory Structure
■ Programming with the TestStand API in LabVIEW
■
Sequence Local Variables
■ Standard and Custom Data Types
Passing Structs to Code Modules - .NET

Purpose
This example demonstrates how to pass a TestStand container as a .NET struct to a
method in an assembly. This example uses functions to pass the struct by both
reference and value. For a method in an assembly to change the value of a
TestStand container, you must pass the reference of the container to the method.

Example File Location

<TestStand Public>\Examples\Fundamentals\Passing Structs to Code
Modules\DotNet\Passing Structs to Code Modules.seq

Highlighted Features
■ .NET Adapter

134 ni.com
TestStand User Manual

■ Local variables
■ Data types

Major API
None

Prerequisites
None

How to Use This Example

The sequence specifies StructOut and StructIn container local variables, which you
can review on the Variables pane. The sequence uses a .NET method to copy the
values from the StructOut container to the StructIn container first by reference and
then by value.
Complete the following steps to use this example.
1. Select Execute»Test UUTs to run the sequence.
2. Enter any serial number in the UUT Information dialog box and click OK.
TestStand launches a Get Results dialog box that lists values loaded from the
StructIn container, which specified default values before you executed the
sequence.
3. Click OK in the Get Results dialog box. TestStand launches another Get
Results dialog box that lists values loaded from the StructIn container. The
second GetStructByRef step specifies a pre-expression that specifies a value of
0 for each variable, and then the step specifies new values for each variable.
4. Click OK when TestStand informs you that the sequence passed.
5. Click Stop in the UUT Information dialog box to end the execution.
You can review the two Message Popup steps in the sequence to verify that the
StructIn container is displaying the variable values. The methods the assembly is
using are available in StructPassingDotNet.dll, located in the <TestStand

© National Instruments 135

TestStand User Manual

Public>\Examples\Fundamentals\Passing Structs to Code Modules\DotNet

directory.
Related concepts:
■ TestStand Directory Structure
■
Sequence Local Variables
■ Standard and Custom Data Types

Pausing Executions with Running Code Modules

The <TestStand Public>\Examples\Fundamentals\Pausing Executions with Running
Code Modules directory contains the following examples.
Related concepts:
■
TestStand Directory Structure
Pausing Executions with Running Code Modules - LabWindows/CVI

Purpose
A TestStand execution cannot break until all threads within the execution have been
suspended. If one or more threads in the execution is running a code module, the
execution will not break until all code modules complete.
This example demonstrates two methods you can use to override this behavior:
■ The Thread.ExternallySuspended property, which if set to True, allows an
execution to be suspended even if the current thread is still executing a code
module. You can use this option to configure the execution pausing behavior
on a per code module basis.
■ The Allow Break While in Code Modules station option, which allows any
execution to be suspended even if one or more threads is still executing a
code module. This setting is located in the Execution tab of the Station
Options dialog. You can set this option at run-time, as shown in this example.
The example also demonstrates how you can poll the TestStand execution status
within a code module and respond when the execution pauses.

136 ni.com
TestStand User Manual

Example File Location

<TestStand Public>\Examples\Fundamentals\Pausing Executions with Running
Code Modules\CVI\Pausing Executions with Running Code Modules.seq

Highlighted Features
Debugging TestStand Executions

Major API
Thread.ExternallySuspended

Prerequisites
None

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Run MainSequence to execute the sequence.
2. This example shows three configuration cases. For each case, the code
module dialog indicates the current settings for the
Thread.ExternallySuspended property and the Allow Break While in
Code Modules station option.
3. In case one, observe that the TestStand execution does not pause when it
reaches the break step. The code module also continues executing.
4. After you dismiss the dialog, the execution will pause. Click the Resume
button or press F5 to resume the execution.
5. In cases two and three, the execution is able to pause successfully, and the
code module pauses the simulated testing operation. If you resume the
execution in TestStand while the module is still running, observe that the
module resumes testing.
Related concepts:

© National Instruments 137

TestStand User Manual

■ TestStand Directory Structure

■ Debugging Executions
Pausing Executions with Running Code Modules - LabVIEW

Example File Location

<TestStand Public>\Examples\Fundamentals\Pausing Executions with Running
Code Modules\LabVIEW\Pausing Executions with Running Code Modules.seq

Highlighted Features
Debugging TestStand Executions

Major API
Thread.ExternallySuspended

138 ni.com
TestStand User Manual

Prerequisites
You must have the LabVIEW development system installed and configure the
LabVIEW Adapter to use the LabVIEW development system.

How to Use This Example

© National Instruments 139

TestStand User Manual

■ The Thread.ExternallySuspended property, which if set to True, allows an

execution to be suspended even if the current thread is still executing a code
module. You can use this option to configure the execution pausing behavior
on a per code module basis.
■ The Allow Break While in Code Modules station option, which allows any
execution to be suspended even if one or more threads is still executing a
code module. This setting is located in the Execution tab of the Station
Options dialog. You can set this option at run-time, as shown in this example.
The example also demonstrates how you can poll the TestStand execution status
within a code module and respond when the execution pauses.

Example File Location

<TestStand Public>\Examples\Fundamentals\Pausing Executions with Running
Code Modules\DotNet\Pausing Executions with Running Code Modules.seq

Highlighted Features
Debugging TestStand Executions

Major API
Thread.ExternallySuspended

Prerequisites
None

How to Use This Example

140 ni.com
TestStand User Manual

Thread.ExternallySuspended property and the Allow Break While in

Code Modules station option.
3. In case one, observe that the TestStand execution does not pause when it
reaches the break step. The code module also continues executing.
4. After you dismiss the dialog, the execution will pause. Click the Resume
button or press F5 to resume the execution.
5. In cases two and three, the execution is able to pause successfully, and the
code module pauses the simulated testing operation. If you resume the
execution in TestStand while the module is still running, observe that the
module resumes testing.
Related concepts:
■ TestStand Directory Structure
■ Debugging Executions

Interpreter Session Management in Python

Purpose
The example will showcase how to use different Python interpreter sessions in a
single execution.

Example File Location

<TestStand Public>Examples\Fundamentals\Python\Interpreter Session
Management\Interpreter Session Management Sequence.seq

Highlighted Features
■ Python Interpreter Session Management

Major API
None

© National Instruments 141

TestStand User Manual

Prerequisites
You must have required version of CPython interpreter installed and added to your
PATH variable. You must update the Python version to use in the Python adapter
configuration dialog before using the example.

How to Use This Example

Complete the following steps to use this example.
1. On the Steps pane of the MainSequence sequence, review the steps in the
Setup step group.
■ The first step, Update Python version to use in all steps, updates the
Python version in each step to use the version specified in Python adapter
settings. You typically will not do this for an actual test and should instead
directly specify the Python version to use in the steps that use the Python
adapter. This example can't determine the Python version installed in the
computer and therefore modifies the Python version of each step
programmatically to match what is specified in the Python adapter settings.
2. On the Steps pane, review the steps in the Main step group.
■ The Global interpreter session step, which is a Sequence Call step, call the
Global subsequence two times to demonstrate Python global interpreter
session.
■ The Per Thread interpreter session, which is a Sequence Call step, call the
Per Thread subsequence three times on a separate thread to demonstrate
Python per thread interpreter session.
■ The Wait for Thread Return step, which is a Wait step, waits for execution
completion of the Per Thread subsequence on a separate thread.
■ The Per Execution interpreter session, which is a Sequence Call step, call
the Per Execution subsequence on a new execution instance to demonstrate
Python per execution interpreter session.
■ The Wait for Executions to Return step, which is a Wait step, waits for
execution completion of the Per Execution subsequence on a separate
execution instance.

142 ni.com
TestStand User Manual

■ The Object Reference interpreter session step, which is a Sequence Call

step, call the Object Reference subsequence to demonstrate Python object
reference interpreter session.
3. The Global, Per Thread, Per Execution, and Object Reference subsequence
gets and sets Python attribute in the code module.
4. The Result step in Global, Per Thread, Per Execution, and Object Reference
subsequence, which is an Additional Results step, summarizes the results in
the report.
5. Select Execute»Single Pass to run the sequence.
6. When execution completes, review the report to see the how different
interpreter sessions maintain independence from each other.
Related concepts:
■ TestStand Directory Structure
■ Step Groups

Passing Data between TestStand and Python

Purpose
This example demonstrates how you can pass TestStand data types to Python code
modules.

Example File Location

<TestStand Public>Examples\Fundamentals\Python\Passing Data to
Python\Passing Data to Python.seq

Highlighted Features
■ Mapping of Python and TestStand types

Major API
None

© National Instruments 143

TestStand User Manual

Prerequisites
Complete the following steps to install the required software and configure
TestStand.
1. Install a supported version of the CPython interpreter and add it to your PATH
variable.
2. Install the following libraries for the version of Python you installed:
■ Python for Win32 (pywin32) extensions
■ NumPy module (required for the NumPy Array example)
3. In the Python Adapter Configuration dialog box, update the Python version
TestStand uses to execute Python code modules.

Note To run the example for Enums, you must use Python 3.6 or
higher.

How to Use This Example

Note The example simulates the testing of a UUT. The Model type, serial
number, ports and voltage values in the example are hypothetical. The
methods in the classes UUTInterface and UUTDatabase in the Python
module are template methods and do not interface with any hardware or
database.

Review the sequences and steps in this example. Select a subsequence in the
Sequences pane to view steps in the subsequence.

Sequence Call step in Subsequence the step Purpose Details

the MainSequence calls
sequence
Working with Number Number Demonstrates passing The subsequence has
numbers (integers and four sections that
real) between demonstrate adding,
subtracting,

144 ni.com
TestStand User Manual

Sequence Call step in Subsequence the step Purpose Details

the MainSequence calls
sequence
TestStand and the multiplying, and
Python module. dividing two TestStand
numbers in the Python
module. The four
sections, delineated by
Label steps, use 64-bit
signed integers, 64-bit
unsigned integers, 64-
bit double-precision
floating-point number,
and float and integer
together respectively.
An Additional Results
step completes each
section to provide a
summary of the results.
Working with Boolean Boolean Demonstrates passing The subsequence
Boolean data between demonstrates the
TestStand and the inversion of the
Python module. Boolean state of a
TestStand variable in a
Python module. An
Additional Results step
provides a summary of
the results.
Working with String String Demonstrates passing The subsequence
string data between demonstrates the
TestStand and the concatenation of two
Python module. TestStand strings in a
Python module. An
Additional Results step
provides a summary of
the results.
Working with List List Demonstrates passing The subsequence
data between demonstrates different
TestStand arrays and operations, such as
Python lists. sorting and converting
array data to string

© National Instruments 145

TestStand User Manual

Sequence Call step in Subsequence the step Purpose Details

the MainSequence calls
sequence
data, the Python
module performs on
TestStand array data.
Working with Tuple Tuple Demonstrates passing The subsequence
data between retrieves a single
TestStand containers element from a
and Python tuples. TestStand container
using a Python module,
sets a Python attribute
as a tuple using a
TestStand container,
and inserts a Python
tuple attribute into a
TestStand container.
Working with PyObject PyObject Demonstrates passing The Setup step group
data between contains the following
TestStand object steps:
references and Python ■ The Create
objects (PyObject).
UUTInterface
Object step and
the Initialize
Database step
obtain the
references to the
instances of the
Python classes
that are
instantiated in
the Python
module.
TestStand stores
the references in
TestStand object
reference
variables. Steps
in the Main and
Cleanup step

146 ni.com
TestStand User Manual

Sequence Call step in Subsequence the step Purpose Details

the MainSequence calls
sequence
groups will use
these references.
The Main step group
contains the following
steps:
■ The Get UUT
Model Type step,
which is an
action step, gets
the value in the
static attribute of
the Python class
UUTInterface.
■ The Get UUT
Serial Number
step, which is an
action step, gets
the value of the
attribute
serialNumber
from the object
of the class
UUTInterface,
whose reference
was obtained
earlier.
■ The Create
UUT Record in
Database step,
which is an
action step, calls
the createRecord
method in the
class instance
object of Python
class
UUTDatabase,

© National Instruments 147

TestStand User Manual

Sequence Call step in Subsequence the step Purpose Details

the MainSequence calls
sequence
whose reference
was obtained
earlier.
■ The Powerup
UUT step, which
is an action step,
calls the
PowerupUUT
method in the
class instance
object of the
Python class
UUTInterface
whose reference
was obtained
earlier.
■ The UUT String
Value Test step
validates the
serial number of
the UUTInterface
object.
■ The UUT
Multiple Numeric
Limit Test step
validates the
range of ports
assigned to the
UUTInterface
object.
■ The UUT
Numeric Limit
Test step
validates the
voltage read by
the UUTInterface
object.

148 ni.com
TestStand User Manual

Sequence Call step in Subsequence the step Purpose Details

the MainSequence calls
sequence
■ The UUT Pass/
Fail Test step
validates the test
result of the
UUTInterface
object.

Working with Dispatch Dispatch Demonstrates passing The Main step group
TestStand objects and contains the following
COM objects Action steps:
implementing ■ The Pass
IDispatch between
Sequence
TestStand and the
Context as
Python module.
Parameter step
passes the
SequenceContext
object as a
parameter to the
Python code
module.
■ The Pass
Engine as
Parameter step
passes the
Engine property
as a parameter to
the Python code
module.
■ The Pass COM
Object as
Parameter step
passes the COM
object, whose
reference is held
in an object
reference
variable.

© National Instruments 149

TestStand User Manual

Sequence Call step in Subsequence the step Purpose Details

the MainSequence calls
sequence
The Pre-
Expression of the
step makes the
object reference
variable hold a
reference to a
PropertyObject,
which is a COM
object. When the
step uses the
object reference
variable as a
parameter, it
passes the COM
object held by
the variable to
the Python code
module.

Working with Enum Enum Demonstrates passing The Main step group
enumerations between contains the following
TestStand and the Action steps:
Python module. ■ The Pass Enum
Color step passes
the TestStand
enum as a
Python enum
parameter with a
type of Enum to
the Python code
module.
■ The Pass Flag
Measurement
step passes the
TestStand enum
as a Python
enum parameter
with a type of

150 ni.com
TestStand User Manual

Sequence Call step in Subsequence the step Purpose Details

the MainSequence calls
sequence
Flag to the
Python code
module.
■ The Pass
IntEnum
FileOpenOption
step passes the
TestStand enum
as a Python
enum parameter
with a type of
IntEnum to the
Python code
module.
■ The Pass
IntFlag
FilePermission
step passes the
TestStand enum
as a Python
enum parameter
with a type of
IntFlag to the
Python code
module.

Working with NumPy NumPy Array Demonstrates passing The subsequence

Array data between a demonstrates passing
TestStand array and a TestStand arrays to a
Python NumPy array. Python module and
performing a sorting
operation using NumPy
arrays.
Complete the following steps to run the example.
1. Click Execute»Single Pass to run the sequence.
2. When execution completes, review the report.

© National Instruments 151

TestStand User Manual

Related concepts:
■ TestStand Directory Structure

Sequence File Translators

Purpose
This example demonstrates how to create and use a sequence file translators, which
is a DLL that TestStand uses to load sequence files in custom formats. A translator
implements a set of required callbacks that TestStand invokes to determine the
types of files the translator can open and to load a custom file as a TestStand
sequence file. You can use translators to open files in custom formats. Once
TestStand loads a custom file as a TestStand sequence file, you can operate on the
file like any other TestStand sequence file. However, you cannot save changes in the
TestStand sequence file back to the original format.
The example directory contains projects for example translators written in LabVIEW,
LabWindows/CVI, and Microsoft Visual C++. The examples illustrate translating text
and XML files and contain a template project you can use to develop a translator in
each development environment. Each example can translate the corresponding text
or XML file located in the same directory as the example.

Example File Location

<TestStand Public>\Examples\Fundamentals\Sequence File Translators -
Examples\SetupExampleTranslators.seq

Highlighted Features
Sequence file translators

Major API
N/A

152 ni.com
TestStand User Manual

Prerequisites
Before you attempt to open a file in a custom format, you must install the example
translator DLL and support files to the appropriate directories in one of the
following ways:
■ Automatic Installation (recommended)—Open the
SetupExampleTranslators.seq example sequence file and run the
MainSequence to select the examples to set up.
■ Manual Installation—Complete the following steps to manually move the
translator DLL and support files:
1. Open the TextTranslator or XMLTranslator directory for one of the
examples in the <TestStand Public>\Examples\Fundamentals\Sequence
File Translators - Examples directory, and copy the translator DLL from
the selected directory to the <TestStand
Public>\Components\Translators directory.
2. Copy the NI_ExampleTranslatorTypes.ini type file from the <TestStand
Public>\Examples\Fundamentals\Sequence File Translators - Examples
directory to the <TestStand Public>\Components\TypePalettes
directory.
3. Copy the FrontPanel.uir and StepType.dll files from the <TestStand
Public>\Examples\Fundamentals\Sequence File Translators -
Examples\Common directory to the <TestStand
Public>\Components\StepTypes\Translators directory.
You must restart the TestStand Sequence Editor so that TestStand can load the
example translator DLL.

How to Use This Example

To open a file with a custom format, select File»Open to launch the Open File
dialog box. The Files of Type control in the Open File dialog box contains the new file
extensions the translator supports. Browse to the examples directory that
corresponds to the development environment you are using and the custom format
for which you installed a translator and select SampleFile.

© National Instruments 153

TestStand User Manual

Note If you modify and rebuild an example translator DLL, you must copy
the DLL to the <TestStand Public>\Components\Translators directory and
restart TestStand to load the new DLL.

Related concepts:
■
Sequence File Translators
■ TestStand Directory Structure

Structure of TestStand Executions

Purpose
This example demonstrates the concepts of executions, threads, and call stacks and
shows how they interact. The example also shows how you can use the Call Stack
pane and the Threads pane to view the current status of an execution.

Example File Location

<TestStand Public>\Examples\Fundamentals\Structure of TestStand
Executions\Structure of TestStand Executions.seq

Highlighted Features
■ Sequence Call step type
■ Call Stack pane
■ Threads pane

Major API
None

Prerequisites
None

154 ni.com
TestStand User Manual

How to Use This Example

Complete the following steps to review the sequences and steps in the example.
1. On the Sequences pane, select the MainSequence. This sequence contains
three Sequence Call steps, which represent three distinct methods of calling a
subsequence.
2. Click the Call SubSequence step and navigate to the Module tab of the Step
Settings pane. Notice that the Execution Options for this sequence call are set
to None, which indicates that this sequence does not execute in a new thread
or execution.
3. Click the Call NewThread step and navigate to the Execution Options of this
step. Notice that this sequence call is set to execute in a new thread, which
means that execution of the MainSequence continues as the New Thread
sequence executes.
4. Click the Call NewExecution step and navigate to the Execution Options of
this step. Notice that this sequence call is set to execute in a new TestStand
execution, which means that TestStand manages execution of the
NewExecution sequence independently from the current execution.
Complete the following steps to run the example.
1. Select Execute»Single Pass to run the sequence.
2. During execution, message prompts explain the structure of TestStand
executions. After you dismiss each message, the corresponding Sequence Call
step executes, and TestStand automatically pauses execution so you can
examine each concept being demonstrated.
3. When you are ready to continue to the next step in the example, click the
green Resume button on the Debug toolbar. This process repeats until
execution completes.
Related concepts:
■ TestStand Directory Structure

Termination Monitor

© National Instruments 155

TestStand User Manual

The <TestStand Public>\Examples\Fundamentals\Termination Monitor directory

contains the following examples.
Related concepts:
■ TestStand Directory Structure
Termination Monitor - LabWindows/CVI

Purpose
This example demonstrates the use of the Termination Monitor function in
LabWindows/CVI. The Termination Monitor allows a code module to stop executing
if TestStand attempts to terminate or abort the execution.

Example File Location

<TestStand Public>\Examples\Fundamentals\Termination Monitor\CVI\Termination
Monitor.seq

Highlighted Features
■ LabWindows/CVI Adapter
■ Termination Monitor

Major API
None

Prerequisites
None

How to Use This Example

This example uses a CVI Action step to call a function in a C DLL that runs
indefinitely. Since it uses the Termination Monitor functionality, the function is able
to stop when TestStand attempts to terminate or abort the execution. If the function

156 ni.com
TestStand User Manual

did not call the Termination Monitor method, TestStand would be unable to
terminate or abort the execution.
To review the functions used in this example, open Termination Monitor Example.c
located at <TestStand Public>\Examples\Fundamentals\Termination
Monitor\CVI\Termination Monitor Example.c.
The TS_CancelDialogIfExecutionStops method is used to search for a request from
TestStand to stop the execution. This method automatically initiates a timer
callback, which will call the QuitUserInterface method if TestStand is attempting to
terminate or abort the execution.
Note that the TS_CancelDialogIfExecutionStops method requires the panel handle
of the onscreen dialog and the SequenceContext of the calling sequence as
parameters. This method also assumes that the calling code has control of the
dialog through a call to the RunUserInterface method.
Complete the following steps to run the example:
1. In TestStand, select Execute»Single Pass to run the sequence.
2. When the TerminationMonitorExample dialog appears, the sequence will
execute indefinitely.
3. On the Debug toolbar in TestStand, click the red Terminate button to
terminate the execution. Observe that the execution terminates successfully.
Related concepts:
■ TestStand Directory Structure
■
Programming with the TestStand API in LabWindows/CVI
■ Checking for Suspended or Stopped Execution within Code Modules
Termination Monitor - LabVIEW

Purpose
This example demonstrates the use of the Termination Monitor VIs in LabVIEW. The
Termination Monitor allows a code module to stop executing if TestStand attempts
to terminate or abort the execution.

© National Instruments 157

TestStand User Manual

Example File Location

<TestStand Public>\Examples\Fundamentals\Termination
Monitor\LabVIEW\Termination Monitor.seq

Highlighted Features
■ LabVIEW Adapter
■ Termination Monitor

Major API
None

Prerequisites
To run this example, you must have the LabVIEW development system installed and
you must configure the LabVIEW Adapter to use the LabVIEW development system.

Note The Termination Monitor palette VIs to not require the LabVIEW
development system. This requirement applies only to this example.

How to Use This Example

This example uses a LabVIEW Action step to call a VI that runs indefinitely. Since this
VI uses the Termination Monitor functions, it is able to stop when TestStand
attempts to terminate or abort the execution. If the VI did not include the
Termination Monitor functions, TestStand would be unable to terminate or abort
the execution.
To review the configuration of the VI, open Termination Monitor Example.vi located
at <TestStand Public>\Examples\Fundamentals\Termination
Monitor\LabVIEW\Termination Monitor Example.vi. In the VI, observe that the
TestStand - Initialize Termination Monitor VI is used to create a reference to the
Termination Monitor object.

158 ni.com
TestStand User Manual

Every 100 milliseconds, the TestStand - Get Termination Monitor Status VI is called
to determine whether TestStand is attempting to stop the execution. If so, the VI
exits.
Note that the Termination Monitor VIs require the SequenceContext of the calling
sequence. The SequenceContext is passed to the code module as a parameter.
Complete the following steps to run the example:
1. Select Execute»Single Pass to run the sequence.
2. When the TerminationMonitorExample VI front panel appears, the sequence
will execute indefinitely.
3. On the Debug toolbar in TestStand, click the red Terminate button to
terminate the execution. Observe that the execution terminates successfully.
Related concepts:
■ TestStand Directory Structure
■ Programming with the TestStand API in LabVIEW
■
Checking for Suspended or Stopped Execution within Code Modules
Termination Monitor - LabVIEW NXG

Purpose
This example demonstrates the use of the Termination Monitor in LabVIEW NXG. The
Termination Monitor allows a code module to stop executing if TestStand attempts
to terminate or abort the execution.

Example File Location

<TestStand Public>\Examples\Fundamentals\Termination Monitor\LabVIEW
NXG\Termination Monitor.seq

Highlighted Features
■ LabVIEW NXG Adapter
■ Termination Monitor

© National Instruments 159

TestStand User Manual

Major API
None

Prerequisites
To run this example, you must have the LabVIEW NXG development system installed.

Note The Termination Monitor palette VIs do not require the LabVIEW
NXG development system. This requirement applies only to this example.

How to Use This Example

This example uses a LabVIEW NXG Action step to call a VI that runs indefinitely. Since
this VI uses the Termination Monitor functions, it is able to stop when TestStand
attempts to terminate or abort the execution. If the VI did not include the
Termination Monitor functions, TestStand would be unable to terminate or abort
the execution because the execution must wait for code modules to complete
before terminating or aborting.
To review the configuration of the VI, click the edit VI button and observe the block
diagram.
Every 100 milliseconds, the TestStand easy termination monitor VI is called to
determine whether TestStand is attempting to stop the execution. If so, the VI exits.
This VI automatically handles starting and stopping the termination monitor. The
easy termination VI returns True if either the TestStand execution is terminated, or
if the stop loop input is true. This allows the dialog to stop based on a condition in
the code module.
Note that the Termination Monitor VIs require the SequenceContext of the calling
sequence which is used to monitor the execution state. The SequenceContext is
passed to the code module as a parameter.
Complete the following steps to run the example:
1. Select Execute»Single Pass to run the sequence.

160 ni.com
TestStand User Manual

2. When the TerminationMonitorExample VI front panel appears, the sequence

will execute indefinitely.
3. On the Debug toolbar in TestStand, click the red Terminate button to
terminate the execution. Observe that the execution terminates successfully
and the dialog is closed.
Related concepts:
■
TestStand Directory Structure
■ Checking for Suspended or Stopped Execution within Code Modules
Termination Monitor - .NET

Purpose
This example demonstrates the use of the Termination Monitor function in .NET. The
Termination Monitor allows a code module to stop executing if TestStand attempts
to terminate or abort the execution.

Example File Location

<TestStand Public>\Examples\Fundamentals\Termination
Monitor\dotNET\Termination Monitor.seq

Highlighted Features
■ .NET Adapter
■ Termination Monitor

Major API
None

Prerequisites
None

© National Instruments 161

TestStand User Manual

How to Use This Example

This example uses a .NET Action step to call a function in a .NET assembly that runs
indefinitely. Since it uses the Termination Monitor functionality, the function is able
to stop when TestStand attempts to terminate or abort execution. If the function did
not call the Termination Monitor method, TestStand would be unable to terminate
or abort the execution.
To review the functions used in this example, open Termination Monitor Example
Form.cs located at <TestStand Public>\Examples\Fundamentals\Termination
Monitor\dotNET\Termination Monitor Example\Termination Monitor Example
Form.cs.
In the InitializeTerminationStateChecking()method, notice that the
Execution.InitTerminationMonitor method from the TestStand API is used to
initialize the termination monitor and obtain a reference to data required by other
Termination Monitor functions. Every 100 milliseconds, the state of the execution is
queried with the Execution.GetTerminationMonitorStatus method from the
TestStand API. If TestStand is attempting to terminate or abort the execution, this
code module finishes its execution.
Complete the following steps to run the example:
1. In TestStand, select Execute»Single Pass to run the sequence.
2. When the TerminationMonitorExample dialog appears, the sequence will
execute indefinitely.
3. On the Debug toolbar in TestStand, click the red Terminate button to
terminate the execution. Observe that the execution terminates successfully.
Related concepts:
■ TestStand Directory Structure
■ Checking for Suspended or Stopped Execution within Code Modules

Using Data Streams

The <TestStand Public>\Examples\Fundamentals\Using Data Streams directory
contains the following examples.
Related concepts:

162 ni.com
TestStand User Manual

■ TestStand Directory Structure

Using Data Streams - LabVIEW

Purpose
This example uses data streams to read from a comma separated value (csv) file and
to create a csv file.

Example File Location

<TestStand Public>\Examples\Fundamentals\Using Data
Streams\LabVIEW\UsingDataStreams.seq

Highlighted Features
■ TestStand Data Streams

Major API
■ TestStand Data Streams API

Prerequisites
You must have the LabVIEW Development System installed to execute this example.

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Run MainSequence to execute the sequence.
2. View the resulting CSV in the Report tab.
Related concepts:
■ TestStand Directory Structure
Using Data Streams - .NET

© National Instruments 163

TestStand User Manual

Purpose
This example uses data streams to read from a comma separated value (csv) file and
to create a csv file.

Example File Location

<TestStand Public>\Examples\Fundamentals\Enumerations\UsingDataStreams.seq

Highlighted Features
■ TestStand Data Streams

Major API
■ TestStand Data Streams API

How to Use This Example

Using Sweep Loops

The <TestStand Public>\Examples\Fundamentals\Using Sweep Loops directory
contains the following examples.
Related concepts:
■ TestStand Directory Structure
Using Sweep Loops - LabVIEW

164 ni.com
TestStand User Manual

Example File Location

<TestStand Public>\Examples\Fundamentals\Using Sweep Loops\LabVIEW\Using
Sweep Loops.seq

Highlighted Features
■ Sweep Loops
■ Data Streams

Major API
■ TestStand Data Streams API

Prerequisites
LabVIEW development system 16.0 or later

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Run Mainsequence to execute the sequence.
Related concepts:
■ TestStand Directory Structure
Using Sweep Loops - .NET

Example File Location

<TestStand Public>\Examples\Fundamentals\Using Sweep Loops\dotNet\Using
Sweep Loops.seq

Highlighted Features
■ Sweep Loops

© National Instruments 165

TestStand User Manual

■ Data Streams

Major API
■ TestStand Data Streams API

Prerequisites
None

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Run Mainsequence to execute the sequence.
Related concepts:
■ TestStand Directory Structure
Sweep Loop Strategies

Example File Location

<TestStand Public>\Examples\Fundamentals\Using Sweep Loops\Sweep Loop
Strategies Demo\Sweep Loop Strategies.seq

Highlighted Features
■ Sweep Loops

Major API
■ SetBreakSettings

Prerequisites
None

166 ni.com
TestStand User Manual

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Run Mainsequence to execute the sequence
2. When the first breakpoint is hit, ensure that
Locals.SweepLoopParameterValues is added to the Watch Window during
execution.
3. At each breakpoint, observe the difference in the sweep loop strategies. The
strategy for ConstantValue resets the variables value to the value set in the
parameters list of the sweep loop even though it is incremented during an
iteration of the loop. The strategy for CaptureValue retains the new value
when a new iteration of the loop starts.
Related concepts:
■
TestStand Directory Structure

Using TestStand Enumerations

The <TestStand Public>\Examples\Fundamentals\Using TestStand Enumerations
directory contains the following examples.
Related concepts:
■ TestStand Directory Structure
Using TestStand Enumerations - CVI

Purpose
This example shows how to use TestStand enumerations with CVI code modules.
Enumerations are defined as custom types and can be stored in the Sequence File or
Type Palettes.

Example File Location

<TestStand Public>\Examples\Fundamentals\Using TestStand
Enumerations\CVI\Using TestStand Enumerations.seq

© National Instruments 167

TestStand User Manual

Highlighted Features
■ Using Enumerations in TestStand
■ Range Checking:Strict and Loose Enumerations
■ Flags Enumerations and Bitwise OR Semantics
■ Using Enumerations with the TestStand Adapters

Major API
■ Val Function
■ Str Function

Prerequisites
None

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Run MainSequence to execute the sequence.
2. As the example executes, follow the prompts and read the message popups
for information about Enumerations, Strict Enumerations, and Flag
Enumerations.
Complete the following steps to review the enumerations and steps in this example:
1. Open the Enum sequence from the Sequences pane. Select the Enum
Behavior step and review the step settings and parameter values for the step.
This code module allows the user to select a combination of RGB colors,
which are then stored in the Locals.Color Local variable.
2. Select the Display Enum Value step and review the Message Expression.
This expression uses the Str() and Val() functions to display the string and
formatted numeric representations of an enum value.
3. Repeat steps 1 and 2 for the Strict Enum and Flag Enum sequences.

168 ni.com
TestStand User Manual

4. Open the Types Window (Ctrl + t) and select Enums.seq to view the three
different enumeration definitions used in this example: Colors, Colors_Strict,
and Colors_Flag. Choose Edit Enumerations to view details of each type.
Related concepts:
■ TestStand Directory Structure
■
Using Enumerations in TestStand
■ Range Checking: Strict and Loose Enumerations
■ Flags Enumerations and Bitwise OR Semantics
■
Using Enumerations with the TestStand Adapters
Using TestStand Enumerations - LabVIEW

Purpose
This example shows how to use TestStand enumerations with LabVIEW code
modules. Enumerations are defined as custom types and can be stored in the
Sequence File or Type Palettes.

Example File Location

<TestStand Public>\Examples\Fundamentals\Using TestStand
Enumerations\LabVIEW\Using TestStand Enumerations.seq

Major API
■ PropertyObject.GetPropertyObject
■ SequenceFile.AsPropertyObjectFile

© National Instruments 169

TestStand User Manual

■ SequenceFile.AsPropertyObject

Prerequisites
None

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Run MainSequence to execute the sequence.
2. As the example executes, follow the prompts and read the message popups
for information about Enumerations.
Complete the following steps to review the enumerations and steps in this example:
1. Open the Enum sequence from the Sequences pane. Select the Enum
Behavior step and review the step settings and parameter values for the step.
This code module allows the user to select a combination of RGB colors,
which are then stored in the Locals.Color Local variable.
2. Select the Display Enum Value step and review the Message Expression.
This expression uses the Str() and Val() functions to display the string and
formatted numeric representations of an enum value.
3. Repeat steps 1 and 2 for the Strict Enum and Flag Enum sequences.
4. Open the Types Window (Ctrl + t) and select Enums.seq to view the three
different enumeration definitions used in this example: Colors, Colors_Strict,
and Colors_Flag. Choose Edit Enumerations to view details of each type.
Related concepts:
■ TestStand Directory Structure
■
Using Enumerations in TestStand
■ Range Checking: Strict and Loose Enumerations
■ Flags Enumerations and Bitwise OR Semantics
■
Using Enumerations with the TestStand Adapters
Using TestStand Enumerations - .NET

170 ni.com
TestStand User Manual

Purpose
This example shows how to use TestStand enumerations with .NET code modules.
Enumerations are defined as custom types and can be stored in the Sequence File or
Type Palettes.

Example File Location

<TestStand Public>\Examples\Fundamentals\Using TestStand
Enumerations\DotNet\Using TestStand Enumerations.seq

Major API
■ Val Function
■ Str Function

Prerequisites
None

How to Use This Example

© National Instruments 171

TestStand User Manual

Complete the following steps to review the enumerations and steps in this example:
1. Open the Enum sequence from the Sequences pane. Select the Enum
Behavior step and review the step settings and parameter values for the step.
This code module allows the user to select a combination of RGB colors,
which are then stored in the Locals.Color Local variable.
2. Select the Display Enum Value step and review the Message Expression.
This expression uses the Str() and Val() functions to display the string and
formatted numeric representations of an enum value.
3. Repeat steps 1 and 2 for the Strict Enum and Flag Enum sequences.
4. Open the Types Window (Ctrl + t) and select Enums.seq to view the three
different enumeration definitions used in this example: Colors, Colors_Strict,
and Colors_Flag. Choose Edit Enumerations to view details of each type.
Related concepts:
■ TestStand Directory Structure
■
Using Enumerations in TestStand
■
Range Checking: Strict and Loose Enumerations
■ Flags Enumerations and Bitwise OR Semantics
■ Using Enumerations with the TestStand Adapters

Examples for Interfacing with Hardware

The Interfacing with Hardware examples demonstrate how you can use TestStand to
communicate with and coordinate your test hardware resources. This directory
includes the following example programs.

Instrument Control Step Types

Purpose
This example demonstrates how to implement a TestStand HP34401a instrument
control step type in LabWindows/CVI. You can use the step type to access
commonly-used functionality of the HP34401a multimeter from a TestStand
sequence.

172 ni.com
TestStand User Manual

Example File Location

<TestStand Public>\Examples\Interfacing with Hardware\Instrument Control Step
Types - HP34401a\Instrument Control Step Types - HP34401a.seq

Highlighted Features
TestStand step types

Major API
N/A

Prerequisites
You must install the HP34401a IVI instrument driver from the Instrument Driver
Network at ni.com/devzone/idnet before running this example.

Note Depending on the version and configuration of IVI on the computer,

simulated measurements the HP34401a step type makes might not return
realistic values. The measurements are correct if you use a real HP34401a
instrument.

How to Use This Example

This example demonstrates optional features you can include in step types you
create. You can decide which, if any, of the following features to support in step
types you create:
■ Tabbed editing dialog box
■ Multiple selectable run-time operations
■ Configuration settings you can specify with TestStand expressions
■ Groups of configuration settings you can load or save to a TestStand custom
data type, which you can then execute according to a group of settings you
store in a local variable or receive as a sequence parameter

© National Instruments 173

TestStand User Manual

■ Instrument driver session obtained from the Session Manager to maximize

the sharing of the instrument handle between steps and other code modules
■ Multiple language string support

Installation Issues
Step types might depend on files such as code modules, icon files, or string resource
files. For TestStand to locate these files, the files must reside in specific directories.
■ Code Module Files (.dll, .vi, and so on)—Place step type code module
files in a subdirectory you create in the <TestStand
Public>\Components\StepTypes directory. TestStand finds code modules you
place in this directory because the TestStand default search paths include all
directories under the <TestStand Public>\Components directory. Although
this example does not install its code module, HP34401aStepType.dll, to the
<TestStand Public>\Components directory, TestStand can find the step type
code module because the step type specifies a relative path from the
<TestStand Public>\Examples\Interfacing with Hardware\Instrument Control
Step Types - HP34401a directory.
■ Icon Files—Place icon files for step types in the <TestStand
Public>\Components\Icons directory. TestStand loads icons from this
directory and the <TestStand>\Components\Icons directory. TestStand installs
the icon for this example to <TestStand
Public>\Components\Icons\NI_Examples\Example_HP34401a.ico.
■ String Resource Files—Place string resource files you create in the
<TestStand
Public>\Components\Language\<language>\TestStandExamples.ini file.
The HP34401a_StepTypeExample.seq example sequence file contains the example
step type definition. You can store step type definitions you create in any sequence
file, and you can add a step type to a new or existing TestStand type palette file. You
can install a type palette file on another computer by placing the file in the
<TestStand Public>\Components\TypePalettes directory. You must prefix the
filenames of the type palettes you install with Install_. At startup, TestStand
searches the TypePalettes directory for type palette files with the Install_ prefix.
When TestStand finds a palette file to install and the base filename is not the same

174 ni.com
TestStand User Manual

as any existing palette file, TestStand removes the Install_ prefix and adds the
palette to the palette list. When TestStand finds a palette file to install and the base
filename is the same as an existing palette file, TestStand merges the types from the
Install_ prefixed file with the existing palette file and deletes the Install_ file.

Step Type Implementation

Complete the following steps to implement a step type.
1. Create a new step type in the Types window. The example step type is named
HP34401aStepType, which you can view in the Types window for the
Instrument Control Step Types - HP34401a.seq file.
2. Determine the data requirements for the step. Analyze the data inputs and
outputs the step requires at run time.
3. Create input properties. Create a step subproperty for each data input. Select
the appropriate data type and set the default value. The example step type
uses the following data input properties:
Step.LogicalNameStep.OperationStep.SettingSourceStep.Configuration.MeasFunctionSte
4. Create output properties. Create a step subproperty for each data output. If
you want an output property to automatically appear in the sequence result
list, create the output property under the Step.Result property. The example
step type uses the following data output properties:
Step.Read.DestStep.SelfTest.DestStep.Result.SinglePointStep.Result.SinglePoint.TypeSte
5. Designate an adapter, if appropriate. If the step is not designed to call user-
written code, enable the Designate an Adapter option on the General tab of
the Step Type Properties dialog box and select the <None> Adapter. The
example step type does not require you to write any code to access the
instrument. Thus, the example step type designates the <None> Adapter as
the appropriate module adapter.
6. Define run-time functionality. Create a Pre- or Post-Step substep to call a code
module you write. Each instance of the step type calls the code module when
the step executes. The code module call is transparent to the user. If the step
type calls user-written code, define a Pre- or Post-Step substep, depending on
whether you want to call the code module before or after the step executes. If
the step type does not call user-written code, you can use a Pre- or Post-Step
substep to call the code module. The example step type defines a Post-Step

© National Instruments 175

TestStand User Manual

substep that calls the ExecuteHP34401aStep DLL function when an instance of

the step type executes. The ExecuteHP34401aStep DLL function accepts a
SequenceContext parameter, which the function uses with the TestStand
API to access the properties of the step. You can also define the function to
accept a separate parameter for each step property the function uses.
7. Define an editing dialog box. Configure the Edit substep to call a code module
that launches the dialog box, which shows step property values in a
controlled and organized manner. When the user finishes editing, the dialog
box stores the edited property values in the step and marks the sequence file
that contains the step as modified. The Edit substep for the example step type
calls the EditHP34401aStep DLL function to launch a dialog box in which the
user selects the action the step executes at run time and configures the
parameters the action requires. The ExecuteHP34401aStep DLL function
accepts a SequenceContext parameter, which the function uses with the
TestStand API to access the properties of the step. You can also define the
function to accept a separate parameter for each step property the function
uses.
8. Configure built-in step type properties. Use the Step Type Properties dialog
box to configure the default values of built-in step type properties and other
settings. Typically, you configure the following settings for a step type:
■ Designate an Icon—If the step does not call user-written code, select an
icon that represents its functionality. You can select from the icon files in the
<TestStand Public>\Components\Icons and <TestStand>\Components\Icons
directories. If the step calls user-written code, do not designate an icon. The
step displays the icon that represents the adapter that calls the user-written
code. The example step type specifies <TestStand
Public>\Components\Icons\NI_Examples\Example_HP34401a.ico as its icon
file.
■ Default Step Name Expression—The default step name expression
determines the name the sequence editor assigns to a new instance of the
step type. You can use the ResStr expression function in the default name
expression to specify a name that changes depending on the selected
language. The example step type specifies the following expression as its
default step name expression: ResStr("HP34401_STEP_TYPE_EXAMPLE",

176 ni.com
TestStand User Manual

"DEFAULT_NAME")If the step type does not need to account for the selected
language, you can enter a default step name in quotes, such as "HP34401a
Step".
■ Step Description Expression—The step description expression
determines the description that Description column on the Steps pane and
the Description control on the General panel of the Properties tab of the
Step Settings pane show for the step. The description expression can refer to
and show the values of step properties. You can use the ResStr expression
function in the description expression to specify a description that changes
depending on the selected language. The example step type uses a lengthy
expression to vary the description depending on the step configuration and
the selected language. If the step type description does not need to account
for the step configuration or the selected language, you can enter a fixed
description in quotes, such as "HP33401a DMM Instrument Control".
■ Menu Item Name—Use the Item Name Expression control on the
Menu tab of the Step Type Properties dialog box to specify the item name
expression for the step type. The expression determines the name of the
menu item in the Insert Step submenu that inserts an instance of the step
type into a sequence. You can use the ResStr expression function in the item
name expression to specify an item name that changes depending on the
selected language. The example step type specifies the following item name
expression: ResStr("HP34401_STEP_TYPE_EXAMPLE", "MENU_NAME")If the
menu item does not need to account for the selected language, you can
enter an item name in quotes, such as "HP34401a".
■ Other Items—Depending on the step type, you can also use the following
features. The example step type does not configure any other step type
settings.
■ Configure the default values of built-in properties, such as the run
options or loop options.
■ Use the Disable Properties tab of the Step Type Properties dialog box to
prevent users of the step type from editing the values of built-in properties
you select.
■ Specify code templates to assist the user in creating code modules that
you designed the step type to call.

© National Instruments 177

TestStand User Manual

Suggestions for Implementing Instrument Control Step Types

To increase performance, do not initialize and close the instrument driver each time
the step executes. Instead, use DLL global variables or another method to maintain
the instrument instance between steps.
One option is to use the Session Manager to initialize and share instrument driver
handles between multiple instances of the step type. The example step type obtains
an instrument session from the Session Manager and attaches the instrument
session to the current TestStand execution object by dynamically creating an
ActiveX reference subproperty. In this way, the driver for the session stays open for
the duration of the execution and all steps that can run during the execution share
the same driver instance handle. You can also use the Session Manager to obtain a
list of available instrument connections from which the step user can select.
To increase the flexibility of the step type, allow the user to specify the values of
important settings with an expression. The user can then store the setting value in a
variable and alter it at run time. The example step type allows the user to specify
almost all setting values with an expression.
For groups of related settings, consider allowing the user to load or store the values
in a variable of a custom data type that you define. The user can then specify a
group of settings in a variable and pass the variable as a parameter to subsequences
that contain the steps that apply the setting values. The example step type allows
the user to specify a setting source variable to which the step loads or stores the
settings for the selected operation.

Suggestions for Implementing Step Type Editing Dialog Boxes in

LabWindows/CVI
The <TestStand>\API\CVI\TSUtil.fp instrument driver contains the following
functions to help create a step type editing dialog box:
■ If the text labels that appear on the step type editing dialog box must
appear in the selected language, call the TS_LoadPanelResourceStrings
function to load the language-specific dialog strings.
■ Call the TS_StartModalDialog and TS_EndModalDialog functions to ensure
that the editing dialog box is modal to the sequence editing application.

178 ni.com
TestStand User Manual

■ Call the TS_ExprCtrl_Create function to convert a string control into an

expression editing control.
■ Call the TS_ExchangePropertyAndCtrlVals function to transfer values
between step properties and dialog box controls.
■ Call the TS_IncSequenceFileChangeCount function if the editing dialog box
modifies the step.
Related concepts:
■
TestStand Directory Structure
■ Built-In Step Types
■ Creating Custom Step Types

InstrumentStudio
The <TestStand Public>\Examples\Interfacing with Hardware\InstrumentStudio
directory contains the following examples.
Related concepts:
■ TestStand Directory Structure
Measure Efficiency

Purpose
This example demonstrates how to use IO Configuration step types to communicate
with the instrument for measuring efficiency.

Example File Location

<TestStand Public>\Examples\Interfacing with
Hardware\InstrumentStudio\Efficiency\Efficiency.seq

Highlighted Features
■ IO Configuration Step Types
■ Sweep Loop Step Type

© National Instruments 179

TestStand User Manual

Major API
None

Prerequisites
Complete the following steps before executing this example on 64-bit TestStand.
1. Install the following NI software:
■ LabVIEW (64-bit)
■ NI-DCPower
■ Measurement & Automation Explorer (MAX)
■ InstrumentStudio 2021 or later
■ MI Device Support for TestStand

Note
■ MAX and InstrumentStudio are included by default when you
install NI-DCPower.
■ MI Device Support for TestStand is included by default with NI-
DCPower only when TestStand is already installed. You can install
it separately with NI Package Manager once TestStand is installed.

2. Complete the following setup:

■In TestStand, configure the LabVIEW Adapter to use the LabVIEW
Development System.
■ Create a simulated device in MAX. Right click Devices and
Interfaces»Create New »Simulated NI-DAQmx Device or Modular
Instrument»Finish.
■ In the Create Simulated NI-DAQmx Device dialog, expand the node for
Power Supplies and select the NI PXIe-4143.
■ For the newly added device, update the name of the device in MAX to dev2
and save the device.

180 ni.com
TestStand User Manual

How to Use This Example

Complete the following steps to use this example.
1. On the Steps pane of the MainSequence sequence, review the steps in the
Setup step group.
■ The Get Sequence File Directory step gets the directory of the example
sequence file.
■ The Identify CSV Output file step creates the output stream in the
sequence file directory.
■ The Create DC Power Session and Apply Configuration step creates a
session (dev2) in LabVIEW.
2. On the Steps pane, review the steps in the Main step group.
■ The Sweep DC Power - Current Vout step sweeps on the voltage values for
the session (dev2) on channel 0 and the current values for the session (dev2)
on channel 1.
■ The Measure Current And Voltage - Channel0 step measures the current
and voltage for channel 0.
■ The Measure Current And Voltage - Channel1 step measures the current
and voltage for channel 1.
■ The Calculate Efficiency step calculates the efficiency based on the
measured voltage and current values against the values set in the preceding
two steps.
3. On the Steps pane, review the steps in the Cleanup step group.
■ The Close Sessions step closes the sessions which have been opened in
the current sequence.
4. Select Execute»Single Pass to run the sequence.
5. The voltage, current, and efficiency values are logged to <TestStand
Public>\Examples\Interfacing with
Hardware\InstrumentStudio\Efficiency\output.csv.
Related concepts:

© National Instruments 181

TestStand User Manual

■ TestStand Directory Structure

■ Step Groups
Measure Quiescent Current

Purpose
This example demonstrates how to use IO Configuration step types to communicate
with the instrument for measuring quiescent current.

Example File Location

<TestStand Public>\Examples\Interfacing with
Hardware\InstrumentStudio\Quiescent Current\QuiescentCurrent.seq

Highlighted Features
■ IO Configuration Step Types
■ Sweep Loop Step Type

Major API
None

Note

182 ni.com
TestStand User Manual

■ MAX and InstrumentStudio are included by default when you

install NI-DCPower.
■ MI Device Support for TestStand is included by default with NI-
DCPower only when TestStand is already installed. You can install
it separately with NI Package Manager once TestStand is installed.

2. Complete the following setup:

How to Use This Example

© National Instruments 183

TestStand User Manual

■ The Measure Current And Voltage step measures the current and voltage.
3. On the Steps pane, review the steps in the Cleanup step group.
■ The Close Sessions step closes the sessions which have been opened in
the current sequence.
4. Select Execute»Single Pass to run the sequence.
5. The voltage, current, efficiency values are logged to <TestStand
Public>\Examples\Interfacing with Hardware\InstrumentStudio\Quiescent
Current\output.csv.
Related concepts:
■ TestStand Directory Structure
■ Step Groups

Interfacing with NI-Hardware drivers using Python Custom step

and Python Adapter
Purpose
This example demonstrates the possibility of TestStand interfacing with NI device
drivers through Python packages for the desired NI devices.
The example will not use the actual device drivers. It will mimic the behaviour of the
device drivers. You can modify the Python modules to interact with actual Python
drivers.
The example will call into a Python module that will use simulated Python drivers
for accessing device.

Example File Location

<TestStand Public>Examples\Interfacing with Hardware\Interfacing Modular
Instruments Using Python Custom Step Type\Interfacing Modular Instruments Using
Python Custom Step Type.seq

Highlighted Features
■ Custom Step Types

184 ni.com
TestStand User Manual

Major API
None

Prerequisites
You must have Python 3.6 installed and added to your PATH variable.

How to Use This Example

Complete the following steps to use this example.
1. On the Steps pane of the MainSequence sequence, review the steps in the
Setup step group.
■ The Create Device Sessions step, which is a Sequence Call step, simulates
the creation of device sessions for the NI-DMM and NI-DcPower devices.
2. On the Steps pane of the MainSequence sequence, review the steps in the
Main step group.
■ The NI-DMM step, which is a Sequence Call step, simulates the interfacing
with the NI-DMM Python package for the NI-DMM device.
■ The NI-SMU [DcPower] step, which is a Sequence Call step, simulates the
interfacing with the NI-DcPower Python package for the NI-DCPower device.
3. On the Steps pane of the MainSequence sequence, review the steps in the
Cleanup step group.
■ The Close Device Sessions step, which is a Sequence Call step, simulates
the releasing of the device sessions for NI-DMM and NI-DcPower devices.
4. On the Steps pane of the CreateDeviceSessions subsequence, review the steps
in the Main step group.
■ The New NI-DMM Session and the New NI-DCPower Session steps, which
are instances of the Custom Step Types NIDMM_NewSession and
NIDCPOWER_NewSession of the sequence file respectively, create new
sessions.

© National Instruments 185

TestStand User Manual

■ The New NI-DMM Session step and the New NI-DCPower Session step
open two separate Python interpreter sessions for the respective devices.
5. On the Steps pane of the NI-DMM subsequence, review the steps in the Main
step group.
■ The Auto Schedule step, which is an Auto Schedule Synchronization step,
performs auto scheduling (avoids multiple access) of the steps within the
Use Auto Scheduled Resource block.
■ The Use Auto Scheduled Resource block, which is a Use Auto Scheduled
Resource Synchronization step, defines the set of steps that needs to be
considered for auto scheduling.
■ The Configure NI-DMM Session step, simulates the initialization of the NI-
DMM device session by setting the Range, Rate, number of Points to
measure and the measurement type properties in the NI-DMM device
session object.
■ The Get DMM Measurements step simulates the collecting of
measurement values from the NI-DMM device using the NI-DMM device
session object.
■ The Average DMM Measurements, which is a Numeric Limit Test step,
calculates the average of the measured values and validates it with a
defined test range.
■ The Results step, which is an Additional Results step, displays the
measurement values obtained from the NI-DMM session object.
6. On the Steps pane if the NI-SMU [DcPower] subsequence, review the steps in
the Main step group.
■ The Auto Schedule step, which is an Auto Schedule Synchronization step,
performs auto scheduling (avoids multiple access) of the steps within the
Use Auto Scheduled Resource block.
■ The Use Auto Scheduled Resource block, which is a Use Auto Scheduled
Resource Synchronization step, defines the set of steps that needs to be
considered for auto scheduling.
■ The Configure NI-DCPower Session step, simulates the initialization of the
NI-DCPower device session by setting the current and voltage Limits and

186 ni.com
TestStand User Manual

Ranges and the number of Points to measure in the NI-DCPower device

session object.
■ The Get DCPower Measurements [Voltage, Current] step simulates the
collecting of voltage and current measurement values from the NI-DCPower
device using the NI-DCPower device session object.
■ The Average DCPower Voltage Measurement in Channel 0 and 1 and the
Average DCPower Current Measurement in Channel 0 and 1, which is an
Action step, calculates the average of the measured values across channels 0
and 1.
■ The Validate Averaged Measurements, which is a Multiple Numeric Limit
Test step, validates the average of the measured values with defined test
ranges.
■ the Results step, which is an Additional Results step, displays the
measurement values obtained from the NI-DCPower session object across
channels 0 and 1.
7. On the Steps pane of the CloseDeviceSessions subsequence, review the steps
in the Main step group.
■ The Close NI-DMM Session and the Close NI-DCPower Session steps, which
are instances of the Custom Step Types NIDMM_CloseSession and
NIDCPOWER_CloseSession respectively of the sequence file, simulate the
releasing of the device sessions.
8. Select Execute»Single Pass to run the sequence.
9. When execution completes, review the report.
Related concepts:
■ TestStand Directory Structure
■ Custom Step Types
■ Step Groups

Session Manager
The <TestStand Public>\Examples\Interfacing with Hardware\Session Manager
directory contains the following examples.

© National Instruments 187

TestStand User Manual

Related concepts:
■ TestStand Directory Structure
■
Session Manager Support for 64-bit TestStand
Session Manager - LabWindows/CVI

Purpose
This example demonstrates how to use NI Session Manager to share named
instrument handles between LabWindows/CVI code modules. Refer to the NI
Session Manager Help. located in <Program Files>\National
Instruments\Shared\Session Manager, for more information about how to use
Session Manager.

Example File Location

<TestStand Public>\Examples\Interfacing with Hardware\Session
Manager\CVI\Session Manager.seq

Highlighted Features
■ IVI
■ NI Session Manager

Major API
None

Prerequisites
You must complete the following steps before you can run this example.
1. Ensure that you have the LabWindows/CVI Run-Time Engine installed and you
configure the LabWindows/CVI Adapter to execute steps in-process. If you
want to use the Execute Steps in an External Instance of CVI option, you
must have the LabWindows/CVI development environment installed.

188 ni.com
TestStand User Manual

2. Install the following software from the NI Device Driver DVD that comes with
TestStand:
■ Measurement & Automation Explorer (MAX)
■ IVI Compliance Package
3. Complete the following steps to download and install an IVI-compliant
instrument driver for the IVI DMM class that the example can use, such as
hp34401a.
a. Refer to the Instrument Driver Network at ni.com/idnet.
b. Search for the manufacturer or the type of instrument you want to
download. In MAX, the driver installer automatically creates a driver
session entry under the Driver Sessions item and populates the
software module information under the Instrument Driver Software
Module item in the Advanced folder.
4. Complete the following steps to create a logical name for the session.
a. In MAX, expand the IVI Drivers category.
b. Right-click the Logical Names item in the configuration tree and select
Create New from the context menu.
c. Complete the configuration panel for the new logical name,
"SampleDMM". Logical names are case-sensitive. In the Driver Session
control, specify the driver session you downloaded.

How to Use This Example

The Get DMM Session step obtains a reference to the session named "SampleDMM",
which the Locals.logicalName local variable specifies. When the step creates the
session, Session Manager initializes the instrument session and the step stores the
reference in the DMM_Reference local variable so the session must continue to exist
until the sequence completes.
The remaining steps in the sequence call code modules. Each code module calls
Session Manager and obtains the instrument handle for the session the
Locals.logicalName local variable specifies. Because the Get DMM Session step

© National Instruments 189

TestStand User Manual

ensures that the session exists for the life of the sequence, each module uses the
same session and the instrument initializes and closes only once.

Note Class drivers launch simulation dialog boxes if interactive

simulation is enabled. These dialog boxes might not have taskbar items
and can go behind the sequence editor. In addition, the IVI soft front
panels remain visible until you close the Execution window.

Related concepts:
■
TestStand Directory Structure
■
Session Manager Support for 64-bit TestStand
Session Manager - LabVIEW

Purpose
This example demonstrates how to use NI Session Manager to share named
instrument handles between LabVIEW code modules. Refer to the NI Session
Manager Help. located in <Program Files>\National Instruments\Shared\Session
Manager, for more information about how to use Session Manager.

Example File Location

<TestStand Public>\Examples\Interfacing with Hardware\Session
Manager\LabVIEW\Session Manager.seq

Highlighted Features
■ IVI
■ NI Session Manager

Major API
None

190 ni.com
TestStand User Manual

Prerequisites
You must complete the following steps before you can run this example.
1. Ensure that you have the LabVIEW development system installed and you
configure the LabVIEW Adapter to use the LabVIEW development system.
2. Install the following software from the NI Device Driver DVD that comes with
TestStand:
■ Measurement & Automation Explorer (MAX)
■ IVI Compliance Package, including the LabVIEW Support portion of the IVI
Class Drivers
3. Complete the following steps to download and install an IVI-compliant
instrument driver for the IVI DMM class that the example can use, such as
hp34401a.
a. Refer to the Instrument Driver Network at ni.com/idnet.
b. Search for the manufacturer or the type of instrument you want to
download. In MAX, the driver installer automatically creates a driver
session entry under the Driver Sessions item and populates the
software module information under the Instrument Driver Software
Module item in the Advanced folder.
4. Complete the following steps to create a logical name for the session.
a. In MAX, expand the IVI Drivers category.
b. Right-click the Logical Names item in the configuration tree and select
Create New from the context menu.
c. Complete the configuration panel for the new logical name, which is
"SampleDMM". Logical names are case-sensitive. In the Driver Session
control, specify the driver session you downloaded.

How to Use This Example

The Get DMM Session step obtains a reference to the session named "SampleDMM",
which the Locals.logicalName local variable specifies. When the step creates the

© National Instruments 191

TestStand User Manual

session, Session Manager initializes the instrument session and the step stores the
reference in the DMM_Reference local variable so the session must continue to exist
until the sequence completes.
The remaining steps in the sequence call code modules. Each code module calls
Session Manager and obtains the instrument handle for the session the
Locals.logicalName local variable specifies. Because the Get DMM Session step
ensures that the session exists for the life of the sequence, each module uses the
same session and the instrument initializes and closes only once.

Note Class drivers launch simulation dialog boxes if interactive

Related concepts:
■
TestStand Directory Structure
■ Effectively Using LabVIEW with TestStand
■
Session Manager Support for 64-bit TestStand

Switch Executive
Description
This example demonstrates how to use TestStand to integrate and perform
switching operations with NI Switch Executive.

Example File Location

<TestStand Public>\Examples\Interfacing with Hardware\Switch Executive\Switch
Executive.seq

Highlighted Features
■ NI Switch Executive integration
■ IVI Switch step type
■ Switching panel

192 ni.com
TestStand User Manual

Major API
None

Prerequisites
This example assumes you have installed a release or evaluation version of NI
Switch Executive. This example also assumes the SwitchExecutiveExample virtual
device exists and the SampleMatrix1 and SampleMatrix2 IVI logical names are
configured to run in simulation mode.
The virtual device is created when you install NI Switch Executive. If the device
and/or logical names have been removed, you can recover them by performing the
following steps:
1. Open the Windows command line and type cd <National Instruments>/switch
executive, where <National Instruments> is the NI directory, which is
C:\Program Files (x86)\National Instruments by default.
2. Enter the command SwitchExecutive s to recreate the virtual device and
logical names.

How to Use This Example

The sequence performs switching operations using the Switching panel on the
Properties tab of the Step Settings pane and the IVI Switch step type. Using the
Switching panel, any step can perform switching operations while the step executes
or perform switching setup for subsequent steps.
You can monitor IVI switching operations by launching NI I/O Trace prior to running
this example. You must enable tracing of calls to the IVI Switch API.
Visit ni.com/ivi for more information about IVI.
Related concepts:
■ TestStand Directory Structure

Characterization of a Transistor

© National Instruments 193

TestStand User Manual

Purpose
This example demonstrates how you can use the Sweep Loop step to characterize a
transistor.

Example File Location

<TestStand Public>\Examples\Interfacing with Hardware\Transistor Characterization
using Sweep Loop Step\TransistorCharacterization.seq

Highlighted Features
■ Sweep Loop Step Type

Major API
None

Prerequisites
None

How to Use This Example

194 ni.com
TestStand User Manual

■ The Sweep Transistor - Temperature step sweeps on the junction

temperature of the transistor.
■ The While loop containing the Measure Junction temperature step
executes until the measured temperature is equal to the desired junction
temperature ±0.1 as set in the Sweep loop step above.
■ The Sweep Transistor - Voltage and Current step sweeps on various
Voltage and Current parameters.
■ The Calculate Vce step calculates the Collector-Emitter voltage as the
difference of voltage between Vcc and Ve.
■ The Measure Ic step simulates the measuring of Collector current.
■ The Measure Ie step simulates the measuring of Emitter current.
■ The Calculate DC Current Gain (hFE) step calculates the gain in current as
the ratio of output current (Ic) to input current (Ie).
■ The Write Record to CSV Output file step writes the values of Temperature,
Vce, measured Ic and Current gain to the output CSV file for each iteration of
the Sweep Loop step.
3. On the Steps pane, review the steps in the Cleanup step group.
■ The Close CSV Output file Stream reference step closes the reference to
the CSV Output File Stream.
4. Select Execute»Single Pass to execute the sequence.
5. The Temperature, Vce, Ic and Current gain values are logged to <TestStand
Public>\Examples\Interfacing with Hardware\Transistor Characterization
using Sweep Loop Step\output.csv.
Related concepts:
■ TestStand Directory Structure

Examples for Modifying Process Models

The Modifying Process Models examples demonstrate common methods for
overriding or extending default process model functionality in the client sequence
file. This directory includes the following example programs.

Dynamically Set the Client Sequence File

© National Instruments 195

TestStand User Manual

Purpose
This example demonstrates how to dynamically specify a client sequence file. This
example uses the Execution.ClientFile property to set the client sequence file of the
process model.

Example File Location

<TestStand Public>\Examples\Modifying Process Models\Dynamically Setting the
Client Sequence File\Dynamically Set the Client Sequence File.seq

Highlighted Features
■ TestStand API
■ Process model plug-in architecture

Major API
■ Engine.GetSequenceFileEx
■ Execution.ClientFile
■ Engine.ReleaseSequenceFileEx

Prerequisites
None

How to Use This Example

When you run this example, TestStand prompts you to select Sequence A or
Sequence B to run as the client sequence file of the process model. Run the example
several times using the Test UUTs or Single Pass Execution entry points and review
the report, which includes information relevant to the sequence file you selected.
Open the process model plug-in file,
DynamicClientFileExampleModelPluginAddon.seq, associated with this example.
Notice that the Model Plugin - Pre UUT sequence sets the Execution.ClientFile
property to the file you select at run time.

196 ni.com
TestStand User Manual

Note By default, TestStand might not unload dynamically selected client

files before execution completes. For more information, review the
comment on the Unload Unused Client File step in the Model Plugin - Pre
UUT and Model Plugin - Pre Batch sequences in
DynamicClientFileExampleModelPluginAddon.seq.

Complete the following steps to use this example.

1. Open <TestStand Public>\Examples\Modifying Process Models\Dynamically
Setting the Client Sequence File\Example -Dynamically Set the Client
Sequence File.seq, read the dialog box that appears, and dismiss the dialog
box.
2. Select Execute»Single Pass. Select the sequence you want to run when
prompted.
3. Review the report that TestStand displays when execution completes.
4. Repeat steps 2-3 but select Execute»Test UUTs to run the sequence using
the Test UUTs Execution entry point.
The example copies the DynamicClientFileExampleModelPluginAddon.seq file from
the <TestStand Public>\Examples directory to the <TestStand
Public>\Components\ModelsPlugins\Addons directory so that the process model
automatically executes the Model Plugin - Pre UUT sequence in the file. If you want
to set a breakpoint in the Model Plugin - Pre UUT sequence, set the breakpoint in
the copy of the file in the <TestStand Public>\Components\ModelsPlugins\Addons
directory. If you make any changes to the file in the Addons directory you must
change the name of the file because the Example - Dynamically Set the Client
Sequence File.seq file overwrites the
DynamicClientFileExampleModelPluginAddon.seq file in the Addons directory when
you load the Example - Dynamically Set the Client Sequence File.seq file and deletes
the DynamicClientFileExampleModelPluginAddon.seq file from the Addons
directory when you unload the Example - Dynamically Set the Client Sequence
File.seq file.
Entry Point Ignores Client File Show Entry Point for All
WindowsModelSequence PropertiesSample Process Model for initiating Testing
Without an Active Sequence File Window.seq

© National Instruments 197

TestStand User Manual

Related concepts:
■ TestStand Directory Structure
■
Process Model Plug-In Architecture
■ Execution Entry Points in the Sequential Process Model

Overriding PreUUT Model Callbacks

Purpose
This example demonstrates how to override the PreUUT Model callback sequence to
simulate scanning a serial number and performing a database query. When you do
not override the PreUUT callback, the default process model prompts you to
manually enter a serial number.

Example File Location

<TestStand Public>\Examples\Modifying Process Models\Overriding Model
Callbacks - Sequential Model\CVI\Overriding the PreUUT Callback.seq

Highlighted Features
Callbacks

Major API
None

How to Use This Example

Complete the following steps to review the sequences and steps in this example.

198 ni.com
TestStand User Manual

1. On the Sequences pane, select the MainSequence. The MainSequence

contains four Numeric Limit Test steps.
2. Select Edit»Sequence File Callbacks to launch the Sequence File Callbacks
dialog box, in which you can select a callback to override. For the PreUUT
callback, the Present column specifies yes. Click OK to close the Sequence
File Callbacks dialog box.
3. On the Sequences pane, select the PreUUT callback. The IdentifyUUT step,
which uses the C/C++ DLL Adapter, calls a DLL to simulate scanning a serial
number and performing a database query.
4. Select Execute»Test UUTs to run the sequence. The PreUUT callback
executes instead of the PreUUT callback in the process model, so TestStand
does not launch the default UUT Information dialog box for you to manually
enter a serial number.
You can click the Stop Testing button at any time to terminate the execution.
Related concepts:
■ Model Callbacks in the Sequential Process Model
■ Process Model Architecture
■ TestStand Directory Structure
■ Callback Sequences
■
Organizing Test Program Files with LabVIEW-Built Shared Libraries

Overriding PreUUT and PostUUT Parallel Model Callbacks

Purpose
This example demonstrates how to override the default UUT Information dialog box
in the Parallel process model, override the ModelOptions callback to disable the
default dialog box, and override the PreUUT callback to define a new method for
obtaining the serial number. Optionally, you can override the PostUUT callback to
obtain the status of a test socket after it finishes a run.

© National Instruments 199

TestStand User Manual

Example File Location

<TestStand Public>\Examples\Modifying Process Models\Overriding Model
Callbacks - Parallel Model\Overriding PreUUT and PostUUT Callbacks.seq

Highlighted Features
Parallel process model

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to run this example.
1. Select Execute»Test UUTs to run the sequence. Each test socket in the
parallel execution launches a UUT Information dialog box that prompts you to
enter a serial number. The dialog boxes launch because the default UUT
Information dialog box for the Parallel process model has been disabled.
2. Enter any serial number in each UUT Information dialog box and click OK.
3. Click OK when TestStand displays the results of each test.
4. Click Cancel in each UUT Information dialog box to stop executing each test
socket. Each Execution window displays a report.
5. Select Window»Close Completed Executions to close all the Execution
windows.
Complete the following steps to review the sequences and steps used in the
example.
1. On the Sequences pane, select the ModelOptions callback sequence.

200 ni.com
TestStand User Manual

2. On the Steps pane, select the Change setting to not show dialog step,
which is a Statement step.
3. On the Step Settings pane, click the Expression edit tab. The Expression
control specifies an expression that disables the default UUT Information
dialog box for the Parallel process model.
4. On the Sequences pane, select the PreUUT callback sequence. This sequence
specifies two Action steps that use the C/C++ DLL Adapter and call a DLL that
returns screen size information TestStand uses to determine where the new
dialog boxes need to launch on the screen. The TestSocket Serial Num
Message Popup step, which is a Message Popup step, requests the serial
number for each test socket TestStand executes in parallel.
You can complete the following steps to re-enable the default UUT Information
dialog box.
1. On the Sequences pane, select the ModelOptions callback sequence.
2. On the Step Settings pane for the Change setting to not show dialog step, click
the Properties tab.
3. Click Run Options on the Properties tab to show the Run Options panel.
4. Select Skip from the Run Mode ring control.
5. Select Execute»Test UUTs to run the sequence. Click No when TestStand
prompts you to save changes to the sequence file. The default UUT
Information dialog box launches to prompt you to enter test socket serial
numbers.
6. Close the sequence file and do not save any changes.
Related concepts:
■ Model Callbacks in the Parallel Process Model
■ TestStand Directory Structure
■ Parallel Process Model
■
Organizing Test Program Files with LabVIEW-Built Shared Libraries

Overriding PreUUT and PostUUT Batch Model Callbacks

© National Instruments 201

TestStand User Manual

Purpose
This example demonstrates how to override the PreUUT callback to customize the
batch and test socket serial number entry and how to override the PostUUT callback
to customize the batch and test socket status report.

Example File Location

<TestStand Public>\Examples\Modifying Process Models\Overriding Model
Callbacks - Batch Model\Overriding PreUUT and PostUUT Callbacks.seq

Highlighted Features
Batch process model

Major API
None

Prerequisites
None

How to Use This Example

This example overrides the PreUUT and PostUUT callbacks, but the
OverrideSerialNumForBatchModel1.seq example sequence file overrides the
PreBatch and PostBatch callbacks.
The advantage of overriding the PreUUT and PostUUT callbacks, and not the
PreBatch and PostBatch callbacks, is that TestStand executes the PreUUT and
PostUUT callbacks in parallel for each test socket, and on some computers this
might improve performance and allow for simpler code in the callbacks.
The disadvantages include the following:
■ You can disable test sockets only in the PreBatch callback. You cannot
disable test sockets in the PreUUT callback.

202 ni.com
TestStand User Manual

■ Test sockets you have disabled, terminated, or aborted never call the
PreUUT and PostUUT callbacks. If you want to record information for the test
sockets, you must do so in the PreBatch and PostBatch callbacks.
Related concepts:
■
Model Callbacks in the Batch Process Model
■ TestStand Directory Structure
■ Batch Process Model
■
Overriding PreBatch and PostBatch Model Callbacks

Overriding PreBatch and PostBatch Model Callbacks

Purpose
This example demonstrates how to override the PreBatch callback to customize the
batch and test socket serial number entry and how to override the PostBatch
callback to customize the batch and test socket status report.

Example File Location

<TestStand Public>\Examples\Modifying Process Models\Overriding Model
Callbacks - Batch Model\Overriding PreBatch and PostBatch Callbacks.seq

Highlighted Features
Batch process model

Major API
None

Prerequisites
None

© National Instruments 203

TestStand User Manual

How to Use This Example

This example overrides the PreBatch and PostBatch callbacks, but the
OverrideSerialNumForBatchModel2.seq example sequence file overrides the
PreUUT and PostUUT callbacks.
The advantages of overriding the PreBatch and PostBatch callbacks, and not the
PreUUT and PostUUT callbacks, include the following:
■ You can enable or disable test sockets.
■ You can access data for test sockets you have disabled, terminated, or
aborted.
The disadvantage is that you must set or retrieve information for each test socket in
a loop instead of in parallel.
Related concepts:
■
Model Callbacks in the Batch Process Model
■ TestStand Directory Structure
■ Batch Process Model
■ Overriding PreUUT and PostUUT Batch Model Callbacks

Examples for Modifying User Interfaces

The Modifying User Interfaces examples demonstrate common TestStand user
interface features and customizations. This directory includes the following example
programs.

Building a TestStand UI with Native Controls

The <TestStand Public>\Examples\Modifying User Interfaces\Building a TestStand UI
with Native Controls directory contains the following examples.
Related concepts:
■ TestStand Directory Structure
Building a TestStand UI with Native Controls - LabWindows/CVI

204 ni.com
TestStand User Manual

Purpose
This example shows how to create a TestStand user interface using only
LabWindows/CVI controls. The UI uses the TestStand UI manager controls to
manage the application.

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Building a TestStand UI
with Native Controls\CVI\TestStand UI with Native Controls.prj

Highlighted Features
TestStand User Interface API

Major API
■ ApplicationManager.GetCommand
■ Command.Execute

Prerequisites
You must have LabWindows/CVI installed to execute this example.

How to Use This Example

Complete the following steps to review the code in this example:
1. In TestStand UI with Native Controls.prj, open TestExec.c.
2. Select the Initialize case. In this case, references to the manager controls and
the LabVIEW controls are stored in the UI data cluster, and this application is
set as the main TestStand window.
3. Find the SetupActiveXControls function. This case specifies callback functions
that will execute when a TestStand event occurs. Refer to the in-line
comments for more information.

© National Instruments 205

TestStand User Manual

Note The user interface used control callbacks to implement

functionality for controls, in the same way as a typical CVI UI
application. These callbacks use the
TSUI_ApplicationMgrGetCommand and TSUI_CommandExecute
functions to implement TestStand-specific functionality.

Complete the following steps to run the example:

1. (64-bit TestStand) Navigate to Build»Configuration and select Debug64 as
the configuration.
2. Click Debug Project to start the user interface.
3. Select Open Sequence File to open a sequence file, then select Execute to
run the file using the first entry point in the current process model.
4. Once the execution completes, the report file path is added to the table
control. This functionality is implemented in the
ApplicationMgr_OnEndExecution event callback.
Related concepts:
■ TestStand Directory Structure
■
TestStand API Overview
Building a TestStand UI with Native Controls - LabVIEW

Purpose
This example shows how to create a TestStand user interface using only LabVIEW
controls. The UI uses the TestStand UI manager controls to manage the application.

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Building a TestStand UI
with Native Controls\LabVIEW\TestStand UI with Native Controls.lvproj

Highlighted Features
TestStand User Interface API

206 ni.com
TestStand User Manual

Major API
■ ApplicationManager.GetCommand
■ Command.Execute

Prerequisites
You must have the LabVIEW Development System installed to execute this example.

How to Use This Example

Complete the following steps to review the code in this example:
1. In TestStand UI with Native Controls.lvproj, open
BasicUIwithNativeControls.vi.
2. Select the Initialize case. In this case, references to the manager controls and
the LabVIEW controls are stored in the UI data cluster, and this application is
set as the main TestStand window.
3. Select the Register Event Callbacks case. This case specifies callback VIs
that will execute when a TestStand event occurs. Refer to the in-line
comments for more information.
4. Select the Handle Events case. This case handles user interaction. Within
the event cases, the GetCommand and Command.Execute methods are called
to implement TestStand-specific functionality.
5. Select the Shutdown case. This case closes all references and closes the
panel.
Complete the following steps to run the example:
1. Click Run to start the user interface.
2. Select Open Sequence File to open a sequence file, then select Execute to
run it using the first entry point in the current process model.
3. Once the execution completes, the report file path is added to the table
control. This functionality is implemented in the EndExecution event callback.

© National Instruments 207

TestStand User Manual

Related concepts:
■ TestStand Directory Structure
■
TestStand API Overview
Building a TestStand UI with Native Controls - LabVIEW NXG

Purpose
This example shows how to create a TestStand user interface using only LabVIEW
NXG controls. The UI uses the TestStand UI manager controls to manage the
application.

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Building a TestStand UI
with Native Controls\LabVIEW NXG\TestStand UI with Native Controls.lvproject

Highlighted Features
TestStand User Interface API

Major API
■ ApplicationManager.GetCommand
■ Command.Execute

Prerequisites
You must have the LabVIEW NXG Development System installed to execute this
example.

How to Use This Example

Complete the following steps to review the code in this example:
1. In TestStand UI with Native Controls.lvproject, open
BasicUIwithNativeControls.gvi.

208 ni.com
TestStand User Manual

2. Select the Initialize case. In this case, references to the manager controls and
the LabVIEW controls are stored in the UI data cluster, and this application is
set as the main TestStand window.
3. Select the Register Event Callbacks case. This case specifies callback VIs
that will execute when a TestStand event occurs. Refer to the in-line
comments for more information.
4. Select the Handle Events case. This case handles user interaction. Within
the event cases, the GetCommand and Command.Execute methods are called
to implement TestStand-specific functionality.
5. Select the Shutdown case. This case closes all references and closes the
panel.
Complete the following steps to run the example:
1. Click Run to start the user interface.
2. Select Open Sequence File to open a sequence file, then select Execute to
run it using the first entry point in the current process model.
3. Once the execution completes, the report file path is added to the table
control. This functionality is implemented in the EndExecution event callback.
Related concepts:
■ TestStand Directory Structure
■ TestStand API Overview
Building a TestStand UI with Native Controls - .NET

Purpose
This example shows how to create a TestStand user interface using only .NET
controls. The UI uses the TestStand UI manager controls to manage the application.

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Building a TestStand UI
with Native Controls\dotNET\TestStand UI with Native Controls.sln

© National Instruments 209

TestStand User Manual

Highlighted Features
TestStand User Interface API

Major API
■ ApplicationManager.GetCommand
■ Command.Execute

Prerequisites
You must have Visual Studio installed to execute this example.

How to Use This Example

Complete the following steps to review the code in this example:
1. In TestStand UI with Native Controls.sln, right-click MainForm.cs.
2. Select the ApplicationManager control, then click Events in the properties
pane. Notice that callbacks have been specified for certain TestStand events.
Double-click a callback to view the code.

Note The user interface used control callbacks to implement

functionality for controls, in the same way as a typical .NET UI
application. These callbacks use the axApplicationMgr.GetCommand
and Command.Execute methods to implement TestStand-specific
functionality.

Complete the following steps to run the example:

1. Click Start Debugging to start the user interface.
2. Select Open Sequence File to open a sequence file, then select Execute to
run the file using the first entry point in the current process model.

210 ni.com
TestStand User Manual

3. Once the execution completes, the report file path is added to the table
control. This functionality is implemented in the
axApplicationMgr_EndExecution event callback.
Related concepts:
■
TestStand Directory Structure
■ TestStand API Overview

Connecting UI Controls Demo

Purpose
The Connecting Controls User Interface demonstrates the available TestStand User
Interface controls and allows you to customize their functionality. The TestStand
User Interface controls get their functionality through a connection to a manager
control. The manager controls provide methods to implement the various types of
connections.
This example allows you to explore the available connections and see their behavior
in real time.

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Connecting UI
Controls\DotNet\bin\Release\TestExec.exe

Highlighted Features
TestStand User Interface Controls

Major API
UI Connection methods

Prerequisites
None

© National Instruments 211

TestStand User Manual

How to Use This Example

To launch the User Interface, Open the TestExec.exe executable. The UI
automatically opens a sequence file and runs a sequence, then pauses the sequence
at a breakpoint.
Navigate the tabs of the interface to view the different UI controls available with
TestStand and the types of connections to manager controls that they support. Each
tab provides more information about each of the following UI Control connection
types:
■ View Connections—Activates a SequenceView, VariablesView, or
ReportView control. The manager controls provide a separate method for
each connection type, so no cmdKind parameter is needed.
■ List Connections—Configures a TestStand ComboBox, ListBarPage, or
ListBox to display a TestStand List, such as the sequences in the current file.
The manager controls provide a separate method for each connection type, so
no cmdKind parameter is needed.
■ Command Connections—Configures a TestStand Button or Checkbox
control to execute a specified command when clicked. Change the
enumerations to see the behavior of the available command kinds.
■ Information Source Connections—Displays caption, image, and
numeric information on Label controls, ExpressionEdit controls, and
StatusBar panes. Changing the source Input will change what information is
displayed in the connected control.
Click the Additional Information button in the example UI to view more
information about these connection types.
Related concepts:
■ TestStand Directory Structure
■ TestStand API Overview
■ Connecting Manager Controls to Visible Controls

Creating a Basic User Interface

212 ni.com
TestStand User Manual

The <TestStand Public>\Examples\Modifying User Interfaces\Creating a Basic User

Interface directory contains the following examples.
Related concepts:
■ TestStand Directory Structure
Creating a Basic User Interface - LabWindows/CVI

Purpose
This example provides a simplified user interface to demonstrate the architecture of
a TestStand user interface. The interface code demonstrates the following actions in
a TestStand interface:
■ Provide functionality to TestStand controls by connecting them to manager
controls
■ Register callbacks to execute when TestStand events occur

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Creating a Basic User
Interface\CVI\Basic User Interface.prj

Highlighted Features
■ TestStand User Interface Controls
■ TestStand User Interface API

Major API
TestStand User Interface API

Prerequisites
You must have LabWindows/CVI installed to execute this example.

© National Instruments 213

TestStand User Manual

How to Use This Example

Complete the following steps to run the example:
1. (64-bit TestStand) Navigate to Build»Configuration and select Debug64 as
the configuration.
2. Click Debug Project to start the user interface.
3. Notice that the control functionality matches the specified connections in the
SetupActiveXControls function.
4. Use the interface to open a sequence file and execute it. The execution
displays in the executionView control if tracing is enabled.
Complete the following steps to review the sequences and steps in this example:
1. In Basic User Interface.prj, open TestExec.c.
2. Find the SetupActiveXControls function. This function registers callback
functions that will execute when a TestStand event occurs. Also, the TestStand
UI controls are connected to manager controls to give them functionality.
Refer to the in-line comments for more information.
Related concepts:
■ TestStand Directory Structure
■ TestStand API Overview
Creating a Basic User Interface - LabVIEW

Purpose
This example provides a simplified user interface to demonstrate the architecture of
a TestStand user interface. The interface code demonstrates the following actions in
a TestStand interface:
■ Initialize the TestStand engine
■ Provide functionality to TestStand controls by connecting them to manager
controls
■ Register callbacks to execute when TestStand events occur

214 ni.com
TestStand User Manual

■ Shut down TestStand

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Creating a Basic User
Interface\LabVIEW\Basic User Interface.lvproj

Highlighted Features
■ TestStand User Interface Controls
■ TestStand User Interface API

Major API
TestStand User Interface API

Prerequisites
You must have the LabVIEW Development System involved to execute this example.

How to Use This Example

Complete the following steps to run the example:
1. Click Run to start the user interface.
2. Notice that the control functionality matches the specified connections in the
Configure Connections case.
3. Use the interface to open a sequence file and execute it. The execution
displays in the executionView control if tracing is enabled.
Complete the following steps to review the sequences and steps in this example:
1. In Basic User Interface.lvproj, open TestStand Basic User interface.vi.
2. Select the Initialize case. In this case, references to the UI controls are stored
in the UI data cluster, and this application is set as the main TestStand
window.

© National Instruments 215

TestStand User Manual

3. Select the Configure Connections case. In this case, the TestStand UI

controls are connected to manager controls to give them functionality. Refer
to the in-line comments for more information.
4. Select the Register Event Callbacks case. This case specifies callback VIs
that will execute when a TestStand event occurs. Refer to the in-line
comments for more information.
5. Select the Handle Events case. This case handles LabVIEW specific events,
such as closing the panel. Refer to the in-line comments for more information.
6. Select the Shutdown case. This case closes all references and closes the
panel.
Related concepts:
■
TestStand Directory Structure
■ TestStand API Overview
Creating a Basic User Interface - LabVIEW NXG

Purpose
This example provides a simplified user interface to demonstrate the architecture of
a TestStand user interface. The interface code demonstrates the following actions in
a TestStand interface:
■ Initialize the TestStand engine
■ Provide functionality to TestStand controls by connecting them to manager
controls
■ Register callbacks to execute when TestStand events occur
■ Shut down TestStand

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Creating a Basic User
Interface\LabVIEW NXG\Basic UI.lvproject

216 ni.com
TestStand User Manual

Highlighted Features
■ TestStand User Interface Controls
■ TestStand User Interface API

Major API
TestStand User Interface API

Prerequisites
You must have the LabVIEW NXG Development System installed to execute this
example.

How to Use This Example

Complete the following steps to run the example:
1. Click Run to start the user interface.
2. Notice that the control functionality matches the specified connections in the
Configure Connections case.
3. Use the interface to open a sequence file and execute it. The execution
displays in the executionView control if tracing is enabled.
Complete the following steps to review the sequences and steps in this example:
1. In Basic User Interface.lvproj, open TestStand Basic User interface.gvi.
2. Select the Initialize case. In this case, references to the UI controls are stored
in the UI data cluster, and this application is set as the main TestStand
window.
3. Select the Configure Connections case. In this case, the TestStand UI
controls are connected to manager controls to give them functionality. Refer
to the in-line comments for more information.

© National Instruments 217

TestStand User Manual

4. Select the Register Event Callbacks case. This case specifies callback
nodes that will execute when a TestStand event occurs. Refer to the in-line
comments for more information.
5. Select the Handle Events case. This case handles LabVIEW NXG specific
events, such as closing the panel. Refer to the in-line comments for more
information.
6. Select the Shutdown case. This case closes all references and closes the
panel.
Related concepts:
■
TestStand Directory Structure
■ TestStand API Overview
Creating a Basic User Interface - .NET

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Creating a Basic User
Interface\DotNet\Basic User Interface.sln

Highlighted Features
■ TestStand User Interface Controls
■ TestStand User Interface API

218 ni.com
TestStand User Manual

Major API
TestStand User Interface API

Prerequisites
You must have Visual Studio installed to execute this example.

How to Use This Example

Complete the following steps to run the example:
1. Click Run to start the user interface.
2. Notice that the control functionality matches the specified connections in the
MainForm_Load method.
3. Use the interface to open a sequence file and execute it. The execution
displays in the executionView control if tracing is enabled.
Complete the following steps to review the sequences and steps in this example.
1. Open Basic User Interface.sln in Visual Studio, then right click
MainForm.cs and select View Code.
2. Find the MainForm_Load method. Within this method, the TestStand UI
controls are connected to manager controls to give them functionality. Refer
to the in-line comments for more information.
3. Double click MainForm.cs to view the designer. Select the
ApplicationManager control, then click Events in the properties pane. Notice
that callback functions have been specified for certain TestStand events.
Double click the event callback to view the callback code.
Related concepts:
■ TestStand Directory Structure
■ TestStand API Overview

Handling UI Messages

© National Instruments 219

TestStand User Manual

The <TestStand Public>\Examples\Modifying User Interfaces\Handling UI Messages

directory contains the following examples.
Related concepts:
■ TestStand Directory Structure
Handling UI Messages - LabWindows/CVI

Purpose
This example shows how you can use custom UI messages to communicate between
the client sequence file and the user interface.
■ Sending data from the sequence to the UI—The Sequence posts UI
messages containing a status string. The UI message handler reads the string
and updates a UI control with the data.
■ Sending data from the UI to the sequence—Before executing, the
sequence posts a message requesting the state of the "show dialogs" UI
setting. The UI message handler sets the Locals.ShowDialogs sequence
property using the TestStand API, based on the value specified in the UI.

Note In order for the UI messages posted in this sequence to be handled,

you must execute the sequence in the "Basic User Interface with UI
Message Handler" Interface, located in the language specific subfolders of
this sequence file. While the sequence will run successfully in the
Sequence Editor or other user interfaces, the user messages posted will
have no effect.

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Handling UI
Messages\CVI\Using Custom UI Messages.prj

Highlighted Features
■ User Interface Messages

220 ni.com
TestStand User Manual

■ TestStand User Interface controls

Major API
Thread.PostUIMessageEx

Prerequisites
You must have LabWindows/CVI installed to execute this example.

How to Use This Example

Complete the following steps to run the example:
1. (64-bit TestStand) Navigate to Build»Configuration and select Debug64 as
the configuration.
2. Click Debug Project in CVI to start the user interface. The UI Message
example sequence is opened by the UI automatically.
3. Run the sequence. Notice that the sequence status is updated as each UI
message is posted with ID 10100.
4. After the execution completes, uncheck the Show Sequence Dialogs option
on the user interface. Run the sequence again, and notice that the message
dialogs no longer appear. The dialogs no longer appear because the Sequence
File posts UI message 10200. The handler for this message sets the
FileGlobals.ShowDialogs property to the value of the Show Sequence Dialogs
setting in the setup step group.
5. You can optionally execute this sequence file in other user interfaces that do
not handle the specified user messages. The sequence will run successfully,
but the user messages posted will have no effect.
Complete the following steps to review the UI message handling code in the CVI UI:
1. In Using Custom UI Messages.prj, open TestExec.c.
2. Find the function TSUI__ApplicationMgrEventsRegOnUserMessage. This
function registers the ApplicationMgr_OnUserMessage function as the User
Message message handler. The UserMessage Event begins when a UI message

© National Instruments 221

TestStand User Manual

with ID greater than 10000 is posted. These IDs are reserved for user-
generated messages.
3. Find the ApplicationMgr_OnUserMessage function. Notice that each UI
message is defined as a case in the switch block. These cases define how each
UI message is handled.
Complete the following steps to review how UI messages are posted from an
executing sequence:
1. Open the example sequence file <TestStand Public>\Examples\Modifying User
Interfaces\Handling UI Messages\UI Message Example.seq
2. Inspect the statement steps. Each of these steps posts a UI message using the
Thread.postUIMessageEx method.
Related concepts:
■ TestStand Directory Structure
■ User Interface Messages (UIMessages)
■ TestStand API Overview
Handling UI Messages - LabVIEW

Note In order for the UI messages posted in this sequence to be handled,

you must execute the sequence in the "Basic User Interface with UI
Message Handler" Interface, located in the language specific subfolders of

222 ni.com
TestStand User Manual

this sequence file. While the sequence will run successfully in the
Sequence Editor or other user interfaces, the user messages posted will
have no effect.

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Handling UI
Messages\LabVIEW\Using Custom UI Messages.lvproj

Highlighted Features
■ User Interface Messages
■ TestStand User Interface controls

Major API
Thread.PostUIMessageEx

Prerequisites
You must have the LabVIEW Development System installed to view this example.

How to Use This Example

Complete the following steps to run the example:
1. In Using Custom UI Messages.lvproj, open Basic User Interface with UI
Message Handler.vi.
2. Click the Run button on the VI to start the user interface. The UI Message
example sequence is opened by the UI automatically.
3. Run the sequence. Notice that the sequence status is updated as each UI
message is posted with ID 10100.
4. After the execution completes, uncheck the Show Sequence Dialogs option
on the user interface. Run the sequence again and notice that the message
dialogs no longer appear. The dialogs no longer appear because the Sequence
File posts UI message 10200. The handler for this message sets the

© National Instruments 223

TestStand User Manual

FileGlobals.ShowDialogs property to the value of the Show Sequence Dialogs

setting in the setup step group.
5. You can optionally execute this sequence file in other user interfaces that do
not handle the specified user messages. The sequence will run successfully,
but the user messages posted will have no effect.
Complete the following steps to review the UI message handling code in the UI:
1. In Using Custom UI Messages.lvproj, open Basic User Interface with UI
Message Handler.vi.
2. In the Register Event Callbacks case, notice that UserMessage Event
Callback.vi is registered to the UserMessage event.
3. Open the UserMessage Event Callback.vi and review the message handling
code in each case.
Complete the following steps to review how UI messages are posted from an
executing sequence:
1. Open the example sequence file <TestStand Public>\Examples\Modifying User
Interfaces\Handling UI Messages\UI Message Example.seq
2. Inspect the statement steps. Each of these steps posts a UI message using the
Thread.postUIMessageEx method.
Related concepts:
■ TestStand Directory Structure
■
User Interface Messages (UIMessages)
■ TestStand API Overview
Handling UI Messages - LabVIEW NXG

224 ni.com
TestStand User Manual

■ Sending data from the UI to the sequence—Before executing, the

sequence posts a message requesting the state of the "show dialogs" UI
setting. The UI message handler sets the Locals.ShowDialogs sequence
property using the TestStand API, based on the value specified in the UI.

Note In order for the UI messages posted in this sequence to be handled,

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Handling UI
Messages\LabVIEW NXG\Using Custom UI Messages.lvproject

Highlighted Features
■ User Interface Messages
■ TestStand User Interface controls

Major API
Thread.PostUIMessageEx

Prerequisites
You must have the LabVIEW NXG Development System installed to view this
example.

How to Use This Example

Complete the following steps to run the example:

© National Instruments 225

TestStand User Manual

1. In Using Custom UI Messages.lvproj, open Basic User Interface with UI

Message Handler.gvi.
2. Click the Run button on the VI to start the user interface. The UI Message
example sequence is opened by the UI automatically.
3. Run the sequence. Notice that the sequence status is updated as each UI
message is posted with ID 10100.
4. After the execution completes, uncheck the Show Sequence Dialogs option
on the user interface. Run the sequence again and notice that the message
dialogs no longer appear. The dialogs no longer appear because the Sequence
File posts UI message 10200. The handler for this message sets the
FileGlobals.ShowDialogs property to the value of the Show Sequence Dialogs
setting in the setup step group.
5. You can optionally execute this sequence file in other user interfaces that do
not handle the specified user messages. The sequence will run successfully,
but the user messages posted will have no effect.
Complete the following steps to review the UI message handling code in the UI:
1. In Using Custom UI Messages.lvproj, open Basic User Interface with UI
Message Handler.gvi.
2. In the Register Event Callbacks case, notice that UserMessage Event
Callback.vi is registered to the UserMessage event.
3. Open the UserMessage Event Callback.gvi and review the message handling
code in each case.
Complete the following steps to review how UI messages are posted from an
executing sequence:
1. Open the example sequence file <TestStand Public>\Examples\Modifying User
Interfaces\Handling UI Messages\UI Message Example.seq
2. Inspect the statement steps. Each of these steps posts a UI message using the
Thread.postUIMessageEx method.
Related concepts:
■ TestStand Directory Structure
■ User Interface Messages (UIMessages)

226 ni.com
TestStand User Manual

■ TestStand API Overview

Handling UI Messages - .NET

Note In order for the UI messages posted in this sequence to be handled,

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Handling UI
Messages\DotNet\Handling UI Messages.sln

Highlighted Features
■ User Interface Messages
■ TestStand User Interface controls

TestStand User Manual

Major API
Thread.PostUIMessageEx

Prerequisites
You must have Visual Studio installed to execute this example.

How to Use This Example

Complete the following steps to run the example:
1. Click Start Debugging in Visual Studio to start the user interface. The UI
Message example sequence is opened by the UI automatically.
2. Run the sequence. Notice that the sequence status is updated as each UI
message is posted with ID 10100.
3. After the execution completes, uncheck the Show Sequence Dialogs option
on the user interface. Run the sequence again and notice that the message
dialogs no longer appear. The dialogs no longer appear because the Sequence
File posts UI message 10200. The handler for this message sets the
FileGlobals.ShowDialogs property to the value of the Show Sequence Dialogs
setting in the setup step group.
4. You can optionally execute this sequence file in other user interfaces that do
not handle the specified user messages. The sequence will run successfully,
but the user messages posted will have no effect.
Complete the following steps to review the UI message handling code in the UI:
1. In Handling UI Messages.sln, open MainForm.cs.
2. In the form designer, select the Application manager control. In the properties
pane, click the Events icon to view the registered events for the
ApplicationManager.
3. Find the User message event, and notice that the
axApplicationMgr_UserMessageCallback method is registered to handle this
event. The UserMessage Event begins when a UI message with ID greater than
10000 is posted. These IDs are reserved for user-generated messages.

228 ni.com
TestStand User Manual

4. Double click the ApplicationMgr_OnUserMessage to navigate to the

method code. Notice that each UI message is defined as a case in the switch
block. These cases define how each UI message is handled.
Complete the following steps to review how UI messages are posted from an
executing sequence:
1. Open the example sequence file <TestStand Public>\Examples\Modifying User
Interfaces\Handling UI Messages\UI Message Example.seq
2. Inspect the statement steps. Each of these steps posts a UI message using the
Thread.postUIMessageEx method.
Related concepts:
■ TestStand Directory Structure
■ User Interface Messages (UIMessages)
■ TestStand API Overview

Updating the Status Bar Using UI Messages

The <TestStand Public>\Examples\Modifying User Interfaces\Updating the Status
Bar Using UI Messages directory contains the following examples.
Related concepts:
■ TestStand Directory Structure
Updating the Status Bar Using UI Messages - LabWindows/CVI

Purpose
This example demonstrates how to use LabWindows/CVI to show step execution
progress and status in the TestStand Sequence Editor or Execution window.

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Updating the Status Bar
Using UI Messages\CVI\Updating the Status Bar Using UI Messages.seq

TestStand User Manual

Highlighted Features
■ LabWindows/CVI Adapter
■ Execution

Major API
■ SequenceContext
■ Thread
■ Thread.PostUIMessage
■ UIMessageCodes Enumeration

Prerequisites
None

How to Use This Example

Complete the following steps to use this example.
1. Open the DisplayingProgressAndStatus.c source file, located in the <TestStand
Public>\Examples\Modifying User Interfaces\Updating the Status Bar Using UI
Messages\CVI directory. The source file specifies the following functionality:
■ Lines 29 and 46—The tsErrChkMsgPopup function uses
TS_ThreadPostUIMessage to post a ProgressPercent user interface (UI)
message that updates the progress bar the sequence displays in TestStand
with the percent complete.
■ Lines 33 and 43—The tsErrChkMsgPopup function uses
TS_ThreadPostUIMessage to post a ProgressText UI message to update the
progress text on the status bar with the percent finished.
2. Close the source file. Do not save any changes.
3. In TestStand, select Execute»Single Pass to run the sequence. Review the
progress bar and progress status field on the status bar of the sequence editor.

230 ni.com
TestStand User Manual

Related concepts:
■ TestStand Directory Structure
■
Programming with the TestStand API in LabWindows/CVI
■ Executions
Updating the Status Bar Using UI Messages - LabVIEW

Purpose
This example demonstrates how to use LabVIEW to show step execution progress
and status in the TestStand Sequence Editor or Execution window.

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Updating the Status Bar
Using UI Messages\LabVIEW\Updating the Status Bar Using UI Messages.seq

Highlighted Features
■ LabVIEW Adapter
■ Execution

Major API
■ SequenceContext
■ Thread
■ Thread.PostUIMessage
■ UIMessageCodes Enumeration

Prerequisites
You must have the LabVIEW development system installed and you must configure
the LabVIEW Adapter to use the LabVIEW development system.

TestStand User Manual

How to Use This Example

Complete the following steps to use this example.
1. On the Steps pane, select the Call Long Test step, which is an Action step
that uses the LabVIEW Adapter.
2. On the Step Settings pane, click the LabVIEW Module tab.
3. Click the Edit VI button, located to the right of the VI Path control, to open in
LabVIEW the VI the Call Long Test step calls.
4. In LabVIEW, switch to the block diagram and select Help»Show Context
Help to display the Context Help window for the block diagram. The block
diagram specifies the following functionality for the VI:
■ The Sequence Context property node obtains a reference to the Thread
object and initializes the termination monitor.
■ The execution enters the Stacked Sequence Structure and executes frame
0. Select frame 0 of the Stacked Sequence Structure. The Start Time is stored
in the sequence local variable.
■ Select frame 1 of the Stacked Sequence Structure. The Get Monitor
Termination Status VI stops the VI if you terminate or abort the execution. If
you do not terminate or abort the execution, the False case of the case
structure executes.
■ The VI invokes the Thread.PostUIMessage method and posts a
ProgressPercent user interface (UI) message that updates the progress bar
the sequence displays in TestStand with the percent complete.
■ The VI posts a ProgressText UI message to update the progress text on the
status bar with the percent finished. This behavior continues in the While
loop until the time limit expires or you terminate or abort the execution. If
the time limit expires, the execution continues to frame 2 of the Stacked
Sequence Structure.
■ Select frame 2. In the False case of the case structure, the progress bar
updates to 100 percent and the progress text updates to Test Finished.
■ The Thread object reference the terminator monitor close.
5. Close the VI. Do not save any changes.

232 ni.com
TestStand User Manual

6. In TestStand, select Execute»Single Pass to run the sequence. Review the

progress bar and progress status field on the status bar of the sequence editor.
Related concepts:
■
TestStand Directory Structure
■ Programming with the TestStand API in LabVIEW
■
Executions
Updating the Status Bar Using UI Messages - LabVIEW NXG

Purpose
This example demonstrates how to use LabVIEW NXG to show step execution
progress and status in the TestStand Sequence Editor or Execution window.

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Updating the Status Bar
Using UI Messages\LabVIEW NXG\Updating the Status Bar Using UI Messages.seq

Highlighted Features
■ LabVIEW Adapter
■ Execution

Major API
■ SequenceContext
■ Thread
■ Thread.PostUIMessage
■ UIMessageCodes Enumeration

Prerequisites
You must have the LabVIEW NXG development system installed and you must
configure the LabVIEW NXG Adapter to use the LabVIEW development system.

TestStand User Manual

How to Use This Example

Complete the following steps to use this example.
1. On the Steps pane, select the Call Long Test step, which is an Action step
that uses the LabVIEW NXG Adapter.
2. On the Step Settings pane, click the LabVIEW NXG Module tab.
3. Click the Edit VI button, located to the right of the VI Path control, to open in
LabVIEW NXG the VI the Call Long Test step calls.
4. In LabVIEW NXG, switch to the block diagram and select Help»Show
Context Help to display the Context Help window for the block diagram. The
block diagram specifies the following functionality for the VI:
■ The Sequence Context property VI obtains a reference to the Thread object
and initializes the termination monitor.
■ The execution enters the Stacked Sequence Structure and executes frame
0. Select frame 0 of the Stacked Sequence Structure. The Start Time is stored
in the sequence local variable.
■ Select frame 1 of the Stacked Sequence Structure. The Get Monitor
Termination Status VI stops the VI if you terminate or abort the execution. If
you do not terminate or abort the execution, the False case of the case
structure executes.
■ The VI invokes the Thread.PostUIMessage method and posts a
ProgressPercent user interface (UI) message that updates the progress bar
the sequence displays in TestStand with the percent complete.
■ The VI posts a ProgressText UI message to update the progress text on the
status bar with the percent finished. This behavior continues in the While
loop until the time limit expires or you terminate or abort the execution. If
the time limit expires, the execution continues to frame 2 of the Stacked
Sequence Structure.
■ Select frame 2. In the False case of the case structure, the progress bar
updates to 100 percent and the progress text updates to Test Finished.
■ The Thread object reference the terminator monitor close.
5. Close the VI. Do not save any changes.

234 ni.com
TestStand User Manual

6. In TestStand, select Execute»Single Pass to run the sequence. Review the

Purpose
This example demonstrates how to use C++ to show step execution progress and
status in the TestStand Sequence Editor or Execution window.

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Updating the Status Bar
Using UI Messages\MFC\Updating the Status Bar Using UI Messages.seq

Highlighted Features
■ C/C++ DLL Adapter
■ Execution

Major API
None

Prerequisites
None

TestStand User Manual

How to Use This Example

AppWizard creates DisplayingProgressAndStatus.dll, which demonstrates the basics
of using the Microsoft Foundation Class (MFC) Library and serves as a starting point
for writing a custom DLL.
The following files, located in the <TestStand Public>\Examples\Modifying User
Interfaces\Updating the Status Bar Using UI Messages\MFC directory, make up
DisplayingProgressAndStatus.dll:
■ DisplayingProgressAndStatus.h—The main header file that declares the
CDisplayingProgressAndStatusApp class for the DLL.
■ DisplayingProgressAndStatus.cpp—The main DLL source file that contains
the CDisplayingProgressAndStatusApp class.
■ DisplayingProgressAndStatus.rc—A list of all the Microsoft Windows
resources the program uses, including icons, bitmaps, and cursors stored in
the res subdirectory. You can directly edit this file in Microsoft Developer
Studio.
■ res\DisplayingProgressAndStatus.rc2—Contains resources Developer
Studio does not edit. Place all resources the resource editor cannot edit in this
file.
■ DisplayingProgressAndStatus.def—Contains DLL information that must be
provided to run with Windows. This file defines parameters such as the name
and description of the DLL and exports functions from the DLL.
■ DisplayingProgressAndStatus.clw—Contains information ClassWizard uses
to edit existing classes, add new classes, and store information required to
create and edit message maps and dialog data maps and to create prototype
member functions.
Other standard files located in the <TestStand Public>\Examples\Modifying User
Interfaces\Updating the Status Bar Using UI Messages\MFC directory include the
following:
■ StdAfx.h and StdAfx.cpp—Used to build a precompiled header (PCH) file
named DisplayingProgressAndStatus.pch and a precompiled types file named
StdAfx.obj.

236 ni.com
TestStand User Manual

■ Resource.h—The standard header file that defines new resource IDs.

Developer Studio reads and updates this file.

Note AppWizard uses TODO: to indicate parts of the source code to which
you must add or that you must customize.

Related concepts:
■
TestStand Directory Structure
■ Organizing Test Program Files with LabVIEW-Built Shared Libraries
■ Executions
Updating the Status Bar Using UI Messages - .NET

Purpose
This example demonstrates how to show step execution progress and status in the
TestStand Sequence Editor or Execution window.

Example File Location

<TestStand Public>\Examples\Modifying User Interfaces\Updating the Status Bar
Using UI Messages\DotNET\Updating the Status Bar Using UI Messages.seq

Highlighted Features
■ Execution
■ .NET Adapter

Major API
■ SequenceContext
■ Thread
■ Thread.PostUIMessage
■ UIMessageCodes Enumeration

TestStand User Manual

Prerequisites
None

How to Use This Example

In TestStand, select Execute»Single Pass to run the sequence. Review the
progress bar and progress status field on the status bar of the sequence editor.
Related concepts:
■ TestStand Directory Structure
■
Executions

Examples for Parallel Testing

The Parallel Testing examples demonstrate TestStand features for running your test
code in parallel. This directory includes the following example programs.

Comparing Resource Usage Strategies

Description
This example demonstrates how to use the Execution Profiler to measure and
understand how different multithreaded resource usage strategies affect the
performance of a simultaneous test of four UUTs when each UUT requires a DMM
measurement and a scope measurement.

Example File Location

<TestStand Public>\Examples\Parallel Testing\Comparing Resource Usage
Strategies\Comparing Resource Usage Strategies.seq

Highlighted Features
■ Execution Profiler
■ Synchronization step types

238 ni.com
TestStand User Manual

Major API
N/A

Prerequisites
None

How to Use This Example

When you open the Comparing Resource Usage Strategies.seq example sequence
file, TestStand also launches the Execution Profiler window.
Complete the following steps to walk through the example:
1. In the TestStand Sequence Editor, select the MainSequence and select Run
MainSequence from the Execute menu. In the Execution Profiler window,
view the instrument usage in the Item Usage per Thread graph as the example
executes five sequences with five different strategies for using the DMM and
scope resources. Make the profiler window wider if your screen has room. The
first row of the graph shows per step locks on the top level sequence call
steps. The example has these locks to better highlight the duration of each
strategy in the profiler. Below the square for each lock, you can see the usage
of the DMM and scope resources for that strategy.
2. For Sequential, note that each UUT uses the DMM in turn, and then each UUT
uses the scope in turn.
3. For Parallel, note that each UUT uses the DMM as soon as it is available and
then uses the scope as soon as it is available.
4. For Auto-scheduled, note that each UUT first uses an instrument of either
kind, as soon as one is available, and then uses the other kind of instrument
as soon as it is available.
5. For Parallel With Additional DMM, note that each UUT first uses either one of
two DMMs as soon as one is available and then uses the scope as soon as it is
available.

TestStand User Manual

6. For Auto Scheduled With Additional DMM, note that each UUT first uses any
instrument, as soon as one is available. It then uses the remaining type of
instrument as soon as one is available.
7. Note that each strategy completes in a shorter time than the previous
strategy.
8. Open the View menu in the profiler. To focus on the instrument usage only,
the example unchecked the following menu items when it launched the
profiler in its SequenceFileLoad sequence:
■ Show Blocked Threads
■ Show Code Modules»Step
■ Show Code Modules»Step Type
■ Show Code Modules»Load
■ Show Code Modules»Unload
■ Show Synchronization»Show Auto Scheduling
■ Show Synchronization»Show Batch Synchronization
■ Show Synchronization»Show Wait Operations
■ Show Steps
■ Show UUTs, Batches, and Lots
Toggle each menu item on and off to observe the additional data the profiler
displays when each item is on.
Complete the following steps to walk through the example:
1. Checkmark the following items in the View menu:
■ Show Blocked Threads
■ Show Synchronization»Show Auto Scheduling
■ Show Synchronization»Show Batch Synchronization
■ Show Synchronization»Show Wait Operations
■ Show UUTs, Batches, and Lots
2. Click Clear and complete the following steps:

240 ni.com
TestStand User Manual

a. In the TestStand Sequence Editor, right-click the Sequential step in the

Main step group of the MainSequence and select Run Selected Steps
from the context menu.
b. In the Execution Profiler window, checkmark Auto Fit below the Item
Usage Per Thread graph. The Sequential strategy example sequentially
runs the DMM test and then the scope test on each UUT. For each test
socket thread, the Item Usage per Thread graph shows the use of the
DMM resource and the scope resource. The red rectangles in the graph
whose tool tips contain Batch Synchronization indicate threads waiting
to enter and exit Batch Serial Sections, which is the mechanism this
example uses to enforce sequential use of the DMM and scope
resources. You can hide the Batch Synchronization operations by
unchecking View»Show Batch Synchronized Sections. The
Sequential strategy example uses Wait steps to simulate instrument
usage. In addition, the Sequential step in the MainSequence is
configured to wait for the execution it launches to complete. You can
hide the Wait operations by unchecking View»Show Wait
Operations. The graph also shows that none of the resources are used
in parallel. The time displayed when you hover over the square labeled
<No Serial Number> (Batch) is 30 seconds, which is the time it took to
test the batch of UUTs. The proceeding steps attempt to lower the total
time span value.
c. Click the Clear button to remove the graph information.
d. In the sequence editor, right-click the Parallel step in the Main step
group of the MainSequence and select Run Selected Steps from the
context menu. In the Execution Profiler window, notice that all threads
attempt to use the DMM, but only one thread acquires the DMM while
the other threads block. As each thread completes the DMM test,
another thread can acquire the DMM. You can hide the time that threads
block while waiting to acquire resources from the graph in the profiler
window display by unchecking View»Show Blocked Threads.
Because the DMM and scope resources are used in parallel much of the
time, the length of the Batch reduces to 21 seconds. However, because
each thread first uses the DMM and then uses the scope, no parallelism
exists until the first thread releases the DMM.

TestStand User Manual

e. Click the Clear button to remove the graph information and select
View»Show Blocked Threads to show the time that threads block
while waiting to acquire resources.
f. In the sequence editor, right-click the Auto Schedule step in the Main
step group of the MainSequence and select Run Selected Steps from
the context menu. In the profiler, notice that the graph now includes
rectangles labeled Auto Schedule ("Resource name"), which correspond
to Use Auto Scheduled Resource steps that define resource usage
sections in the sequence. The graph shows that the Use Auto Scheduled
Resource steps block the execution of their threads until the steps can
lock the resources that their section of the sequence requires. You can
hide the operations of the Auto Schedule and Use Auto Scheduled
Resource steps by unchecking View»Show Auto Scheduling. Notice
that for some threads, the Auto Schedule example reorders the use of
the DMM and scope resources to reduce the batch time to
approximately 18 seconds, because each DMM test takes a minimum of
4.5 seconds. In this example, the test time is now resource limited, and
any further improvements will require additional resources.
g. Click the Items tab to display the Items table.
h. Uncheck View»Show UUTs, Batches, and Lots.
i. Click the % Actual Time in Use column heading twice to sort the
percent values in descending order, as indicated by an inverted triangle
icon. The Auto Scheduled item has the highest % Actual Time in Use
value. However, this is only the name of the lock the example holds to
force the profiler to display the name of the strategy being used.
Ignoring that item, the DMM item now has the highest Percent Time in
Use value, which indicates that system performance might improve if
you add additional DMM resources.
j. Click the Clear button to remove the graph information and uncheck
View»Display Blocked Threads. Checkmark View»Show UUTs,
Batches, and Lots.
k. In the sequence editor, right-click the Parallel with Additional DMM step
in the Main step group of the MainSequence and select Run Selected

242 ni.com
TestStand User Manual

Steps from the context menu. In the profiler, notice that the additional
DMM reduces the value of the batch time to approximately 17 seconds.
Because the DMM test always precedes the scope test, the scope test
cannot execute in parallel until a thread completes its DMM test.
l. Click the Clear button to remove the graph information.
m. In the sequence editor, right-click the Auto Scheduled with Additional
DMM step in the Main step group of the MainSequence and select Run
Select Steps from the context menu. In the profiler, notice that the
batch time reduces to approximately 12 seconds, which is a substantial
improvement over the initial value of 30 seconds for the Sequential
strategy example, in which no parallel resource usage existed.
n. In the sequence editor, open and examine the Sequential, Parallel, Auto
Scheduled, Parallel with Additional DMM, and Auto Scheduled with
Additional DMM sequences to view how each sequence synchronizes
access to the DMM and scope resources. Notice that the DMM and scope
are represented by Wait steps. The example models tests that are
resource-bound instead of CPU-bound, and is an accurate model for
tests that must wait on instrument and I/O operations and for multi-
core systems in which the number of cores equals or exceeds the
number of UUTs. You can change the values of the
DMMSimulatedTestDuration and ScopeSimulatedTestDuration file
global variables to determine the effect of different resource speeds on
total throughput. The example contains a ModelOptions callback
sequence that sets the number of UUTs to four. You can edit the callback
sequence, or you can delete the sequence and select
Configure»Model Options to launch the Model Options dialog box
and modify the value of the Number of Test Sockets option to
experiment with the effect of changing the number of UUTs.
Related concepts:
■ TestStand Directory Structure

Executing Code Modules in Parallel

TestStand User Manual

Purpose
This example demonstrates how to run code modules in parallel. This sequence
uses two Sequence Call steps that each call a subsequence in a new execution. Each
subsequence calls a LabWindows/CVI code module to display a panel, which is
updated by a loop in the MainSequence asynchronous from the original execution.

Example File Location

<TestStand Public>\Examples\Parallel Testing\Executing Code Modules In
Parallel\Executing Code Modules In Parallel.seq

Highlighted Features
■ Sequence Call steps
■ Wait steps

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to use this example.
1. On the Steps pane, select the Launch Display Panel 1 step, which is a
Sequence Call step.
2. On the Step Settings pane, click the Sequence Call Module tab. The Execution
Options ring control specifies the Use New Execution option.
3. Click the Sequence Call Advanced Settings button, located to the right of
the Execution Options ring control, to launch the Sequence Call Advanced
Settings window, in which the options change depending on the execution
option you select. The Wait for Execution to Complete ring control specifies

244 ni.com
TestStand User Manual

the Do not wait option. This sequence uses the Do not wait option and a
set of Wait steps at the end of the MainSequence to collect results from each
subsequence.
4. On the Steps pane, select the Wait on Panel 1 for Results step, which is a
Wait step.
5. On the Step Settings pane, click the Wait Settings edit tab. The Specify by
Sequence Call option specifies that the step waits for the Launch Display
Panel 1 sequence call to finish executing. Similarly, the Wait on Panel 2 for
Results step waits for the Launch Display Panel 2 sequence call to finish
executing.
6. On the Sequences pane, select the Display 1 sequence.
7. On the Steps pane, select the Display Panel 1 step, which is an Action step
that uses the LabWindows/CVI Adapter.
8. On the Step Settings pane, click the LabWindows/CVI Module tab. This step
calls a DLL that polls the Counter1 file global variable and displays the
content. Similarly, the Display Panel 2 step in the Display 2 sequence polls the
Counter2 file global variable and displays the content.
9. On the Sequences pane, select the MainSequence and select Execute»Single
Pass to run the sequence. TestStand begins three executions: one execution
updates the Counter1 and Counter2 variables, and the other executions polls
the values of the variables.
10. Click Stop for both Display Panel 1 and Display Panel 2. Scroll to the bottom
of the report, which displays results for the Display Panel 1 and Display Panel
2 steps under the Wait steps for each new execution. If the sequence did not
use Wait steps, TestStand would not log results for the steps run in new
executions.
Related concepts:
■ TestStand Directory Structure
■ Programming with the TestStand API in LabWindows/CVI

Executing Sequences in Parallel

TestStand User Manual

Purpose
This example demonstrates how to launch a parallel, independent sequence
execution with a Sequence Call step in conjunction with a Wait step so that the
execution results of the primary sequence are combined with the execution results
of the subsequence.
Alternatively, you can run the subsequence in the same execution as the primary
sequence. Review the report TestStand generates after either scenario to see the
difference in where the results are collected for the Sequence Call steps.

Example File Location

<TestStand Public>\Examples\Parallel Testing\Executing Sequences In
Parallel\Executing Sequences In Parallel.seq

Highlighted Features
■ Sequence Call steps
■ Wait steps

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to use this example.
1. On the Steps pane, select the Parallel Call step, which is a Sequence Call
step.
2. On the Step Settings pane, click the Sequence Call Module tab. The Execution
Options ring control specifies the Use New Execution option.

246 ni.com
TestStand User Manual

3. On the Steps pane, select the Sequential Call step, which is a Sequence Call
step.
4. On the Step Settings pane, click the Sequence Call Module tab. The
Execution Options ring control specifies the None option.
5. On the Steps pane, select the Wait step.
6. On the Step Settings pane, click the Wait Settings edit tab. The Specify by
Sequence Call option specifies that the step waits for the Parallel Call
sequence call to finish executing.
7. Select Execute»Single Pass to run the sequence.
8. Review the information in the dialog box that launches, and click the Run
DemoSequence in New Execution button. A dialog box launches for each
execution simultaneously. You may have to move or click OK in each dialog
box to see the others.
9. Click OK in each dialog box.
10. Review the report. The results for the Message Popup step from the
DemoSequence appears after the Wait step.
11. Select Execute»Restart to restart the MainSequence execution.
12. Review the information in the dialog box that launches, and click the Run
DemoSequence Sequentially button. Now, only one dialog box launches
at a time.
13. Click OK in each dialog box, and review the report. The Message Popup step
from the DemoSequence now appears after the Message Popup 2 step.
Related concepts:
■ TestStand Directory Structure

Testing UUTs in Parallel - Batch Model

Purpose
This example demonstrates how to use the Batch process model to test multiple
UUTs simultaneously by running a sequence once for each test socket in the system.

TestStand User Manual

The Batch process model generates a batch report that summarizes the results for
the UUTs in the batch.

Example File Location

<TestStand Public>\Examples\Parallel Testing\Testing UUTs in Parallel - Batch
Model\Testing UUTs in Parallel - Batch Model.seq

Highlighted Features
■ Batch process model
■ Batch Synchronization step
■ Flow Control steps
■ Synchronization panel

Major API
None

Prerequisites
None

How to Use This Example

The Set Chamber Temperature step in the MainSequence applies an action to the
entire UUT batch. The Synchronization panel of the Properties tab of the Step
Settings pane for the step sets the Batch Synchronization option to One thread
only because the sequence needs to execute this action only once for the entire
batch.
The Pulse Test step calls the Pulse Test subsequence, which you can select on the
Sequences pane. This sequence contains Batch Synchronization steps that create a
serial synchronized section around the other steps in the sequence to force all the
UUTs in the batch to execute the steps on one UUT before the next UUT can begin. In
a real-world application, controlling UUT execution in a batch can be useful in cases

248 ni.com
TestStand User Manual

in which you have only one set of testing equipment available for certain
procedures.
The Frequency Sweep step in the MainSequence does not specify any
synchronization options, and so all UUTs run this step in parallel.
Select Execute»Single Pass to run the sequence and review the behavior of the
batch execution. When the test completes, the sequence launches a dialog box that
displays the time required to perform the frequency test on all UUTs. The dialog box
divides the total time by the number of UUTs and displays the test time per UUT to
illustrate how you can increase throughput by testing UUTs in parallel.

Note
■ By default, a sequence file uses the Sequential process model, but you
can use the Station Model control on the Model tab of the Station
Options dialog box to specify that the Batch process model is the default
model for all sequence files.
■ You can use the Model Options dialog box to configure the number of
test sockets you want to use for the batch.

Related concepts:
■
Batch Process Model
■ TestStand Directory Structure
■
Sequential Process Model

Testing UUTs in Parallel - Parallel Model

Purpose
This example demonstrates use of the Parallel process model to test multiple UUTs
in parallel. With the Parallel process model, each UUT executes independently, and
you can start and stop testing on any test socket at any time.

TestStand User Manual

Example File Location

<TestStand Public>\Examples\Parallel Testing\Testing UUTs in Parallel - Parallel
Model\Testing UUTs in Parallel - Parallel Model.seq

Highlighted Features
Parallel process model

Major API
None

Prerequisites
None

How to Use This Example

Complete the following steps to review the sequences and steps in the example.
1. Open Testing UUTs in Parallel - Parallel Model.seq, select Edit»Sequence
File Properties and click the Advanced tab. The settings on this tab specify
that the Parallel process model executes this sequence file. You can configure
any sequence file to use the Parallel process model by opening the file,
navigating to the Advanced tab of the Sequence File Properties dialog box,
selecting Require Specific Model for the Model Option setting, and then
selecting ParallelModel.seq from the Model File control.
2. On the Sequences pane, select the MainSequence. This sequence contains
one Sequence Call step and one Numeric Limit Test with an associated
LabWindows\CVI code module.
3. On the Sequences pane, select the PreUUTLoop sequence. This sequence is
a callback from the Parallel process model. Steps in this sequence execute this
code only once before any UUTs are tested. The Set Chamber Temperature
step simulates a setup operation that must be performed to prepare the test

250 ni.com
TestStand User Manual

station for UUT testing, but it needs to be performed only once before any
tests begin.
4. On the Sequences pane, select the Pulse Test sequence. This sequence
simulates a test that can execute on only one test socket at a time. In many
cases, a test station testing multiple UUTs in parallel must share resources
(such as hardware) between test sockets to ensure multiple sockets do not
attempt to access the resource at the same time.
5. Observe the Enter Locked Section step at the beginning of the sequence and
the Exit Locked Section step at the end of the sequence. These steps use the
Lock synchronization object in TestStand to ensure only one test socket
executes this sequence at a time.
Complete the following steps to run the example.
1. Select Execute»Test UUTs to run the sequence.
2. The Set Chamber Temperature dialog box indicates the simulated chamber
heating process. This code executes before any UUTs are tested.
3. The UUT Information dialog box displays once the chamber heating process is
complete. Use this dialog box to enter a serial number for the UUT and start or
stop the execution for each test socket.
4. Once testing has started on a test socket, dialog boxes indicate the status of
the tests. Observe that the Parallel model allows each UUT to start and stop
testing independently. However, the Lock steps in the Pulse Test sequence
cause that sequence to execute on only one test socket at a time. This
behavior demonstrates the ability to synchronize among test sockets when
using the Parallel model.
Related concepts:
■ Parallel Process Model
■ TestStand Directory Structure

Examples for the TestStand API

The TestStand API examples demonstrate how to implement common applications
of the TestStand API in the TestStand expression language and other programming
languages. This directory includes the following example programs.

TestStand User Manual

Accessing Arrays Using API

The <TestStand Public>\Examples\TestStand API\Accessing Arrays Using API
directory contains the following examples.
Related concepts:
■
TestStand Directory Structure
Accessing Arrays Using API - HTBasic

Purpose
This example demonstrates how to use the TestStand API from an HTBasic code
module to access a one-dimensional array, two-dimensional array, and an array of
strings in TestStand.

Example File Location

<TestStand Public>\Examples\TestStand API\Accessing Arrays Using
API\HTBasic\Accessing Arrays Using API.seq

Highlighted Features
■ HTBasic Adapter
■ TestStand API

Major API
■ PropertyObject.GetValNumberByOffset
■ PropertyObject.SetValNumberByOffset
■ PropertyObject.GetValStringByOffset
■ PropertyObject.SetValStringByOffset

Prerequisites
When you use the demo version of HTBasic, you must configure the HTBasic
Adapter to use the HTBasic demo server. Select the Use HTBasic Runtime Server

252 ni.com
TestStand User Manual

option in the HTBasic Adapter Configuration dialog box and specify the path and
filename for HTBwin.exe.

Note (64-bit TestStand) 64-bit TestStand does not support the HTBasic
Adapter.

How to Use This Example

Open the following ArraySubs.prg file, located in the <TestStand
Public>\Examples\TestStand API\Accessing Arrays Using API\HTBasic directory, and
review the following defined subroutines and the TestStand API calls used to get
and set the TestStand local variables:
■ Filllocalarray—Demonstrates how to use the TestStand API from HTBasic to
populate an array stored in a TestStand local variable.
■ Accessarray—Demonstrates how to use the TestStand API from HTBasic to
read an array stored in a TestStand local variable and display a graph of the
data.
■ Fill2darray—Demonstrates how to use the TestStand API from HTBasic to
populate a two-dimensional array stored in a TestStand local variable.
■ Access2darray—Demonstrates how to use the TestStand API from HTBasic
to read a two-dimensional array stored in a TestStand local variable.
■ Fillstrarray—Demonstrates how to use the TestStand API from HTBasic to
populate a string array stored in a TestStand local variable.
■ Accessstrarray—Demonstrates how to use the TestStand API from HTBasic
to read a string array stored in a TestStand local variable.
Complete the following steps to review how TestStand calls the subroutines in the
HTBasic PRG file and review the created local variables.
1. Open the AccessingArrays.seq example sequence file. On the Variables pane,
the NumericArray, TwoDimArray, and StrArray local variables have been
created, but do not contain any data.
2. On the Steps pane, select an Action step.

TestStand User Manual

3. On the Step Settings pane, review the settings for the Action step. The step
does not pass local variables to or return local variables from the subroutine.
4. Select Execute»Single Pass to run the sequence. Use the TestStand
debugging tools such as breakpoints, the Variables pane, and the Watch View
pane to monitor the local variables and verify that the HTBasic subroutines
populate the panes with data.
Related concepts:
■
TestStand Directory Structure
■
Debugging Executions
Accessing Arrays Using API - LabWindows/CVI

Purpose
This example demonstrates how to use the TestStand API from a LabWindows/CVI
DLL code module to access a one-dimensional array, two-dimensional array, and an
array of strings in TestStand.

Example File Location

<TestStand Public>\Examples\TestStand API\Accessing Arrays Using
API\CVI\Accessing Arrays Using API.seq

Highlighted Features
■ LabWindows/CVI Adapter
■ TestStand API

Major API
■ PropertyObject.NewSubProperty
■ PropertyObject.GetValVariant
■ PropertyObject.SetValVariant

254 ni.com
TestStand User Manual

How to Use This Example

Open the AccessArrays.c source file, located in the <TestStand
Public>\Examples\TestStand API\Accessing Arrays Using API\CVI directory, and
review the following defined functions and the TestStand API calls used to get and
set the TestStand local variables:
■ FillLocalArray—Demonstrates how to use the TestStand API from
LabWindows/CVI to populate an array stored in a TestStand local variable.
■ AccessLocalArray—Demonstrates how to use the TestStand API from
LabWindows/CVI to read an array stored in a TestStand local variable and
display a graph of the data.
■ Create2DArray—Demonstrates how to use the TestStand API from
LabWindows/CVI to dynamically create and populate a two-dimensional array
stored in a TestStand local variable

Note Normally, this function would use the InsertIfMissing

property option to create the local variable, but this example does
not use this property option to maintain compatibility with previous
versions of TestStand.

■ Access2DArray—Demonstrates how to use the TestStand API from

LabWindows/CVI to read a two-dimensional array stored in a TestStand local
variable and display a graph of the data.
■ SetStringArray—Demonstrates how to use the TestStand API from
LabWindows/CVI to populate a string array stored in a TestStand local
variable.

TestStand User Manual

■ GetStringArray—Demonstrates how to use the TestStand API from

LabWindows/CVI to read a string array stored in a TestStand local variable and
display the strings in a message popup.
Complete the following steps to review how TestStand calls the functions in the DLL,
review the created local variables, and review the parameters passed to and from
the functions.
1. Open the AccessingArrays.seq example sequence file. On the Variables pane,
the NumericArray and StringArray local variables have been created, but do
not contain any data.
2. On the Steps pane, select an Action step.
3. On the Step Settings pane, review the settings for the Action step. The step
does not pass local variables to or return local variables from the function.
4. Select Execute»Single Pass to run the sequence. The DLL calls populate the
local variables with data, and LabWindows/CVI accesses and displays the
data.
Related concepts:
■ TestStand Directory Structure
■ Programming with the TestStand API in LabWindows/CVI
Accessing Arrays Using API - LabVIEW

Purpose
This example demonstrates how to use the TestStand API from a LabVIEW code
module to access a one-dimensional array, two-dimensional array, and an array of
strings in TestStand.

Example File Location

<TestStand Public>\Examples\TestStand API\Accessing Arrays Using
API\LabVIEW\Accessing Arrays Using API.seq

256 ni.com
TestStand User Manual

Highlighted Features
■ LabVIEW Adapter
■ TestStand API

Major API
■ PropertyObject.NewSubProperty
■ PropertyObject.SetValVariant

Prerequisites
You must have the LabVIEW development system installed and you must configure
the LabVIEW Adapter to use the LabVIEW development system.

How to Use This Example

Open the following example VIs, located in the <TestStand
Public>\Examples\TestStand API\Accessing Arrays Using API\LabVIEW directory, and
review the TestStand API calls used to get and set the TestStand local variables:
■ FillLocalArray.vi—Demonstrates how to use the TestStand API from LabVIEW
to populate an array stored in a TestStand local variable.
■ AccessArray.vi—Demonstrates how to use the TestStand API from LabVIEW
to read an array stored in a TestStand local variable and display a graph of the
data.
■ Create2DArray.vi—Demonstrates how to use the TestStand API from
LabVIEW to dynamically create and populate a two-dimensional array stored
in a TestStand local variable.
■ Access2DArray.vi—Demonstrates how to use the TestStand API from
LabVIEW to read a two-dimensional array stored in a TestStand local variable
and display a graph of the data.
■ SetStringArray.vi—Demonstrates how to use the TestStand API from
LabVIEW to populate a string array stored in a TestStand local variable.

TestStand User Manual

■ GetStringArray.vi—Demonstrates how to use the TestStand API from

LabVIEW to read a string array stored in a TestStand local variable and display
the strings in the VI.
Complete the following steps to review how TestStand calls the VIs, review the
created local variables, and review the parameters passed to and from the VIs.
1. Open the AccessingArrays.seq example sequence file. On the Variables pane,
the NumericArray and StringArray local variables have been created, but do
not contain any data.
2. On the Steps pane, select an Action step.
3. On the Step Settings pane, review the settings for the Action step. The step
does not pass local variables to or return local variables from the VI.
4. Select Execute»Single Pass to run the sequence. The VIs populate the local
variables with data, and LabVIEW accesses and displays the data.
Related concepts:
■ TestStand Directory Structure
■ Programming with the TestStand API in LabVIEW
Accessing Arrays Using API - LabVIEW NXG

Purpose
This example demonstrates how to use the TestStand API from a LabVIEW NXG code
module to access a one-dimensional array, two-dimensional array, and an array of
strings in TestStand.

Example File Location

<TestStand Public>\Examples\TestStand API\Accessing Arrays Using API\LabVIEW
NXG\Accessing Arrays Using API.seq

Highlighted Features
■ LabVIEW NXG Adapter
■ TestStand API

258 ni.com
TestStand User Manual

Major API
■ PropertyObject.NewSubProperty
■ PropertyObject.SetValVariant

Prerequisites
You must have the LabVIEW NXG development system installed and you must
configure the LabVIEW NXG Adapter to use the LabVIEW NXG development system.

How to Use This Example

Open the following example VIs, located in the <TestStand
Public>\Examples\TestStand API\Accessing Arrays Using API\LabVIEW NXG directory,
and review the TestStand API calls used to get and set the TestStand local variables:
■ FillLocalArray.gvi—Demonstrates how to use the TestStand API from
LabVIEW NXG to populate an array stored in a TestStand local variable.
■ AccessArray.gvi—Demonstrates how to use the TestStand API from LabVIEW
NXG to read an array stored in a TestStand local variable and display a graph
of the data.
■ Create2DArray.gvi—Demonstrates how to use the TestStand API from
LabVIEW NXG to dynamically create and populate a two-dimensional array
stored in a TestStand local variable.
■ Access2DArray.gvi—Demonstrates how to use the TestStand API from
LabVIEW NXG to read a two-dimensional array stored in a TestStand local
variable and display a graph of the data.
■ SetStringArray.gvi—Demonstrates how to use the TestStand API from
LabVIEW NXG to populate a string array stored in a TestStand local variable.
■ GetStringArray.gvi—Demonstrates how to use the TestStand API from
LabVIEW NXG to read a string array stored in a TestStand local variable and
display the strings in the VI.
Complete the following steps to review how TestStand calls the VIs, review the
created local variables, and review the parameters passed to and from the VIs.

TestStand User Manual

1. Open the AccessingArrays.seq example sequence file. On the Variables pane,

the NumericArray and StringArray local variables have been created, but do
not contain any data.
2. On the Steps pane, select an Action step.
3. On the Step Settings pane, review the settings for the Action step. The step
does not pass local variables to or return local variables from the VI.
4. Select Execute»Single Pass to run the sequence. The VIs populate the local
variables with data, and LabVIEW NXG accesses and displays the data.
Related concepts:
■ TestStand Directory Structure
■ Programming with the TestStand API in LabVIEW
Accessing Arrays Using API - MFC

Purpose
This example demonstrates how to use the TestStand API from a Microsoft
Foundation Class (MFC) Library code module to access a one-dimensional array,
two-dimensional array, and an array of strings in TestStand.

Example File Location

<TestStand Public>\Examples\TestStand API\Accessing Arrays Using
API\MFC\Accessing Arrays Using API.seq

Highlighted Features
■ C/C++ DLL Adapter
■ TestStand API

Major API
■ PropertyObject.NewSubProperty
■ PropertyObject.GetValVariant

260 ni.com
TestStand User Manual

■ PropertyObject.SetValVariant

Prerequisites
None

How to Use This Example

AppWizard creates AccessingArrays.dll, which demonstrates the basics of using the
Microsoft Foundation Class (MFC) Library and serves as a starting point for writing a
custom DLL.
The following files, located in the <TestStand Public>\Examples\TestStand
API\Accessing Arrays Using API\MFC directory, make up AccessingArrays.dll:
■ AccessingArrays.h—The main header file that declares the
CAccessingArraysApp class for the DLL.
■ AccessingArrays.cpp—The main DLL source file that contains the
CAccessingArraysApp class.
■ AccessingArrays.rc—A list of all the Microsoft Windows resources the
program uses, including icons, bitmaps, and cursors stored in the res
subdirectory. You can directly edit this file in Microsoft Developer Studio.
■ res\AccessingArrays.rc2—Contains resources Developer Studio does not
edit. Place all resources the resource editor cannot edit in this file.
■ AccessingArrays.def—Contains DLL information that must be provided to
run with Windows. This file defines parameters such as the name and
description of the DLL and exports functions from the DLL.
■ AccessingArrays.clw—Contains information ClassWizard uses to edit
existing classes, add new classes, and store information required to create
and edit message maps and dialog data maps and to create prototype
member functions.
Other standard files located in the <TestStand
Public>\Examples\AccessingArraysUsingAPI\UsingMFC directory include the
following:

TestStand User Manual

■ StdAfx.h and StdAfx.cpp—Used to build a precompiled header (PCH) file

named AccessingArrays.pch and a precompiled types file named StdAfx.obj.
■ Resource.h—The standard header file that defines new resource IDs.
Developer Studio reads and updates this file.

Note AppWizard uses TODO: to indicate parts of the source code to which
you must add or that you must customize.

Related concepts:
■ TestStand Directory Structure
■
Organizing Test Program Files with LabVIEW-Built Shared Libraries
Accessing Arrays Using API - .NET

Purpose
This example demonstrates how to use the TestStand API from a .NET assembly
code module to access a one-dimensional array, two-dimensional array, and an
array of strings in TestStand.

Example File Location

<TestStand Public>\Examples\TestStand API\Accessing Arrays Using
API\DotNet\Accessing Arrays Using API.seq

Highlighted Features
■ .NET Adapter
■ TestStand API

Major API
■ PropertyObject.NewSubProperty
■ PropertyObject.GetValVariant
■ PropertyObject.SetValVariant

262 ni.com
TestStand User Manual

Prerequisites
None

How to Use This Example

Complete the following steps to review how TestStand calls the functions in the DLL,
review the created local variables, and review the parameters passed to and from
the functions.
1. Open the AccessingArraysDotNet.seq example sequence file. On the Variables
pane, the NumericArray and StringArray local variables have been created, but
do not contain any data.
2. On the Steps pane, select an Action step.
3. On the Step Settings pane, review the settings for the Action step. The step
does not pass local variables to or return local variables from the function.
4. Select Execute»Single Pass to run the sequence. The DLL calls populate the
local variables with data, and the .NET assemblies access and display the
data.
Related concepts:
■ TestStand Directory Structure

Accessing Properties Using API

The <TestStand Public>\Examples\TestStand API\Accessing Properties Using API
directory contains the following examples.
Related concepts:
■ TestStand Directory Structure
Accessing Properties Using API - LabWindows/CVI

Purpose
This example shows how to access built-in and dynamic TestStand properties. Built-
in TestStand properties are defined by the TestStand API, and are available for any

TestStand User Manual

object of a given class. Dynamic properties, also known as SubProperties, can vary
between objects of the same class.

Example File Location

<TestStand Public>\Examples\TestStand API\Accessing Properties Using
API\CVI\Accessing Properties Using API.seq

Highlighted Features
■ Built-In Properties
■ Dynamic Properties
■ RunState Property
■ TestStand API

Major API
■ PropertyObject.GetValNumber
■ PropertyObject.GetValString
■ PropertyObject.SetValNumber
■ PropertyObject.SetValBoolean
■ PropertyObject.SetValVariant

Prerequisites
None

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Run MainSequence to execute the sequence.
2. As the example executes, read the message popups for information about
built-in and dynamic properties and how they are accessed.
Complete the following steps to review the sequences and steps in this example.

264 ni.com
TestStand User Manual

1. Open the Accessing Built-In Properties sequence from the Sequences

pane. Select the Access Built-in properties step, then click Edit Code in
the Module tab of the Step Settings pane to open the code module. This code
module uses the TestStand API to access built-in properties and methods.
2. Open the Accessing Dynamic Properties sequence from the Sequences
pane. Select the Get Step Results step, then click Edit Code in the Module
tab of the Step Settings pane to open the code module. This code module
uses the TestStand PropertyObject methods to get the values of dynamic step
properties.
3. Select the Set Step Results step, then click Edit Code in the Module tab of
the Step Settings pane to open the code module. This code module uses the
TestStand PropertyObject methods to set the values of dynamic step
properties.
4. Select the Set Variables step, then click Edit Code in the Module tab of the
Step Settings pane to open the code module. This code module uses the
TestStand PropertyObject methods to set the value of a local variable, and
create a new local variable that exists only at run-time.
Related concepts:
■ Accessing Built-in Properties
■
Accessing Dynamic Properties
■ TestStand Directory Structure
■ RunState Subproperties
Accessing Properties Using API - LabVIEW

Purpose
This example shows how to access built-in and dynamic TestStand properties. Built-
in TestStand properties are defined by the TestStand API, and are available for any
object of a given class. Dynamic properties, also known as SubProperties, can vary
between objects of the same class.

TestStand User Manual

Example File Location

<TestStand Public>\Examples\TestStand API\Accessing Properties Using
API\LabVIEW\Accessing Properties Using API.seq

Highlighted Features
■ Built-In Properties
■ Dynamic Properties
■ RunState Property
■ TestStand API

Major API
■ PropertyObject.GetValNumber
■ PropertyObject.GetValString
■ PropertyObject.SetValNumber
■ PropertyObject.SetValBoolean
■ PropertyObject.SetValVariant

Prerequisites
None

How to Use This Example

266 ni.com
TestStand User Manual

1. Open the Accessing Built-In Properties sequence from the Sequences

pane. Select the Access Built-in properties step, then click Edit VI in the
Module tab of the Step Settings pane to open the code module. This code
module uses the TestStand API to access built-in properties and methods.
2. Open the Accessing Dynamic Properties sequence from the Sequences
pane. Select the Get Step Results step, then click Edit VI in the Module tab
of the Step Settings pane to open the code module. This code module uses
the TestStand PropertyObject methods to get the values of dynamic step
properties.
3. Select the Set Step Results step, then click Edit VI in the Module tab of the
Step Settings pane to open the code module. This code module uses the
TestStand PropertyObject methods to set the values of dynamic step
properties.
4. Select the Set Variables step, then click Edit VI in the Module tab of the Step
Settings pane to open the code module. This code module uses the TestStand
PropertyObject methods to set the value of a local variable, and create a new
local variable that exists only at run-time.
Related concepts:
■ Accessing Built-in Properties
■
Accessing Dynamic Properties
■ TestStand Directory Structure
■ RunState Subproperties
Accessing Properties Using API - LabVIEW NXG

TestStand User Manual

Example File Location

<TestStand Public>\Examples\TestStand API\Accessing Properties Using
API\LabVIEW NXG\Accessing Properties Using API.seq

Highlighted Features
■ Built-In Properties
■ Dynamic Properties
■ RunState Property
■ TestStand API

Major API
■ PropertyObject.GetValNumber
■ PropertyObject.GetValString
■ PropertyObject.SetValNumber
■ PropertyObject.SetValBoolean
■ PropertyObject.SetValVariant

Prerequisites
None

How to Use This Example

268 ni.com
TestStand User Manual

1. Open the Accessing Built-In Properties sequence from the Sequences

TestStand User Manual

Example File Location

<TestStand Public>\Examples\TestStand API\Accessing Properties Using
API\MFC\Accessing Properties Using API.seq

Highlighted Features
■ Built-In Properties
■ Dynamic Properties
■ RunState Property
■ TestStand API

Major API
■ PropertyObject.GetValNumber
■ PropertyObject.GetValString
■ PropertyObject.SetValNumber
■ PropertyObject.SetValBoolean
■ PropertyObject.SetValVariant

Prerequisites
None

How to Use This Example

AppWizard creates AccessingPropertiesAndVariables.dll, which demonstrates the
basics of using the Microsoft Foundation Class (MFC) Library and serves as a starting
point for writing a custom DLL.
The following files, located in the <TestStand Public>\Examples\TestStand
API\Accessing Properties Using API\MFC directory, make up
AccessingPropertiesAndVariables.dll:

270 ni.com
TestStand User Manual

■ AccessingPropertiesAndVariables.h—The main header file that declares the

CAccessingPropertiesAndVariablesApp class for the DLL.
■ AccessingPropertiesAndVariables.cpp—The main DLL source file that
contains the CAccessingPropertiesAndVariablesApp class.
■ AccessingPropertiesAndVariables.rc—A list of all the Microsoft Windows
resources the program uses, including icons, bitmaps, and cursors stored in
the res subdirectory. You can directly edit this file in Microsoft Developer
Studio.
■ res\AccessingPropertiesAndVariables.rc2—Contains resources Developer
Studio does not edit. Place all resources the resource editor cannot edit in this
file.
■ AccessingPropertiesAndVariables.def—Contains DLL information that must
be provided to run with Windows. This file defines parameters such as the
name and description of the DLL and exports functions from the DLL.
■ AccessingPropertiesAndVariables.clw—Contains information ClassWizard
uses to edit existing classes, add new classes, and store information required
to create and edit message maps and dialog data maps and to create
prototype member functions.
Other standard files located in the <TestStand Public>\Examples\Accessing
Properties Using API\MFC directory include the following:
■ StdAfx.h and StdAfx.cpp—Used to build a precompiled header (PCH) file
named AccessingPropertiesAndVariables.pch and a precompiled types file
named StdAfx.obj.
■ Resource.h—The standard header file that defines new resource IDs.
Developer Studio reads and updates this file.

Note AppWizard uses TODO: to indicate parts of the source code to which
you must add or that you must customize.

Related concepts:
■
TestStand Directory Structure
Accessing Properties Using API - .NET

TestStand User Manual

Example File Location

<TestStand Public>\Examples\TestStand API\Accessing Properties Using
API\DotNet\Accessing Properties Using API.seq

Highlighted Features
■ Built-In Properties
■ Dynamic Properties
■ RunState Property
■ TestStand API

Major API
■ PropertyObject.GetValNumber
■ PropertyObject.GetValString
■ PropertyObject.SetValNumber
■ PropertyObject.SetValBoolean
■ PropertyObject.SetValVariant

Prerequisites
None

How to Use This Example

Complete the following steps to run the example:

272 ni.com
TestStand User Manual

1. Select Execute»Run MainSequence to execute the sequence.

2. As the example executes, read the message popups for information about
built-in and dynamic properties and how they are accessed.
Complete the following steps to review the sequences and steps in this example.
1. Open the Accessing Built-In Properties sequence from the Sequences pane.
Select the Access Built-in properties step, then click Edit In Visual
Studio in the Module tab of the Step Settings pane to open the code module.
This code module uses the TestStand API to access built-in properties and
methods.
2. Open the Accessing Dynamic Properties sequence from the Sequences pane.
Select the Get Step Results step, then click Edit In Visual Studio in the
Module tab of the Step Settings pane to open the code module. This code
module uses the TestStand PropertyObject methods to get the values of
dynamic step properties.
3. Select the Set Step Results step, then click Edit In Visual Studio in the
Module tab of the Step Settings pane to open the code module. This code
module uses the TestStand PropertyObject methods to set the values of
dynamic step properties.
4. Select the Set Variables step, then click Edit In Visual Studio in the
Module tab of the Step Settings pane to open the code module. This code
module uses the TestStand PropertyObject methods to set the value of a local
variable, and create a new local variable that exists only at run-time.
Related concepts:
■ Accessing Built-in Properties
■ Accessing Dynamic Properties
■ TestStand Directory Structure
■ RunState Subproperties
Accessing Properties Using API - TestStand Expressions

TestStand User Manual

Example File Location

<TestStand Public>\Examples\TestStand API\Accessing Properties Using
API\TestStand Expressions\Accessing Properties Using API.seq

Highlighted Features
■ Built-In Properties
■ Dynamic Properties
■ RunState Property
■ TestStand API

Major API
■ PropertyObject.GetValNumber
■ PropertyObject.GetValString
■ PropertyObject.SetValNumber
■ PropertyObject.SetValBoolean
■ PropertyObject.SetValVariant

Prerequisites
None

How to Use This Example

Complete the following steps to run the example:

274 ni.com
TestStand User Manual

1. Select Execute»Run MainSequence to execute the sequence.

2. As the example executes, read the message popups for information about
built-in and dynamic properties and how they are accessed.
Complete the following steps to review the sequences and steps in this example.
1. Open the Accessing Built-In Properties sequence from the Sequences
pane. Review the statement steps in this sequence. These steps access built-in
properties and methods using the TestStand API.
2. Open the Accessing Dynamic Properties sequence from the Sequences
pane. Review the first set of statement steps under the Get Step Properties
label. These steps use the TestStand PropertyObject methods to get the
values of dynamic step properties.
3. Review the set of statement steps under the Set Step Properties label. These
steps use the TestStand PropertyObject methods to set the values of dynamic
step properties.
4. Review the set of statement steps under the Get Step Properties label. These
steps use the TestStand ProprtyObject methods to set the value of a local
variable, and dynamically create a local variable that exists only at run-time.
Related concepts:
■ Accessing Built-in Properties
■ Accessing Dynamic Properties
■
TestStand Directory Structure
■ RunState Subproperties

Building a Sequence Using API

The <TestStand Public>\Examples\TestStand API\Building a Sequence Using API
directory contains the following examples.
Related concepts:
■ TestStand Directory Structure
Building a Sequence Using API - LabVIEW

TestStand User Manual

Purpose
This example demonstrates how to programmatically create and execute new test
sequences. This example uses an XML file to create new steps and insert them into a
new sequence. The example then saves and executes the new sequence file.

Example File Location

<TestStand Public>\Examples\TestStand API\Building a Sequence Using
API\LabVIEW\Building a Sequence Using API - XML.seq

Highlighted Features
■ TestStand API
■ Flow Control steps

Major API
■ Engine.NewSequenceFile
■ Engine.NewStep
■ Sequence.InsertStep
■ Engine.GetSequenceFileEx
■ Engine.NewExecution
■ Execution.WaitForEndEx
■ Engine.ReleaseSequenceFileEx

Prerequisites
None

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Run MainSequence to start the example.

276 ni.com
TestStand User Manual

2. When prompted, select the example XML file. The data in this file will be used
to create a new sequence file.
3. Notice that a new execution is created. This execution is running the
dynamically created sequence file.
4. Open the sample XML file located in <TestStand Public>\TestStand
API\Building a Sequence Using API\Common in a text editor. You can modify
this file to change the steps in the generated sequence file.
Related concepts:
■ TestStand Directory Structure
Building a Sequence Using API - .NET

Example File Location

<TestStand Public>\Examples\TestStand API\Building a Sequence Using
API\DotNet\Building a Sequence Using API - XML.seq

Highlighted Features
■ TestStand API
■ Flow Control steps

Major API
■ Engine.NewSequenceFile
■ Engine.NewStep
■ Sequence.InsertStep
■ Engine.GetSequenceFileEx
■ Engine.NewExecution

TestStand User Manual

■ Execution.WaitForEndEx
■ Engine.ReleaseSequenceFileEx

Prerequisites
None

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Run MainSequence to start the example.
2. When prompted, select the example XML file. The data in this file will be used
to create a new sequence file.
3. Notice that a new execution is created. This execution is running the
dynamically created sequence file.
4. Open the sample XML file located in <TestStand Public>\TestStand
API\Building a Sequence Using API\Common in a text editor. You can modify
this file to change the steps in the generated sequence file.
Related concepts:
■ TestStand Directory Structure
Building a Sequence Using API - TestStand Expressions (INI)

Purpose
This example demonstrates how to programmatically create and execute new test
sequences. This example uses an INI file to create new steps and insert them into a
new sequence. The example then saves and executes the new sequence file.

Example File Location

<TestStand Public>\Examples\TestStand API\Building a Sequence Using
API\TestStand Expressions\Building a Sequence Using API - INI.seq

278 ni.com
TestStand User Manual

Highlighted Features
■ TestStand API
■ Flow Control steps

Major API
■ Engine.NewSequenceFile
■ Engine.NewStep
■ Sequence.InsertStep
■ Engine.GetSequenceFileEx
■ Engine.NewExecution
■ Execution.WaitForEndEx
■ Engine.ReleaseSequenceFileEx

Prerequisites
None

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Run MainSequence to start the example.
2. When prompted, select the example INI file. The data in this file will be used to
create a new sequence file.
3. Notice that a new execution is created. This execution is running the
dynamically created sequence file.
4. Open the sample INI file located in <TestStand Public>\TestStand API\Building
a Sequence Using API\Common in a text editor. You can modify this file to
change the steps in the generated sequence file.
Related concepts:

TestStand User Manual

■ TestStand Directory Structure

Building a Sequence Using API - TestStand Expressions (XML)

Example File Location

<TestStand Public>\Examples\TestStand API\Building a Sequence Using
API\TestStand Expressions\Building a Sequence Using API - XML.seq

Highlighted Features
■ TestStand API
■ Flow Control steps

Major API
■ Engine.NewSequenceFile
■ Engine.NewStep
■ Sequence.InsertStep
■ Engine.GetSequenceFileEx
■ Engine.NewExecution
■ Execution.WaitForEndEx
■ Engine.ReleaseSequenceFileEx

Prerequisites
None

280 ni.com
TestStand User Manual

How to Use This Example

Creating and Deleting Users Using API

Purpose
This example demonstrates how to programmatically create and delete users.

Example File Location

<TestStand Public>\Examples\TestStand API\Creating & Deleting Users Using
API\Creating & Deleting Users Using API.seq

Highlighted Features
■ User management

Major API
■ Engine.GetUserGroup
■ Engine.NewUser
■ Engine.UserNameExists

TestStand User Manual

■ Engine.UsersFile
■ PropertyObject.SetPropertyObjectByOffset
■ PropertyObject.SetValStringByOffset
■ UsersFile.UserList

Prerequisites
You must be logged into TestStand as a user with administrator privileges.

How to Use This Example

Complete the following steps to review the sequences and steps in this example.
1. On the Steps pane of the MainSequence, select the Create or Delete a User
step.
2. On the Step Settings pane, click the Text and Buttons tab. When you run the
sequence, you select whether you want to create a user or delete a user. The If
and Else steps call the Create User sequence or Delete User sequence,
depending on which option you select.
3. On the Sequences pane, select the Create User sequence, which specifies
the following functionality:
a. The Get New User Name step prompts for a new user name.
b. The If step uses the Engine.UserNameExists method to determine
whether the user name already exists. If the user name does not exist,
the user is created.
c. The Select User Group step in the If structure prompts you to select a
group for the user.
d. A series of Statement steps perform API calls to create the new user and
increment the change count of the user file.
4. On the Steps pane, select each Statement step one at a time and click the
Expression edit tab on the Step Settings pane to review the expression each
step uses. The steps use the Engine.NewUser method to create the new user,
the UsersFile.UserList property and
PropertyObject.SetPropertyObjectByOffset method to insert the new user in

282 ni.com
TestStand User Manual

the user list, and the Engine.GetUserGroup method and

PropertyObject.SetValStringByOffset method to add the user to a group.
5. On the Sequences pane, select the Delete User sequence, which specifies
the following functionality:
a. The Get User Names step, which is a Sequence Call step, calls a
subsequence to generate an array of all user names in the user list.
b. In the If structure, the Delete User sequence verifies that more than one
user exists so that you cannot delete the only user and become locked
out of TestStand.
c. The Delete User sequence stores the user name to delete in a local
variable before the user is actually deleted and removed from any
groups.
d. A Statement step increments the change count of the user file.
6. On the Steps pane of the MainSequence, select the Save Users File step.
7. On the Step Settings pane, click the Text and Buttons tab. When you run the
sequence and have selected whether to create a new user or delete a user, the
precondition evaluates whether the Users file has been modified. If the file
has been modified, the step prompts you to save the changes. If you select
No, TestStand reflects the changes in the User Manager but does not save the
changes.
Complete the following steps to run the example.
1. On the Sequences pane, select the MainSequence.
2. Select Execute»Run MainSequence to run the sequence.
3. In the Create or Delete a User dialog box, click Create User.
4. In the New User Name dialog box, enter a name for the new user and click OK.
5. In the User Group dialog box, select any group for the new user.
6. In the Save the Modified Users File dialog box, select whether you want to
save the changes made to the User file.
7. Select Execute»Restart to run the sequence again.
8. In the Create or Delete a User dialog box, click Delete User.

TestStand User Manual

9. In the Select User dialog box, select the new user you created in step 4.
10. In the Save the Modified Users File dialog box, select whether you want to
save the changes made to the User file.
Related concepts:
■
TestStand Directory Structure
■ Managing Users
■ Privileges

Creating New Properties Using API

The <TestStand Public>\Examples\TestStand API\Creating New Properties Using API
directory contains the following examples.
Related concepts:
■ TestStand Directory Structure
Creating New Properties Using API - LabWindows/CVI

Purpose
This example demonstrates how to use the TestStand API to create and assign
values to PropertyObjects. With the exception of the TestStand Engine, any object in
TestStand can be accessed as a PropertyObject. This arrangement allows the
methods demonstrated in this example to be used with many objects in TestStand,
including step properties and variables.

Example File Location

<TestStand Public>\Examples\TestStand API\Creating New Properties Using
API\CVI\Creating New Properties Using API.seq

Highlighted Features
■ TestStand API

284 ni.com
TestStand User Manual

Major API
■ Engine.NewPropertyObject
■ PropertyObject.NewSubProperty
■ PropertyObject.InsertSubProperty
■ PropertyObject.SetValString
■ PropertyObject.SetValNumber
■ PropertyObject.SetValBoolean
■ PropertyObject.SetValVariant
■ PropertyObject.SetFlags

Prerequisites
Report generation should be enabled in order to see the result of adding a
PropertyObject to the Result container of a step.

How to Use This Example

TestStand User Manual

2. On the Sequences pane, select the Create New PropertyObject sequence.

This sequence uses the Engine.NewPropertyObject and
PropertyObject.InsertSubProperty API calls to create a new PropertyObject
and insert it into the Locals container as a new Local variable. Although this
method of creating PropertyObjects is less common than other approaches, it
is included for completeness.
3. On the Sequences pane, select the SetVal Methods sequence. This sequence
uses the PropertyObject.SetValString, PropertyObject.SetValNumber, and
PropertyObject.SetValBoolean methods to create PropertyObjects and insert
them as Local variables. This approach allows you to create and assign a value
to a PropertyObject with a single API call.
4. On the Sequences pane, select the Create New Container sequence. This
sequence demonstrates a method of creating complex container structures
with the SetVal methods. The PropertyObject.NewSubProperty method is
used to create a container field for error data, which is a defined type in the
TestStand Types pane. Additionally, this sequence uses a
PropertyObject.NewSubProperty method call to create an array and assigns a
value to that array using the PropertyObject.SetValVariant method.
5. On the Sequences pane, select the Insert PropertyObject Into Step
Results sequence. This sequence creates a new PropertyObject and inserts it
into the step’s Result container. The PropertyObject.SetFlags TestStand API
method is used to mark this PropertyObject to be included in the report
generated after execution. This demonstrates a common use case for creating
new PropertyObjects in a test sequence.
Related concepts:
■ TestStand Directory Structure
Creating New Properties Using API - LabVIEW

286 ni.com
TestStand User Manual

methods demonstrated in this example to be used with many objects in TestStand,

including step properties and variables.

Example File Location

<TestStand Public>\Examples\TestStand API\Creating New Properties Using
API\LabVIEW\Creating New Properties Using API.seq

Highlighted Features
■ TestStand API

Prerequisites
Report generation should be enabled in order to see the result of adding a
PropertyObject to the Result container of a step.

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Single Pass to run the sequence.

TestStand User Manual

2. TestStand will display Message Popups to explain each section of the

example. After each section completes, the execution will automatically break
to allow you to observe the results of each approach.
3. When you are ready to continue execution, simply click the green Resume
button on the debug toolbar.
4. After execution completes, examine the report to observe the results of the
final section, where a PropertyObject named SpecialResults was added to a
step’s Result container.
Complete the following steps to review the sequences and steps in this example:
1. On the Sequences pane, select the MainSequence. The MainSequence
contains four Sequence Call steps corresponding to the different approaches
demonstrated in this example.
2. On the Sequences pane, select the Create New PropertyObject sequence.
This sequence uses the Engine.NewPropertyObject and
PropertyObject.InsertSubProperty API calls to create a new PropertyObject
and insert it into the Locals container as a new Local variable. Although this
method of creating PropertyObjects is less common than other approaches, it
is included for completeness.
3. On the Sequences pane, select the SetVal Methods sequence. This sequence
uses the PropertyObject.SetValString, PropertyObject.SetValNumber, and
PropertyObject.SetValBoolean methods to create PropertyObjects and insert
them as Local variables. This approach allows you to create and assign a value
to a PropertyObject with a single API call.
4. On the Sequences pane, select the Create New Container sequence. This
sequence demonstrates a method of creating complex container structures
with the SetVal methods. The PropertyObject.NewSubProperty method is
used to create a container field for error data, which is a defined type in the
TestStand Types pane. Additionally, this sequence uses a
PropertyObject.NewSubProperty method call to create an array and assigns a
value to that array using the PropertyObject.SetValVariant method.
5. On the Sequences pane, select the Insert PropertyObject Into Step
Results sequence. This sequence creates a new PropertyObject and inserts it
into the step’s Result container. The PropertyObject.SetFlags TestStand API

288 ni.com
TestStand User Manual

method is used to mark this PropertyObject to be included in the report

generated after execution. This demonstrates a common use case for creating
new PropertyObjects in a test sequence.
Related concepts:
■
TestStand Directory Structure
Creating New Properties Using API - LabVIEW NXG

Example File Location

<TestStand Public>\Examples\TestStand API\Creating New Properties Using
API\LabVIEW NXG\Creating New Properties Using API.seq

Highlighted Features
■ TestStand API

TestStand User Manual

Prerequisites
Report generation should be enabled in order to see the result of adding a
PropertyObject to the Result container of a step.

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Single Pass to run the sequence.
2. TestStand will display Message Popups to explain each section of the
example. After each section completes, the execution will automatically break
to allow you to observe the results of each approach.
3. When you are ready to continue execution, simply click the green Resume
button on the debug toolbar.
4. After execution completes, examine the report to observe the results of the
final section, where a PropertyObject named SpecialResults was added to a
step’s Result container.
Complete the following steps to review the sequences and steps in this example:
1. On the Sequences pane, select the MainSequence. The MainSequence
contains four Sequence Call steps corresponding to the different approaches
demonstrated in this example.
2. On the Sequences pane, select the Create New PropertyObject sequence.
This sequence uses the Engine.NewPropertyObject and
PropertyObject.InsertSubProperty API calls to create a new PropertyObject
and insert it into the Locals container as a new Local variable. Although this
method of creating PropertyObjects is less common than other approaches, it
is included for completeness.
3. On the Sequences pane, select the SetVal Methods sequence. This sequence
uses the PropertyObject.SetValString, PropertyObject.SetValNumber, and
PropertyObject.SetValBoolean methods to create PropertyObjects and insert
them as Local variables. This approach allows you to create and assign a value
to a PropertyObject with a single API call.

290 ni.com
TestStand User Manual

4. On the Sequences pane, select the Create New Container sequence. This
sequence demonstrates a method of creating complex container structures
with the SetVal methods. The PropertyObject.NewSubProperty method is
used to create a container field for error data, which is a defined type in the
TestStand Types pane. Additionally, this sequence uses a
PropertyObject.NewSubProperty method call to create an array and assigns a
value to that array using the PropertyObject.SetValVariant method.
5. On the Sequences pane, select the Insert PropertyObject Into Step
Results sequence. This sequence creates a new PropertyObject and inserts it
into the step’s Result container. The PropertyObject.SetFlags TestStand API
method is used to mark this PropertyObject to be included in the report
generated after execution. This demonstrates a common use case for creating
new PropertyObjects in a test sequence.
Related concepts:
■
TestStand Directory Structure
Creating New Properties Using API - .NET

Example File Location

<TestStand Public>\Examples\TestStand API\Creating New Properties Using
API\DotNet\Creating New Properties Using API.seq

Highlighted Features
■ TestStand API

TestStand User Manual

Prerequisites
Report generation should be enabled in order to see the result of adding a
PropertyObject to the Result container of a step.

How to Use This Example

292 ni.com
TestStand User Manual

2. On the Sequences pane, select the Create New PropertyObject sequence.

This sequence uses the Engine.NewPropertyObject and
PropertyObject.InsertSubProperty API calls to create a new PropertyObject
and insert it into the Locals container as a new Local variable. Although this
method of creating PropertyObjects is less common than other approaches, it
is included for completeness.
3. On the Sequences pane, select the SetVal Methods sequence. This sequence
uses the PropertyObject.SetValString, PropertyObject.SetValNumber, and
PropertyObject.SetValBoolean methods to create PropertyObjects and insert
them as Local variables. This approach allows you to create and assign a value
to a PropertyObject with a single API call.
4. On the Sequences pane, select the Create New Container sequence. This
sequence demonstrates a method of creating complex container structures
with the SetVal methods. The PropertyObject.NewSubProperty method is
used to create a container field for error data, which is a defined type in the
TestStand Types pane. Additionally, this sequence uses a
PropertyObject.NewSubProperty method call to create an array and assigns a
value to that array using the >PropertyObject.SetValVariant method.
5. On the Sequences pane, select the Insert PropertyObject Into Step
Results sequence. This sequence creates a new PropertyObject and inserts it
into the step’s Result container. The PropertyObject.SetFlags TestStand API
method is used to mark this PropertyObject to be included in the report
generated after execution. This demonstrates a common use case for creating
new PropertyObjects in a test sequence.
Related concepts:
■ TestStand Directory Structure
Creating New Properties Using API - TestStand Expressions

TestStand User Manual

methods demonstrated in this example to be used with many objects in TestStand,

including step properties and variables.

Example File Location

<TestStand Public>\Examples\TestStand API\Creating New Properties Using
API\TestStand Expressions\Creating New Properties Using API.seq

Highlighted Features
■ TestStand API

Prerequisites
Report generation should be enabled in order to see the result of adding a
PropertyObject to the Result container of a step.

How to Use This Example

Complete the following steps to run the example:
1. Select Execute»Single Pass to run the sequence.

294 ni.com
TestStand User Manual

2. TestStand will display Message Popups to explain each section of the

TestStand User Manual

method is used to mark this PropertyObject to be included in the report

generated after execution. This demonstrates a common use case for creating
new PropertyObjects in a test sequence.
Related concepts:
■
TestStand Directory Structure

Executing Sequences Using API

The <TestStand Public>\Examples\TestStand API\Executing Sequences Using API
directory contains the following examples.
Related concepts:
■ TestStand Directory Structure
Executing Sequences Using API - LabWindows/CVI

Purpose
This example demonstrates various methods of calling a sequence using the
TestStand API.

Note If you are developing a TestStand user interface which must handle
TestStand UI messages, do not use the WaitForEndEx() method, since this
method does not process the UI messages while it waits for the execution
to complete. If you need to call this method from a user interface, you
must call this method from a non-UI thread.

Example File Location

<TestStand Public>\Examples\TestStand API\Executing Sequences Using
API\CVI\Executing Sequences Using API.seq

Highlighted Features
■ TestStand API

296 ni.com
TestStand User Manual

Major API
■ Engine.GetSequenceFileEx
■ Engine.NewExecution
■ Engine.ReleaseSequenceFileEx

Prerequisites
None

How to Use This Example

Complete the following steps to review the sequences and steps in the example.
1. Open Executing Sequences Using API.seq.
2. On the Sequences pane, select the MainSequence. The MainSequence
contains four Sequence Call steps that correspond to the different approaches
demonstrated in this example.
3. On the Sequences pane, select the Execute With No Process Model
sequence. This sequence uses the Engine.GetSequenceFileEx and
Engine.NewExecution methods from the TestStand API to open and execute a
sequence file. Because this type of execution does not use a process model, it
is similar to selecting Execute»Run MainSequence in the target sequence
file.
4. After execution completes, the Engine.ReleaseSequenceFileEx method
releases the target sequence file. This is a necessary step for any sequence file
loaded with the Engine.GetSequenceFile method.
5. On the Sequences pane, select the Execute With Process Model sequence.
This sequence loads a process model with the Engine.GetSequenceFileEx
method and uses the Engine.NewExecution method to execute a client
sequence file using one of the entry points from the process model.
6. On the Sequences pane, select the Execute With Sequence Parameters
sequence. This sequence passes parameters to the target sequence by using
the Engine.NewPropertyObject, PropertyObject.SetValNumber, and

TestStand User Manual

PropertyObject.SetValString methods to create a container to store the

parameters. The parameters must be declared in the same order they appear
in the target sequence. Observe that the new PropertyObject container is
passed to the Engine.NewExecution method as one of its parameters.
7. Open Target Sequence File.seq.
8. On the Sequences pane, select the MainSequence. This sequence includes a
Message Popup step to indicate to the user that the sequence has executed.
9. On the Sequences pane, select the Subsequence. Observe that this
sequence includes two parameters, which are displayed in the Message Popup
step.
Complete the following steps to run the example:
1. Select Execute»Single Pass to run the sequence.
2. As each section of code executes, the Message Popup from the target
sequence appears. Click OK on these dialog boxes to continue execution.
3. When the Execute With Sequence Parameters sequence executes, enter a
number and string in the Message Popups that appear. Notice that these
values are displayed in the final Message Popup.
Related concepts:
■ TestStand Directory Structure
Executing Sequences Using API - LabVIEW

Purpose
This example demonstrates various methods of calling a sequence using the
TestStand API.

298 ni.com
TestStand User Manual

Example File Location

<TestStand Public>\Examples\TestStand API\Executing Sequences Using
API\LabVIEW\Executing Sequences Using API.seq

Highlighted Features
■ TestStand API

Major API
■ Engine.GetSequenceFileEx
■ Engine.NewExecution
■ Engine.ReleaseSequenceFileEx

Prerequisites
None

How to Use This Example

TestStand User Manual

4. After execution completes, the Engine.ReleaseSequenceFileEx method

releases the target sequence file. This is a necessary step for any sequence file
loaded with the Engine.GetSequenceFile method.
5. On the Sequences pane, select the Execute With Process Model sequence. This
sequence loads a process model with the Engine.GetSequenceFileEx method
and uses the Engine.NewExecution method to execute a client sequence file
using one of the entry points from the process model.
6. On the Sequences pane, select the Execute With Sequence Parameters
sequence. This sequence passes parameters to the target sequence by using
the Engine.NewPropertyObject, PropertyObject.SetValNumber, and
PropertyObject.SetValString methods to create a container to store the
parameters. The parameters must be declared in the same order they appear
in the target sequence. Observe that the new PropertyObject container is
passed to the Engine.NewExecution method as one of its parameters.
7. Open Target Sequence File.seq.
8. On the Sequences pane, select the MainSequence. This sequence includes a
Message Popup step to indicate to the user that the sequence has executed.
9. On the Sequences pane, select the Subsequence. Observe that this
sequence includes two parameters, which are displayed in the Message Popup
step.
Complete the following steps to run the example:
1. Select Execute»Single Pass to run the sequence.
2. As each section of code executes, the Message Popup from the target
sequence appears. Click OK on these dialog boxes to continue execution.
3. When the Execute With Sequence Parameters sequence executes, enter a
number and string in the Message Popups that appear. Notice that these
values are displayed in the final Message Popup.
Related concepts:
■ TestStand Directory Structure
Executing Sequences Using API - LabVIEW NXG

300 ni.com
TestStand User Manual

Purpose
This example demonstrates various methods of calling a sequence using the
TestStand API.

Example File Location

<TestStand Public>\Examples\TestStand API\Executing Sequences Using
API\LabVIEW NXG\Executing Sequences Using API.seq

Highlighted Features
■ TestStand API

Major API
■ Engine.GetSequenceFileEx
■ Engine.NewExecution
■ Engine.ReleaseSequenceFileEx

Prerequisites
None

How to Use This Example

Complete the following steps to review the sequences and steps in the example.
1. Open Executing Sequences Using API.seq.

TestStand User Manual

2. On the Sequences pane, select the MainSequence. The MainSequence

contains four Sequence Call steps that correspond to the different approaches
demonstrated in this example.
3. On the Sequences pane, select the Execute With No Process Model
sequence. This sequence uses the Engine.GetSequenceFileEx and
Engine.NewExecution methods from the TestStand API to open and execute a
sequence file. Because this type of execution does not use a process model, it
is similar to selecting Execute»Run MainSequence in the target sequence
file.
4. After execution completes, the Engine.ReleaseSequenceFileEx method
releases the target sequence file. This is a necessary step for any sequence file
loaded with the Engine.GetSequenceFile method.
5. On the Sequences pane, select the Execute With Process Model sequence. This
sequence loads a process model with the Engine.GetSequenceFileEx method
and uses the Engine.NewExecution method to execute a client sequence file
using one of the entry points from the process model.
6. On the Sequences pane, select the Execute With Sequence Parameters
sequence. This sequence passes parameters to the target sequence by using
the Engine.NewPropertyObject, PropertyObject.SetValNumber, and
PropertyObject.SetValString methods to create a container to store the
parameters. The parameters must be declared in the same order they appear
in the target sequence. Observe that the new PropertyObject container is
passed to the Engine.NewExecution method as one of its parameters.
7. Open Target Sequence File.seq.
8. On the Sequences pane, select the MainSequence. This sequence includes a
Message Popup step to indicate to the user that the sequence has executed.
9. On the Sequences pane, select the Subsequence. Observe that this
sequence includes two parameters, which are displayed in the Message Popup
step.
Complete the following steps to run the example:
1. Select Execute»Single Pass to run the sequence.

302 ni.com
TestStand User Manual

2. As each section of code executes, the Message Popup from the target
sequence appears. Click OK on these dialog boxes to continue execution.
3. When the Execute With Sequence Parameters sequence executes, enter a
number and string in the Message Popups that appear. Notice that these
values are displayed in the final Message Popup.
Related concepts:
■ TestStand Directory Structure
Executing Sequences Using API - .NET

Purpose
This example demonstrates various methods of calling a sequence using the
TestStand API.

Example File Location

<TestStand Public>\Examples\TestStand API\Executing Sequences Using
API\DotNet\Executing Sequences Using API.seq

Highlighted Features
■ TestStand API

Major API
■ Engine.GetSequenceFileEx
■ Engine.NewExecution
■ Engine.ReleaseSequenceFileEx

TestStand User Manual

Prerequisites
None

How to Use This Example

304 ni.com
TestStand User Manual

8. On the Sequences pane, select the MainSequence. This sequence includes a

Message Popup step to indicate to the user that the sequence has executed.
9. On the Sequences pane, select the Subsequence. Observe that this
sequence includes two parameters, which are displayed in the Message Popup
step.
Complete the following steps to run the example:
1. Select Execute»Single Pass to run the sequence.
2. As each section of code executes, the Message Popup from the target
sequence appears. Click OK on these dialog boxes to continue execution.
3. When the Execute With Sequence Parameters sequence executes, enter a
number and string in the Message Popups that appear. Notice that these
values are displayed in the final Message Popup.
Related concepts:
■ TestStand Directory Structure
Executing Sequences Using API - TestStand Expressions

Purpose
This example demonstrates various methods of calling a sequence using the
TestStand API.

Example File Location

<TestStand Public>\Examples\TestStand API\Executing Sequences Using
API\TestStand Expressions\Executing Sequences Using API.seq

TestStand User Manual

Highlighted Features
■ TestStand API

Major API
■ Engine.GetSequenceFileEx
■ Engine.NewExecution
■ Engine.ReleaseSequenceFileEx

Prerequisites
None

How to Use This Example

306 ni.com
TestStand User Manual

method and uses the Engine.NewExecution method to execute a client

sequence file using one of the entry points from the process model.
6. On the Sequences pane, select the Execute With Sequence Parameters
sequence. This sequence passes parameters to the target sequence by using
the Engine.NewPropertyObject, PropertyObject.SetValNumber, and
PropertyObject.SetValString methods to create a container to store the
parameters. The parameters must be declared in the same order they appear
in the target sequence. Observe that the new PropertyObject container is
passed to the Engine.NewExecution method as one of its parameters.
7. Open Target Sequence File.seq.
8. On the Sequences pane, select the MainSequence. This sequence includes a
Message Popup step to indicate to the user that the sequence has executed.
9. On the Sequences pane, select the Subsequence. Observe that this
sequence includes two parameters, which are displayed in the Message Popup
step.
Complete the following steps to run the example:
1. Select Execute»Single Pass to run the sequence.
2. As each section of code executes, the Message Popup from the target
sequence appears. Click OK on these dialog boxes to continue execution.
3. When the Execute With Sequence Parameters sequence executes, enter a
number and string in the Message Popups that appear. Notice that these
values are displayed in the final Message Popup.
Related concepts:
■ TestStand Directory Structure

Type Casting API Classes

The <TestStand Public>\Examples\TestStand API\Type Casting API Classes directory
contains the following examples.
Related concepts:
■ TestStand Directory Structure

TestStand User Manual

Type Casting API Classes - LabWindows/CVI

Purpose
This example demonstrates how to type cast TestStand objects in order to access
specific API properties and methods.

Example File Location

<TestStand Public>\Examples\TestStand API\Type Casting API Classes\CVI\Type
Casting API Classes.seq

Highlighted Features
■ Built-In Properties
■ Dynamic Properties
■ RunState Property
■ TestStand API

Major API
■ PropertyObject.GetPropertyObject
■ SequenceFile.AsPropertyObjectFile
■ SequenceFile.AsPropertyObject

Prerequisites
None

How to Use This Example

308 ni.com
TestStand User Manual

a sequence file object to the more generic propertyObject and

PropertyObjectFile classes to access their properties and methods.
2. Open the Cast to More Specific Class sequence from the Sequences pane.
Select the Cast to More Specific Class step, then click Edit Code in the
Module tab of the Step Settings pane to open the code module. This step casts
a PropertyObject to more specific classes to access their properties and
methods.
Complete the following steps to run the example:
1. Select Execute»Run MainSequence to execute the sequence.
2. As the sequence executes, read the message popups for information about
the kinds of type casting available in the TestStand API.
Related concepts:
■ TestStand Directory Structure
■
Accessing Built-in Properties
■ Accessing Dynamic Properties
■
RunState Subproperties
Type Casting API Classes - LabVIEW

Purpose
This example demonstrates how to type cast TestStand objects in order to access
specific API properties and methods.

Example File Location

<TestStand Public>\Examples\\TestStand API\Type Casting API
Classes\LabVIEW\Type Casting API Classes.seq

Highlighted Features
■ Built-In Properties
■ Dynamic Properties

TestStand User Manual

■ RunState Property
■ TestStand API

Major API
■ PropertyObject.GetPropertyObject
■ SequenceFile.AsPropertyObjectFile
■ SequenceFile.AsPropertyObject

Prerequisites
None

How to Use This Example

Complete the following steps to review the code in this example:
1. Open the Cast to More Generic Class sequence from the Sequences pane.
Select the Cast to More Generic Class step, then click Edit VI in the Module
tab of the Step Settings pane to open the code module. This step casts a
sequence file object to the more generic propertyObject and
PropertyObjectFile classes to access their properties and methods.
2. Open the Cast to More Specific Class sequence from the Sequences pane.
Select the Cast to More Specific Class step, then click Edit VI in the
Module tab of the Step Settings pane to open the code module. This step casts
a PropertyObject to more specific classes to access their properties and
methods.
Complete the following steps to run the example:
1. Select Execute»Run MainSequence to execute the sequence.
2. As the sequence executes, read the message popups for information about
the kinds of type casting available in the TestStand API.
Related concepts:
■ TestStand Directory Structure

310 ni.com
TestStand User Manual

■ Accessing Built-in Properties

■ Accessing Dynamic Properties
■ RunState Subproperties
Type Casting API Classes - LabVIEW NXG

Purpose
This example demonstrates how to type cast TestStand objects in order to access
specific API properties and methods.

Example File Location

<TestStand Public>\Examples\\TestStand API\Type Casting API Classes\LabVIEW
NXG\Type Casting API Classes.seq

Highlighted Features
■ Built-In Properties
■ Dynamic Properties
■ RunState Property
■ TestStand API

Major API
■ PropertyObject.GetPropertyObject
■ SequenceFile.AsPropertyObjectFile
■ SequenceFile.AsPropertyObject

Prerequisites
None

How to Use This Example

Complete the following steps to review the code in this example:

TestStand User Manual

1. Open the Cast to More Generic Class sequence from the Sequences pane.
Select the Cast to More Generic Class step, then click Edit VI in the Module
tab of the Step Settings pane to open the code module. This step casts a
sequence file object to the more generic propertyObject and
PropertyObjectFile classes to access their properties and methods.
2. Open the Cast to More Specific Class sequence from the Sequences pane.
Select the Cast to More Specific Class step, then click Edit VI in the
Module tab of the Step Settings pane to open the code module. This step casts
a PropertyObject to more specific classes to access their properties and
methods.
Complete the following steps to run the example:
1. Select Execute»Run MainSequence to execute the sequence.
2. As the sequence executes, read the message popups for information about
the kinds of type casting available in the TestStand API.
Related concepts:
■ TestStand Directory Structure
■ Accessing Built-in Properties
■ Accessing Dynamic Properties
■
RunState Subproperties
Type Casting API Classes - .NET

Purpose
This example demonstrates how to type cast TestStand objects in order to access
specific API properties and methods.

Example File Location

<TestStand Public>\Examples\TestStand API\Type Casting API Classes\dotNET\Type
Casting API Classes.seq

312 ni.com
TestStand User Manual

Highlighted Features
■ Built-In Properties
■ Dynamic Properties
■ RunState Property
■ TestStand API

Major API
■ PropertyObject.GetPropertyObject
■ SequenceFile.AsPropertyObjectFile
■ SequenceFile.AsPropertyObject

Prerequisites
None

How to Use This Example

Complete the following steps to review the code in this example:
1. Open the Cast to More Generic Class sequence from the Sequences pane.
Select the Cast to More Generic Class step, then click Edit in Visual
Studio in the Module tab of the Step Settings pane to open the code module.
This step casts a sequence file object to the more generic propertyObject and
PropertyObjectFile classes to access their properties and methods.
2. Open the Cast to More Specific Class sequence from the Sequences pane.
Select the Cast to More Specific Class step, then click Edit in Visual
Studio in the Module tab of the Step Settings pane to open the code module.
This step casts a PropertyObject to more specific classes to access their
properties and methods.
Complete the following steps to run the example:
1. Select Execute»Run MainSequence to execute the sequence.

TestStand User Manual

2. As the sequence executes, read the message popups for information about
the kinds of type casting available in the TestStand API.
Related concepts:
■ TestStand Directory Structure
■
Accessing Built-in Properties
■ Accessing Dynamic Properties
■ RunState Subproperties
Type Casting API Classes - TestStand Expressions

Purpose
This example demonstrates how to type cast TestStand objects in order to access
specific API properties and methods.

Example File Location

<TestStand Public>\Examples\TestStand API\Type Casting API Classes\TestStand
Expressions\Type Casting API Classes.seq

Highlighted Features
■ Built-In Properties
■ Dynamic Properties
■
RunState Property
■ TestStand API

Major API
■ PropertyObject.GetPropertyObject
■ SequenceFile.AsPropertyObjectFile
■ SequenceFile.AsPropertyObject

314 ni.com
TestStand User Manual

Prerequisites
None

How to Use This Example

Complete the following steps to review the code in this example:
1. Open the Cast an Object Reference sequence from the Sequences pane.
Review the statement steps in this sequence. These steps cast a generic object
reference to a specific class to access the properties of the specific class.
2. Open the Cast to More Generic Class sequence from the Sequences pane.
Review the statement steps in this sequence. These steps cast a sequence file
object to the more generic propertyObject and PropertyObjectFile classes to
access their properties and methods.
3. Open the Cast to More Specific Class sequence from the Sequences pane.
Review the statement steps in this sequence. These steps cast a
PropertyObject to more specific classes to access their properties and
methods.
Complete the following steps to run the example:
1. Select Execute»Run MainSequence to execute the sequence.
2. As the sequence executes, read the message popups for information about
the kinds of type casting available in the TestStand API.
Related concepts:
■ TestStand Directory Structure
■ Accessing Built-in Properties
■ Accessing Dynamic Properties
■ RunState Subproperties

Examples for TestStand Debugging Features

TestStand User Manual

The TestStand Debugging Features examples highlight TestStand features for

troubleshooting your test sequences. This directory includes the following example
programs.

Benchmarks
Purpose
This example performs a benchmark on each of the TestStand adapters.

Example File Location

<TestStand Public>\Examples\TestStand Debugging
Features\Benchmarks\Benchmarks.seq

Highlighted Features
■ Module adapters
■ Performance

Major API
None

Prerequisites
You must log into TestStand as a user with administrator privileges. To use the
LabVIEW benchmark portion of the example, you must have the LabVIEW
development system or LabVIEW Run-Time Engine (RTE) installed and you must
configure the LabVIEW Adapter to use the LabVIEW development system or LabVIEW
RTE.

How to Use This Example

This example runs multiple sets of steps. Each set uses a different adapter and
configuration. As the sequence executes, it records the total time required to
execute each set of steps. The sequence generates a custom report to display the
average execution time for a single step in each set of steps.

316 ni.com
TestStand User Manual

You can adjust the following options to improve performance:

■Disable the Enable Tracing option on the Execution tab of the Station
Options dialog box.
■ Enable the Disable Result Recording for All Sequences option on the
Execution tab of the Station Options dialog box.
■To improve the performance of the ActiveX/COM Adapter, disable the Use
Late Binding option in the ActiveX/COM Adapter Configuration dialog box.
■ To improve the performance of the LabVIEW Adapter, enable the Reserve
Loaded VIs for Execution option in the LabVIEW Adapter Configuration
dialog box.
Complete the following steps to use this example.
1. Select Execute»Single Pass to run the sequence.
2. Select Continue. If you do not have the LabVIEW development system or
LabVIEW RTE installed, select the Continue - skip LabVIEW option.
3. When execution completes, review the report on the Report pane.
Related concepts:
■ Module Adapters
■
TestStand Directory Structure
■ Privileges
■
Programming with the TestStand API in LabVIEW

Custom Analyzer Rules

Purpose
This example demonstrates how to implement custom TestStand Sequence
Analyzer rules and analysis modules in LabVIEW, LabWindows/CVI, Microsoft Visual
C#, and Microsoft Visual C++. The example directory contains the following example
custom rules:
■ CheckNumberOfLocals—This rule verifies that the number of locals in
each analyzed sequence does not exceed a maximum number. The maximum

TestStand User Manual

is a configurable rule setting that users edit with a standard built-in dialog
box. This example demonstrates how to use rule settings to configure rules
and how to use analysis transitions to perform bookkeeping tasks.
■ CheckStepNameLength—This rule verifies that the analyzed step names
do not exceed a maximum length. The maximum length is a configurable rule
setting that users edit using a custom dialog box. This example demonstrates
how to use a rule configuration module to configure rules using a custom
dialog box and how to store and retrieve rule configuration data.
Each example rule contains source code for analysis modules and rule configuration
modules written in LabVIEW, LabWindows/CVI, Microsoft Visual C#, and Microsoft
Visual C++.

Example File Location

This example does not use a separate sequence file. Create a new sequence file and
follow the steps in to import the files located in the <TestStand
Public>\Examples\TestStand Debugging Features directory.

Highlighted Features
■ Analysis module
■ Analysis transitions
■ Rule configuration module
■ Rule settings

Major API
■ AnalysisContext
■ RuleConfiguration
■ RuleConfigurationContext

318 ni.com
TestStand User Manual

Prerequisites
You do not need any additional software to run the examples. You must have a
supported version of LabVIEW, LabWindows/CVI, or Microsoft Visual Studio installed
to modify and rebuild the modules.

How to Use This Example

This example implements several rules and analysis modules using LabVIEW,
LabWindows/CVI, Visual C#, and Visual C++. You must import the corresponding
rules files in the Configure Sequence Analyzer Available Rules dialog box to add the
example rules to the sequence analyzer.
After you add the rule to the sequence analyzer, the analyzer adds the rule to all
opened analyzer projects. The sequence analyzer uses the analysis module the next
time you analyze a project.
Related concepts:
■
TestStand Directory Structure

Generating Output Messages

Purpose
This example demonstrates how to generate output messages using the
OutputMessage expression function and the Engine.NewOutputMessage and
OutputMessage.Post methods of the TestStand API. The Output pane of the
TestStand Sequence Editor displays the messages.

Example File Location

<TestStand Public>\Examples\TestStand Debugging Features\Generating Output
Messages\Generating Output Messages.seq

Highlighted Features
■ Action step
■ ActiveX/COM Adapter

TestStand User Manual

■ Sequence Call step

■ Statement step

Major API
■ Engine.NewOutputMessage
■ OutputMessage.Post

Prerequisites
(LabVIEW) You must have the LabVIEW development system installed and you must
configure the LabVIEW Adapter to use the LabVIEW development system.
(LabWindows/CVI)You must have the LabWindows/CVI Run-Time Engine installed
and you must configure the LabWindows/CVI Adapter to execute steps in-process. If
you want to use the Execute Steps in an External Instance of CVI option, you
must have the LabWindows/CVI development environment installed.

How to Use This Example

None

LabVIEW Action Step

Open OutputMessageExample.vi, located in the <TestStand
Public>\Examples\TestStand Debugging Features\Generating Output Messages
directory, and switch to the block diagram, which describes the following
functionality for the VI:
■ The invoke node labeled IEngine invokes the Engine.NewOutputMessage
method.
■ Parameters that enter the VI determine the sequence for which the message
is intended and the content, category, and severity of the message.
■ The subsequent property nodes specify color and icon name.
■ The final invoke node invokes the OutputMessage.Post method to display
the output message on the Output pane in the sequence editor

320 ni.com
TestStand User Manual

LabWindows/CVI Action Step

The LabWindows/CVI Action step calls a LabWindows/CVI DLL named
GenerateOutputMessages.dll, located in the <TestStand
Public>\Examples\TestStand Debugging Features\Generating Output Messages
directory.
Select the Generate Output Messages using a CVI Module step and click the
LabWindows/CVI Module tab on the Step Settings pane, which describes the
following functionality for the LabWindows/CVI step:
■ The Module control specifies GenerateOutputMessages.dll.
■ The Function control specifies the GenerateOutputMessages function.
■ The Parameters table lists the parameters the DLL accepts. The
SeqContextCVI parameter accepts the sequence context, and the other
parameters handle errors or log information for inclusion in the report.

Statement Step
The Statement step is the simplest way to generate output messages. Select the
Generate Output Message using a Statement step step and click the
Expression edit tab on the Step Settings pane, which describes the following
functionality for the Statement step:
■ The expression specifies a simple comparison to determine if the
RunState.LoopIndex value is a multiple of 10. If true, the modulus 10
operation evaluates to 0, and TestStand calls the OutputMessage function.
■ The parameters of the OutputMessage function accept a message and a
severity, and specify the font color and icon to display with the message.

ActiveX/COM Steps
The final step in the MainSequence is a Sequence Call step that calls the Using
ActiveX Adapter steps sequence. Select the Using ActiveX Adapter steps on the
Sequences pane to display the steps in the Using ActiveX Adapter steps sequence,
which describes the following functionality:

TestStand User Manual

■ A For loop contains all the steps in the sequence. The If step specifies that
the steps execute during only every tenth iteration through the loop.
■ The New Output Message step creates the output message by calling the
Engine.NewOutputMessage method. This step also specifies the message text,
category, and severity and obtains a reference to the sequence context.
■ The Set Text Color step uses the Set Property option on the TextColor
property to change the message font color to cyan.
■ The Set Icon Name step specifies the icon to display next to the message.
■ The Post Output Message step invokes the OutputMessage.Post method to
display the output message on the Output pane. Simply creating the message
using the Engine.NewOutputMessage method is insufficient.
Related concepts:
■
TestStand Directory Structure
■ Sequence Context

Developing Embedded Applications Using CompactRIO and LabVIEW FPGA - PG
No ratings yet
Developing Embedded Applications Using CompactRIO and LabVIEW FPGA - PG
284 pages
Industrial Automation Communication Using Crio
No ratings yet
Industrial Automation Communication Using Crio
45 pages
DC-6 Om
100% (4)
DC-6 Om
522 pages
LabView Core 2 Course Manual PDF
No ratings yet
LabView Core 2 Course Manual PDF
130 pages
LabVIEW - Real-Time Application Development Course Manual PDF
100% (4)
LabVIEW - Real-Time Application Development Course Manual PDF
444 pages
LabVIEW FPGA Programming Best Practices
100% (1)
LabVIEW FPGA Programming Best Practices
29 pages
LabVIEW FPGA Course Manual
No ratings yet
LabVIEW FPGA Course Manual
238 pages
Ni Teststand: Getting Started With Teststand
No ratings yet
Ni Teststand: Getting Started With Teststand
89 pages
NI-XNET Hardware and Software Manual
No ratings yet
NI-XNET Hardware and Software Manual
1,247 pages
Crio 9068 User Manaul
No ratings yet
Crio 9068 User Manaul
24 pages
LabVIEW Design Patterns
100% (1)
LabVIEW Design Patterns
59 pages
Ni Teststand Advanced Architecture Series
No ratings yet
Ni Teststand Advanced Architecture Series
204 pages
LabView Exems Answers PDF
No ratings yet
LabView Exems Answers PDF
712 pages
LabVIEW Core1 Course Manual
100% (2)
LabVIEW Core1 Course Manual
216 pages
LabView Tutorial Step-By-Step On How To Use ActiveX in Labview
No ratings yet
LabView Tutorial Step-By-Step On How To Use ActiveX in Labview
17 pages
LabVIEW Intermediate II (Connectivity Course Manual) PDF
100% (1)
LabVIEW Intermediate II (Connectivity Course Manual) PDF
216 pages
CTD Guide For Exam
No ratings yet
CTD Guide For Exam
9 pages
Introduction To Object Oriented Programming and Hardware Abstraction Layers
No ratings yet
Introduction To Object Oriented Programming and Hardware Abstraction Layers
56 pages
Master Thesis Vu Amsterdam
100% (2)
Master Thesis Vu Amsterdam
8 pages
Orientering
No ratings yet
Orientering
15 pages
LabVIEW Core 1 - Participant Guide
No ratings yet
LabVIEW Core 1 - Participant Guide
189 pages
LabVIEW Intermediate I PDF
100% (1)
LabVIEW Intermediate I PDF
452 pages
Plumbing Tools and Their Uses
No ratings yet
Plumbing Tools and Their Uses
6 pages
Labview Core 2 Exercises: Instruments Not For Distribution
No ratings yet
Labview Core 2 Exercises: Instruments Not For Distribution
102 pages
Instant Download Understanding Race and Crime 1st Edition Colin Webster PDF All Chapter
100% (3)
Instant Download Understanding Race and Crime 1st Edition Colin Webster PDF All Chapter
84 pages
Kursus ICT Refresh Course Programme (ICTRCP) Tahun 2024 (Sesi 6)
No ratings yet
Kursus ICT Refresh Course Programme (ICTRCP) Tahun 2024 (Sesi 6)
32 pages
D Professional Development For Office Administration 2 1
No ratings yet
D Professional Development For Office Administration 2 1
55 pages
Daqsc Coursemanual English
No ratings yet
Daqsc Coursemanual English
466 pages
17.tendering Strategies Iconsult
No ratings yet
17.tendering Strategies Iconsult
32 pages
Intro LabVIEW FPGAv4
No ratings yet
Intro LabVIEW FPGAv4
35 pages
LabVIEW Machine Vision - Day 1
No ratings yet
LabVIEW Machine Vision - Day 1
116 pages
(Ebook) Mastering Twitter Ads by Antonio Calero (PDF)
No ratings yet
(Ebook) Mastering Twitter Ads by Antonio Calero (PDF)
106 pages
Test Stand Architecture
No ratings yet
Test Stand Architecture
2 pages
VISA Labview
100% (1)
VISA Labview
22 pages
LabVIEW FPGA
No ratings yet
LabVIEW FPGA
336 pages
Ts2 Exercises Sample 2013 Sample
No ratings yet
Ts2 Exercises Sample 2013 Sample
48 pages
Lvcore1 Participantguide English
No ratings yet
Lvcore1 Participantguide English
314 pages
LabVIEW Core 1 Exercises
0% (1)
LabVIEW Core 1 Exercises
43 pages
Diadem Basics
No ratings yet
Diadem Basics
434 pages
FPGA in Data Acquisition Using cRIO and LabVIEW
0% (1)
FPGA in Data Acquisition Using cRIO and LabVIEW
44 pages
LabVIEW Performance and Memory Management
No ratings yet
LabVIEW Performance and Memory Management
40 pages
Introduction To OOP For LabVIEW Programmers
No ratings yet
Introduction To OOP For LabVIEW Programmers
57 pages
NI LabVIEW For CompactRIO
No ratings yet
NI LabVIEW For CompactRIO
225 pages
Labview Core 2 Course Manual: Instruments Not For Distribution
No ratings yet
Labview Core 2 Course Manual: Instruments Not For Distribution
134 pages
How-To Guide For Most Common Measurements
No ratings yet
How-To Guide For Most Common Measurements
76 pages
Labview Core 2 Instructor Guide: November 2014
No ratings yet
Labview Core 2 Instructor Guide: November 2014
53 pages
Lvcore1 Participantguide English
No ratings yet
Lvcore1 Participantguide English
363 pages
Onion - Wikipedia, The Free Encyclopedia1
No ratings yet
Onion - Wikipedia, The Free Encyclopedia1
7 pages
31st MCMC
No ratings yet
31st MCMC
11 pages
Second Quarter Lesson Plan in English 7
No ratings yet
Second Quarter Lesson Plan in English 7
5 pages
PG AHC Admissions Policy 2020
No ratings yet
PG AHC Admissions Policy 2020
13 pages
Lvcore2 Conceptsmanual English
No ratings yet
Lvcore2 Conceptsmanual English
130 pages
Keralauniversity of Fisheries & Ocean Studies: Panangad P.O., Kochi 682 506, Kerala, India
No ratings yet
Keralauniversity of Fisheries & Ocean Studies: Panangad P.O., Kochi 682 506, Kerala, India
13 pages
Improving The Performance of Your NI LabVIEW Applications
No ratings yet
Improving The Performance of Your NI LabVIEW Applications
45 pages
Manual - LabVIEW 3 Hour Hands-On With MyDAQ
No ratings yet
Manual - LabVIEW 3 Hour Hands-On With MyDAQ
113 pages
Serial Port Communication in LabVIEW
No ratings yet
Serial Port Communication in LabVIEW
5 pages
cDAQ Hands On
No ratings yet
cDAQ Hands On
124 pages
LabVIEW Mostly Missed Question in CLAD
No ratings yet
LabVIEW Mostly Missed Question in CLAD
39 pages
Labview Intermediate I For 8
No ratings yet
Labview Intermediate I For 8
452 pages
Daniel Science
No ratings yet
Daniel Science
10 pages
What Is Athletic Sports and Management?
No ratings yet
What Is Athletic Sports and Management?
3 pages
NI TestStand Verification - Validation
No ratings yet
NI TestStand Verification - Validation
8 pages
t7 2009 Dec Q
No ratings yet
t7 2009 Dec Q
8 pages
5 Muscle
No ratings yet
5 Muscle
3 pages
Project Scope Statement1
No ratings yet
Project Scope Statement1
6 pages
5 People Who Disappeared But Would Reappear Years Later
No ratings yet
5 People Who Disappeared But Would Reappear Years Later
5 pages
MS-Syllabus TCChem
No ratings yet
MS-Syllabus TCChem
17 pages
NI VeriStand Software Only HandsOn
100% (1)
NI VeriStand Software Only HandsOn
27 pages
User Manual 3948368
No ratings yet
User Manual 3948368
4 pages
Lesson 01 - LabVIEW Environment
No ratings yet
Lesson 01 - LabVIEW Environment
34 pages
Amisha Reflective Report
No ratings yet
Amisha Reflective Report
8 pages
BCOC Outstanding 24 Oktober 2023
No ratings yet
BCOC Outstanding 24 Oktober 2023
12 pages
Natgeo-Formation-Of-Earth-2000002398-Article Quiz and Answers
No ratings yet
Natgeo-Formation-Of-Earth-2000002398-Article Quiz and Answers
4 pages
Bapp Telesys Tag 3
No ratings yet
Bapp Telesys Tag 3
4 pages
AC6-How To Setup Client+AP Mode
No ratings yet
AC6-How To Setup Client+AP Mode
10 pages
File Page No 1663658874765
No ratings yet
File Page No 1663658874765
10 pages
Object Oriented Design Patterns Technical Manual and Exercises
No ratings yet
Object Oriented Design Patterns Technical Manual and Exercises
35 pages
NI-VISA and Serial Communication
No ratings yet
NI-VISA and Serial Communication
21 pages
Motion in 1dimension DPP 05 of Lec 06 Prayas JEE 2.0 2025666a9a5e40a9650018c46d03
No ratings yet
Motion in 1dimension DPP 05 of Lec 06 Prayas JEE 2.0 2025666a9a5e40a9650018c46d03
5 pages
ZT105A (MT) 非公路自卸车技术规格书（中英） 20230818
No ratings yet
ZT105A (MT) 非公路自卸车技术规格书（中英） 20230818
15 pages
Labview Improving Performance
No ratings yet
Labview Improving Performance
46 pages
Opc and Real-Time Systems in Labview
No ratings yet
Opc and Real-Time Systems in Labview
81 pages
VLSI Career ICE Breaker
From Everand
VLSI Career ICE Breaker
Yogesh Soni
3/5 (1)
Data Acquisition Using LabVIEW
From Everand
Data Acquisition Using LabVIEW
Behzad Ehsani
No ratings yet
LabVIEW – More LCOD
From Everand
LabVIEW – More LCOD
Rob Maskell
No ratings yet
Bare-Metal Embedded C Programming: Develop high-performance embedded systems with C for Arm microcontrollers
From Everand
Bare-Metal Embedded C Programming: Develop high-performance embedded systems with C for Arm microcontrollers
Israel Gbati
No ratings yet
Safety of Computer Architectures
From Everand
Safety of Computer Architectures
Jean-Louis Boulanger
No ratings yet
Gray Hat Hacking the Ethical Hacker's
From Everand
Gray Hat Hacking the Ethical Hacker's
Çağatay Şanlı
5/5 (1)
ChatGPT for Business: Strategies for Success
From Everand
ChatGPT for Business: Strategies for Success
Matthew C. Smith
No ratings yet
EtherNet IP The Ultimate Step-By-Step Guide
From Everand
EtherNet IP The Ultimate Step-By-Step Guide
Gerardus Blokdyk
No ratings yet