Test Stand PDF

TestStand I Fundamentals
Course Manual
Course Software Version 2.0

February 2001 Edition
Part Number 322317E-01
TestStand I Fundamentals Course Manual
Copyright
Copyright © 2001 National Instruments Corporation. All rights reserved.
Under the copyright laws, this publication may not be reproduced or transmitted in any form, electronic or mechanical, including
photocopying, recording, storing in an information retrieval system, or translating, in whole or in part, without the prior written consent
of National Instruments Corporation.
Trademarks
CVI™, LabVIEW™, and TestStand™ are trademarks of National Instruments Corporation.
Product and company names mentioned herein are trademarks or trade names of their respective companies.
Worldwide Technical Support and Product Information
ni.com
National Instruments Corporate Headquarters

11500 North Mopac Expressway Austin, Texas 78759-3504 USA Tel: 512 794 0100
Worldwide Offices
Australia 03 9879 5166, Austria 0662 45 79 90 0, Belgium 02 757 00 20, Brazil 011 284 5011, Canada (Calgary) 403 274 9391,
Canada (Ottawa) 613 233 5949, Canada (Québec) 514 694 8521, China (Shanghai) 021 6555 7838,
China (ShenZhen) 0755 3904939, Denmark 45 76 26 00, Finland 09 725 725 11, France 01 48 14 24 24, Germany 089 741 31 30,
Greece 30 1 42 96 427, Hong Kong 2645 3186, India 91805275406, Israel 03 6120092, Italy 02 413091, Japan 03 5472 2970,
Korea 02 596 7456, Mexico 5 280 7625, Netherlands 0348 433466, New Zealand 09 914 0488, Norway 32 27 73 00,
Poland 0 22 528 94 06, Portugal 351 1 726 9011, Singapore 2265886, Spain 91 640 0085, Sweden 08 587 895 00,
Switzerland 056 200 51 51, Taiwan 02 2528 7227, United Kingdom 01635 523545
Contents
Introduction
Introduction................................................................................................................. xi
Technical Support Options ......................................................................................... xii
Course Objectives....................................................................................................... xiii
Course Map................................................................................................................. xiv
Items You Need for This Course ................................................................................ xv
Lesson 1
Introduction to TestStand
Introduction to TestStand ........................................................................................... 1-1
The Role of a Test Executive...................................................................................... 1-2
Our Goal for TestStand............................................................................................... 1-3
What is TestStand? ..................................................................................................... 1-4
The TestStand Architecture ........................................................................................ 1-5
The Sequence Editor................................................................................................... 1-6
The Operator Interface................................................................................................ 1-7
TestStand Engine ........................................................................................................ 1-8
Module Adapters ........................................................................................................ 1-9
The TestStand Architecture ........................................................................................ 1-10
Summary..................................................................................................................... 1-13
Exercise 1-1 Running a Sequence File.................................................................. 1-14
Exercise 1-2A Running a Sequence File from the LabVIEW
Operator Interface ............................................................................ 1-19
Exercise 1-2B Running a Sequence File from the
LabWindows/CVI Operator Interface .............................................. 1-24
Lesson 2
The TestStand Environment
Introduction................................................................................................................. 2-1
What is a sequence?.................................................................................................... 2-2
Step Groups ................................................................................................................ 2-3
TestStand Sequence Files ........................................................................................... 2-4
Debugging Tools ........................................................................................................ 2-5
The TestStand Process Models................................................................................... 2-8
Available TestStand Process Models.......................................................................... 2-9
© National Instruments Corporation iii TestStand I Fundamentals Course Manual

Contents
The Default Process Model: Test UUTs Mode ..........................................................2-10

SequentialModel.seq...................................................................................................2-11
The Role of a Process Model in TestStand.................................................................2-12
Workspaces and Source Control.................................................................................2-14
Workspaces and Projects Demo .................................................................................2-15
Summary .....................................................................................................................2-16
Exercise 2-1 Understanding the Sequence File .....................................................2-17
Exercise 2-2 Running a Sequence File with Breakpoints
and Single Stepping..........................................................................2-22
Exercise 2-3 Understanding the Sequential Process Model ..................................2-29
Lesson 3
Creating Sequences
Introduction.................................................................................................................3-1
How to Create Test Sequences ...................................................................................3-2
Step 1 : Specify the Adapter .......................................................................................3-3
Step 2: Select the Step Type .......................................................................................3-4
Step Types...................................................................................................................3-5
Step 3: Specify the Test Module.................................................................................3-6
Specifying the Module................................................................................................3-7
Specifying the Module: Search Directories ................................................................3-8
Step 4: Configure Step Properties...............................................................................3-9
Step Properties: General Tab ......................................................................................3-10
Step Properties: Preconditions ....................................................................................3-11
Step Properties: Run Options Tab ..............................................................................3-12
Step Properties: Run Options Tab (Continued) ..........................................................3-13
Step Properties: Run Options Tab (Continued) ..........................................................3-14
Step Properties: Post Actions Tab ..............................................................................3-15
Step Properties: Loop Options Tab.............................................................................3-16
Step Properties: Loop Options Tab (Continued) ........................................................3-17
Step Properties: Synchronization Tab.........................................................................3-18
Step Properties: Expressions Tab ...............................................................................3-19
Useful Step Type Features ..........................................................................................3-22
Sequence Call Options................................................................................................3-23
IVI Step Type Demo...................................................................................................3-24
Exercise 3-1 Creating Steps in the Sequence Editor .............................................3-28
Exercise 3-2 Configuring Loop Options ...............................................................3-38
Exercise 3-3 Creating a Sequence .........................................................................3-42
Exercise 3-4 Running Sequences in Parallel (Optional) .......................................3-60
TestStand I Fundamentals Course Manual iv ni.com

Contents
Lesson 4
TestStand Parameters, Variables, and Expressions
Introduction.................................................................................................................4-1
TestStand Variables ....................................................................................................4-2
Parameters...................................................................................................................4-3
Parameters: Passing data to subsequences..................................................................4-4
Local Variables ...........................................................................................................4-5
Creating Local Variables ............................................................................................4-6
Sequence File Global Variables..................................................................................4-8
Creating Sequence File Global Variables ...................................................................4-9
Station Globals............................................................................................................4-10
RunState Property Object ...........................................................................................4-11
RunState Subproperties...............................................................................................4-12
RunState Property Example........................................................................................4-13
The Expression Browser .............................................................................................4-14
Using the Expression Browser....................................................................................4-15
Defining Variables and Parameters ............................................................................4-16
Summary .....................................................................................................................4-21
Exercise 4-1 Using Local Variables ......................................................................4-22
Exercise 4-2 Examine the Uses and Differences between Locals,
File Globals, and Station Globals.....................................................4-25
Exercise 4-3 Using Expressions to Change Step Properties..................................4-32
Exercise 4-4 Passing Parameters ...........................................................................4-41
Exercise 4-5 Dynamically Selecting Which Sequence to Run..............................4-53
Lesson 5
Creating Test Modules in External Environments
Introduction.................................................................................................................5-1
Creating Tests in External Environments ...................................................................5-2
Data Transfer in TestStand .........................................................................................5-3
Using Clusters to Pass Data from LabVIEW..............................................................5-4
Using Structures to Pass Data from LabWindows/CVI..............................................5-6
Method 2—Passing Parameters Directly Without Using Structures ..........................5-8
Method 3—Using the ActiveX Automation API to Access Properties
and Methods .............................................................................................................5-12
What is ActiveX Automation?....................................................................................5-13
Summary of ActiveX Automation ..............................................................................5-14
TestStand and ActiveX Automation ...........................................................................5-15
ActiveX Automation in LabVIEW .............................................................................5-16
An Example of ActiveX Automation in LabVIEW....................................................5-17
ActiveX Automation in LabWindows/CVI ................................................................5-18
An Example ActiveX Automation in In LabWindows/CVI.......................................5-19
Using TestStand Code Templates...............................................................................5-24
Code Templates ..........................................................................................................5-25
Summary .....................................................................................................................5-26
© National Instruments Corporation v TestStand I Fundamentals Course Manual

Contents
Exercise 5-1A Creating Pass/Fail Tests in LabVIEW..............................................5-27

Exercise 5-1B Creating Pass/Fail Tests with LabWindows/CVI.............................5-38
Exercise 5-1C Creating Pass/Fail Tests for the DLL Flexible
Prototype Adapter.............................................................................5-47
Exercise 5-2A Creating Numeric Limit Tests with LabVIEW ................................5-55
Exercise 5-2B Creating Numeric Limit Tests with
LabWindows/CVI.............................................................................5-66
Exercise 5-2C Creating Numeric Limit Tests for the DLL
Flexible Prototype Adapter...............................................................5-73
Exercise 5-3A Debugging Tests Using LabVIEW ...................................................5-85
Exercise 5-3B Debugging Tests Using LabWindows/CVI......................................5-90
Exercise 5-3C Debugging Tests that use the DLL Flexible
Prototype Adapter.............................................................................5-94
Exercise 5-4A Using the ActiveX API in Code Modules
with LabVIEW .................................................................................5-97
Exercise 5-4B Using the ActiveX API in Code Modules
with LabWindows/CVI ....................................................................5-105
Exercise 5-4C Using the ActiveX API in Flexible DLL Code
Modules ............................................................................................5-114
Exercise 5-5A Creating a Simple Test Using the LabVIEW
Standard Prototype Adapter .............................................................5-125
Exercise 5-5B Creating A Simple Test Using The C/CVI
Standard Prototype Adapter .............................................................5-127
Exercise 5-6A Passing Parameters from TestStand to LabVIEW
using The TestStand API..................................................................5-128
Exercise 5-6B Passing Parameters from TestStand to
LabWindows/CVI using The TestStand API ...................................5-130
Exercise 5-7 Passing Data Between TestStand and a Test
Module Using the DLL Flexible Prototype Adapter........................5-132
Lesson 6
User Management
Introduction.................................................................................................................6-1
The TestStand User Manager .....................................................................................6-2
Default User Profiles ..................................................................................................6-3
Windows System Users ..............................................................................................6-5
Summary .....................................................................................................................6-6
Exercise 6-1 Setting User Login Access and Privileges........................................6-7
Lesson 7
Result Collection and Report Generation
Introduction.................................................................................................................7-1
When and Where Results are Stored ..........................................................................7-2
What Results are Stored..............................................................................................7-3
View of Actual Results ...............................................................................................7-4
TestStand I Fundamentals Course Manual vi ni.com

Contents
Subsequence Results...................................................................................................7-5
Formatting Results into a Report ................................................................................7-6
Report Configuration Options ....................................................................................7-7
Report Options Dialog Box: Contents Tab.................................................................7-8
Report Options Dialog Box: Report File Pathname Tab ............................................7-9
Inserting Message in Report .......................................................................................7-10
Using an External Report Viewer from TestStand .....................................................7-11
Summary .....................................................................................................................7-13
Exercise 7-1 Customizing Report Generation .......................................................7-14
Lesson 8
Database Interaction
Introduction.................................................................................................................8-1
Database Concepts ......................................................................................................8-2
Structured Query Language (SQL).............................................................................8-3
Database Interface Technologies ................................................................................8-4
Database and Database Drivers ..................................................................................8-5
Configuring Database Options: Logging Options ......................................................8-6
Configuring Database Options: Data Link .................................................................8-7
Configuring Database Options: Schemas ...................................................................8-8
Configuring Database Options: Statements ................................................................8-9
Configuring Database Options: Columns/Parameters ................................................8-10
Logging Property ........................................................................................................8-11
Default Schema: Generic Recordset ...........................................................................8-12
Creating Default Database Tables ..............................................................................8-13
Database Viewer .........................................................................................................8-14
Open Database Step Type...........................................................................................8-18
Open SQL Statement Step Type .................................................................................8-19
Open SQL Statement: Build SQL Select Statement Dialog Box ...............................8-20
Data Operation Step Type...........................................................................................8-21
Data Operation Step Type (Continued) ......................................................................8-22
Close SQL Statement Step Type ................................................................................8-25
Close Database Step Type ..........................................................................................8-26
Summary .....................................................................................................................8-28
Exercise 8-1 Logging UUT Results to Database...................................................8-29
Exercise 8-2 Using Database Step Types ..............................................................8-42
Lesson 9
The Operator Interface
Introduction.................................................................................................................9-1
The Operator Interface................................................................................................9-2
Available Operator Interfaces .....................................................................................9-3
Operator Interface Functionality.................................................................................9-4
© National Instruments Corporation vii TestStand I Fundamentals Course Manual

Contents
Sequence Display........................................................................................................9-5
Execution Display.......................................................................................................9-6
How the Operator Interface Works.............................................................................9-7
What is a UIMessage? ................................................................................................9-8
Summary .....................................................................................................................9-10
Exercise 9-1 Running Tests from the Operator Interface......................................9-11
Lesson 10
Additional Topics
Introduction.................................................................................................................10-1
Import/Export Properties ............................................................................................10-2
Import/Export Properties Dialog Box.........................................................................10-3
The Property Loader Step ...........................................................................................10-4
Importing/Exporting Values Summary.......................................................................10-8
Distributing TestStand ................................................................................................10-9
TestStand Run-Time Engine.......................................................................................10-10
Distribute the Operator Interface ................................................................................10-11
Distribute Sequences and Code Modules ...................................................................10-12
Exercise 10-1 Importing and Exporting Properties .................................................10-13
Exercise 10-2 Using the Property Loader Step Type...............................................10-19
Exercise 10-3 Using the Expressions to Load Properties........................................10-24
Appendix A
Introduction to Interchangeable Virtual Instruments
Introduction to Interchangeable Virtual Instruments (IVI).........................................A-1
What is an Instrument Driver?....................................................................................A-2
What is IVI?................................................................................................................A-3
IVI Instrument Drivers................................................................................................A-4
IVI Instrument Drivers (Continued) ...........................................................................A-5
IVI Driver ...................................................................................................................A-6
IVI Attribute Model ....................................................................................................A-7
State Caching ..............................................................................................................A-8
Range Checking ..........................................................................................................A-9
Simulation ...................................................................................................................A-10
Standardization ...........................................................................................................A-11
Instrument Classes ......................................................................................................A-12
IVI Class Specification ...............................................................................................A-13
IVI Driver Standard ....................................................................................................A-14
Where Does IVI Fit In? ..............................................................................................A-15
Using IVI Instrument Specific Drivers .......................................................................A-16
Using IVI Instrument Specific Drivers (Continued)...................................................A-17
Types of IVI Drivers...................................................................................................A-18
Interchangeable Drivers ..............................................................................................A-19
IVI Architecture ..........................................................................................................A-20
IVI Configuration .......................................................................................................A-21
TestStand I Fundamentals Course Manual viii ni.com

Contents
IVI Configuration .......................................................................................................A-22

Logical Names ............................................................................................................A-23
Virtual Instruments .....................................................................................................A-24
Instrument Driver Configuration ................................................................................A-25
Device Configuration..................................................................................................A-26
Inherent Attributes ......................................................................................................A-27
Virtual Channel Names...............................................................................................A-28
Default Setup ..............................................................................................................A-29
IVI Foundation Update ...............................................................................................A-30
Instrument Driver Network (IDNet) ...........................................................................A-31
© National Instruments Corporation ix TestStand I Fundamentals Course Manual

Introduction
TestStand I: Fundamentals
Course Manual
National Instruments
11500 N. MoPac Expressway
Austin, Texas 78759
(512) 683-0100
Introduction
TestStand is a powerful, flexible, and easy-to-use test executive software program. Built around an
intuitive explorer-style interface and able to execute tests created in a variety of test development
environments, TestStand enables developers to build sophisticated testing programs customized to
their exact needs.
This course introduces the TestStand environment and teaches you how to use TestStand for your
test executive applications. The main emphasis of this course is to cover the fundamental,
off-the-shelf features that TestStand offers. A background knowledge of test executive software and
a familiarity with either LabVIEW or C programming is required for this course.
© National Instruments Corporation xi TestStand I Fundamentals Course Manual

Introduction
Technical Support Options

Internet Support:
NI Web Support ni.com
Email Support ni.com/ask
TestStand Support ni.com/support/teststandsupp.htm
The NI Web and TestStand Support pages offer these resources to

help you find answers to your measurement and automation questions:
• Developer Zone
• TestExec List Server
• Example programs database
• Searchable KnowledgeBase
• Latest product and event information
Telephone Support (USA):

Telephone Support (512) 795-8248
Technical Support Options

National Instruments is dedicated to providing you with the best support options to help you find
solutions to your questions in the shortest possible time. For 24-hour accessibility, we offer
complete and exhaustive technical information through our NI Web Support, which features an
extensive knowledgebase with search capabilities, a variety of support documents (such as user
manuals for our products), application notes, driver software, and much more. Use NI Web Support
as your first stop if you have any questions about National Instruments products. If our web site
does not answer all your questions, we also offer e-mail and phone support.
TestStand I Fundamentals Course Manual xii ni.com

Introduction
Course Objectives
• Introduce the TestStand architecture
• Demonstrate the powerful off-the-shelf capabilities of
TestStand
In this course, you will learn how to:

• Build sequences and tests
• Use the operator interfaces
• Distribute TestStand and test code
Note You can customize many of the topics discussed in this

course to integrate further with your testing requirements.
Course Objectives
This TestStand course teaches you the fundamentals of the TestStand environment. It begins with
a background discussion of the TestStand architecture, including an overview of each constituent
part. The course then discusses the TestStand environment and demonstrates how to use TestStand
to create a test management program. The course concludes by showing you how to distribute
TestStand and your test sequences.
Course Description
The course is divided into lessons that teach a topic or a set of topics. Each lesson consists of:
• An introduction that describes the lesson’s objectives and the topics discussed.
• A discussion of the topics.
• A set of hands-on exercises that reinforce the concepts presented in the discussion. (Some of
the exercises are duplicated for LabVIEW and LabWindows/CVI, so you can work in your
preferred programming environment. For duplicate exercises, select one of the exercises to
complete during the time allotted.)
• A summary that highlights the concepts covered in the lesson.
© National Instruments Corporation xiii TestStand I Fundamentals Course Manual

Introduction
Course Map
Day 1 Day 2
TestStand User Management
Environment
Creating Sequences Operator Interface
Result Collection
Variables, Report Generation
Properties, and
Expressions
Database Features
Creating Test
Modules in External Distributing
Environments TestStand
Course Map
Over the next two days, the course addresses several key concepts of TestStand.
Lessons 1 through 4 introduce the TestStand development environment. These lessons present
basic operations in opening and creating sequence files and using variables, properties, and
expressions.
Lesson 5 explains how TestStand communicates with external programming environments and
how you can create TestStand-compatible test modules in these environments.
Lesson 6 addresses how you can develop multiple user levels.
Lessons 7 through 10 address collecting results and generating reports, logging results to a
database, using the property loader, and distributing TestStand to other test stations.
TestStand I Fundamentals Course Manual xiv ni.com

Introduction
Items You Need for This Course

TestStand
version 2.0
or later
TestStand I:
Fundamentals
Course Manual
TestStand
Computer running Windows 95/NT/98 Development
with an internal PC speaker Course disks
(Recommended: Pentium II 266 MHz
or better and 64MB RAM)
Items You Need for This Course

• Computer running Windows 95/NT/98
• TestStand version 2.0
• TestStand I Fundamentals Course Manual and disks
Install the course software by inserting the course disks and extracting the contents of the
self-extracting archives into your C:\Exercises\TestStand I directory. The solutions to all
exercises should be installed in the C:\Solutions\TestStand I directory.
You also need LabVIEW 6.0 or later, LabWindows/CVI 5.5, and Excel 97 or Excel 97 Viewer for
some of the exercises.
© National Instruments Corporation xv TestStand I Fundamentals Course Manual

Introduction
Hands-On Exercises
• Exercises reinforce the topics presented

• Save exercises in the \Exercises\TestStand I
directory
• Solutions are in the \Solutions\TestStand I
directory
TestStand I Fundamentals Course Manual xvi ni.com

Lesson 1
Lesson 1: Introduction to TestStand

In this lesson, you will learn:
• The role of a test executive
• The basic TestStand concepts
• The TestStand architecture
This lesson introduces the basic TestStand concepts and the development environment architecture.
The first part introduces the role of a test executive in a test environment and the tasks it performs.
The second part addresses the issue of “What is TestStand?”
The third part describes the TestStand architecture and provides detailed information about its
constituent parts. The exercises introduce two of the constituent parts of TestStand, the Sequence
Editor and the Operator Interface.
© National Instruments Corporation 1-1 TestStand I Fundamentals Course Manual

Lesson 1 Introduction to TestStand
The Role of a Test Executive

Components of a Test System:
Operations different for Operations repeated for

each product tested: each product tested:
• Calibration • Operator interfaces
ve
• Configuring instruments • User management
uti
• Data acquisition • Unit Under Test (UUT) tracking
ec
Ex
• Measurements • Test flow control
st
• Analyzing results • Archiving results
Te
• Test strategies • Test reports
The Role of a Test Executive

In every testing environment, a wide variety of operations must be performed. These operations can
be separated into two distinct groups: operations repeated for each product tested and operations
different for each product tested.
Test executive programs execute operations that are repeated for each product. Operations such as
displaying the user interface, providing user management, performing step branching, archiving
results, and creating test reports are similar for each product tested, and are therefore handled by a
test executive.
The other set of operations, such as calibration and configuration routines, data acquisition and
measurement, analysis of results, and developing test strategies, are different for each product.
These operations are written in other environments (for example, LabVIEW and/or
LabWindows/CVI) and implemented as steps in a test executive program.
Thus, a test executive allows test engineers to concentrate on developing tests for their products
while providing the basic operations needed for testing environments. This allows test engineers to
develop test modules efficiently without redundant code development.
TestStand I Fundamentals Course Manual 1-2 ni.com

Our Goal for TestStand
To build an off-the-shelf test executive that:

• Any user can modify easily
• Satisfies a variety of user requirements
• Integrates with existing systems (databases, SPC
tools, UUT tracking, and so on)
Our Goal for TestStand

National Instruments has been designing test executive software for many years and has acquired
in-depth experience about the needs of test developers. Test developers need a solution that is easy
to use and ready to run right out of the box. At the same time, they need to customize the test
management software for their own particular testing environments. Furthermore, they need to
integrate the test management software with existing systems, including not only the test
development environment, but also the additional tools used in the test systems (such as statistical
control and database management).
The goal of TestStand is to provide a product that is versatile and flexible enough that users can
both easily use TestStand for their testing needs and customize TestStand quickly to create their
own custom test executive systems. As you proceed with the course, you will see how TestStand
meets the first goal and in the advanced course you will see how TestStand meets the second goal.

What is TestStand?
Two Products in One

• Ready-to-run test executive
• Development environment for building a powerful
custom test solution
What is TestStand?
You can think of TestStand as two products in one. On the one hand, it is a ready-to-run test
executive. Right out of the box, you can use it to develop sophisticated sequences to track UUTs
and log and display data. Furthermore, because TestStand can call test modules written in a variety
of languages, TestStand sequences can integrate a variety of existing code.
TestStand goes beyond just building sequences. The test developer can customize almost every
aspect of TestStand itself. So, in effect, TestStand is a tool for building your own test executive.

The TestStand Architecture
Main Components of TestStand

• Sequence Editor
• Operator Interfaces
• TestStand Engine
• Module Adapters

To understand TestStand, you must understand its four major components:
• Sequence Editor
• Module Adapters
It is important to understand how each component fits into the test software design stages:
• Sequence Editor—for developing, debugging, and executing sequences
• Operator Interfaces—for executing and debugging sequences on the production floor
• TestStand Engine—an Active X server that performs the test executive operations
• Module Adapters—enable TestStand to interface with external development environments
This lesson continues with a detailed discussion of each component.

TestStand Architecture:
Sequence Editor
The Sequence Editor is:

• A separate application
• A development environment for:
• Building and editing test sequences
• Executing sequences for development and debugging
• Managing your test code development
The Sequence Editor

The Sequence Editor is a Win32-style application for creating, editing, and debugging TestStand
sequences. A sequence is a collection of test modules with a controlled execution order.
The Sequence Editor supports standard Windows editing tools such as cut and paste, drag and drop,
and context-sensitive menus. The Sequence Editor gives you easy access to powerful TestStand
features, such as step types and process models (addressed later in this course). You can use
debugging tools such as breakpoints, single-stepping, stepping into or over function calls, tracing,
variable display, and watch window. From the Sequence Editor, you can execute multiple instances
of the same sequence and execute different sequences at the same time.
The Sequence Editor is the development environment from which you can build and debug your
test sequences. The Sequence Editor also has features like source code control and workspaces that
help you manage your test development.

Operator Interface
The Operator Interface:

• Allows you to start multiple concurrent executions, set
breakpoints, and single-step, but not modify,
sequences
• Can be created in several development environments
• Contains source code for LabVIEW, LabWindows/CVI,
Delphi, and Visual Basic

The Operator Interface is a separate application used for executing TestStand sequences on the
production floor. It serves as an interface for the engine through the TestStand application
programming interface (API). The run-time Operator Interface allows you to start multiple
concurrent executions, set breakpoints, and single-step through a sequence. However, the run-time
Operator Interface does not allow you to modify sequences or display sequence variables, sequence
parameters, or step properties.
TestStand currently includes four operator interfaces in both source code and executable form.
Each run-time operator interface is a separate application program, differing primarily with respect
to the application development environment (ADE) in which each was developed. TestStand ships
with run-time operator interfaces developed in LabVIEW, LabWindows/CVI, Delphi, and Visual
Basic. In addition to the these programming environments, you can write the Operator Interface in
any programming environment that supports ActiveX client functionality.
Although you can use the TestStand Sequence Editor at a production station, the TestStand
run-time operator interfaces are simpler and fully customizable, thus making them more suitable
applications for deployment. This course explains the operator interfaces in more detail in a later
lesson.

TestStand Engine
The TestStand Engine is focused on execution, speed,

flexibility, and long-term support/compatibility.
The TestStand Engine offers:

• Multithreaded sequencing
• Flow control (Preconditions, Branching, Looping)
• Sequence file creation, modification, saving, and loading
• Data collection
• Multilevel user access (login)
TestStand Engine
At the core of the TestStand architecture is the TestStand Engine. The engine is implemented as a
set of 32-bit Dynamic Link Libraries (DLLs) that export an ActiveX API. The TestStand Engine
handles test executive tasks such as sequencing, branching, looping, limit checking, data
allocation, and user management. The engine is optimized for speed and designed for maximum
flexibility and long-term compatibility.
The TestStand Sequence Editor and run-time operator interfaces use the engine API for creating,
editing, executing, and debugging sequences. You can call the engine API from any programming
environment that supports access to ActiveX Automation servers. You can even call the engine API
from test modules, including test modules you create in LabVIEW and LabWindows/CVI.
ActiveX Automation and the TestStand API are discussed more thoroughly later in the course.

Module Adapters
Module Adapters:
• Allow TestStand to integrate with various languages
• Execute test modules at run-time
• Step into test modules
• Generate test module templates
TestStand
LV CVI DLL ActiveX TestStand HT

Servers Sequence Basic
Module Adapters
To communicate with external code modules, TestStand must know the code module type, how
to call it, and how to pass parameters to it. Module adapters integrate TestStand with external
environments. The adapters act as an interface between TestStand and external test development
environments, supplying the necessary information for communication between the two
environments.
Module adapters allow TestStand to execute test modules, pass and receive data, generate test
module templates, and even debug code written in another programming language. TestStand can
call a test written in any language for which it has an adapter. Currently, there are adapters for
LabVIEW, LabWindows/CVI, Dynamic Linked Libraries (DLLs), ActiveX Automation servers,
sequences, and HTBasic. These adapters can call different types of code modules: TestStand
sequences, LabVIEW VIs, HTBasic subroutines, C functions in DLLs, and C functions in source,
object, or library modules that you create in LabWindows/CVI or other compilers.
Module adapters allow you to integrate your existing test software and tools. Adapters help you
benefit from the fully customizable features of TestStand and the investment you have already
made in your existing test software infrastructure.
Note When creating TestStand sequences, you can use different adapters within the
same sequence.

TestStand Architecture
Samples in ActiveX
Source: Custom Clients
Operator Sequence
LV, CVI, VB Interface Editor
Application Programming Interface

Process
TestStand Engine (ActiveX Server) Model
CVI DLL ActiveX TestStand HT

LV Servers Sequence Basic

The TestStand architecture involves using all four main components (Sequence Editor, Operator
Interfaces, Engine, and Module Adapters) in the test execution. This slide demonstrates how each
component interacts with the TestStand Engine. The engine, an ActiveX server, exports an API that
the Sequence Editor and operator interfaces use. The engine performs specific operations (for
example, running a sequence) in response to ActiveX method calls. The TestStand Engine runs the
sequences, which contain steps that can call external code modules. By using module adapters that
have a standard adapter interface, the TestStand Engine can load and execute different types of code
modules and even call other sequences through the same adapter interface. The TestStand Engine
uses a special type of sequence called a process model to direct the flow of its operations. The next
lesson addresses process models in detail.
In Exercise 1-1, you will examine the Sequence Editor and one of the sample operator interfaces.

Exercise 1-1
Objective: To launch TestStand and run a

sequence file from the Sequence Editor
Approximate time to complete: 10 minutes

Exercises 1-2A and 1-2B
Objective: To run a sequence file from the

LabVIEW or LabWindows/CVI Operator
Interface
Note When there is both an exercise A and B, choose

one of the exercises based on your preferred
development environment

Lesson 1 Summary:
• Test executives perform UUT-independent repetitive

operations in testing environments
• TestStand is an off-the-shelf, ready-to-run test
executive that is fully customizable
• TestStand has four main components:
• Sequence Editor
• Module Adapters
Summary
A test executive program performs tasks in the testing environment that are repetitive for different
products tested. This allows you to focus on creating the test modules and prevents redundant
programming.
TestStand is a ready-to run test executive software program that is fully customizable so that you
can modify TestStand to fit your needs.
The TestStand architecture has four main components:

• Sequence Editor—for developing, debugging, and executing sequences.
• Operator Interfaces—for executing and debugging sequences on the production floor.
• TestStand Engine—an ActiveX server that performs the test executive operations.
• Module Adapters—enable TestStand to interface with external development environments.
In the rest of the course, you will learn how to use and develop tests using these key TestStand
components.

Lesson 1 Introduction to TestStand Exercises
Exercise 1-1 Running a Sequence File

Objective: To run test sequences from the Sequence Editor and view reports generated by
TestStand.
The Sequence Editor is the TestStand development environment in which

you can create, edit, and execute sequences. It is important to be familiar
with this environment, because you will develop all sequence files here.
1. Open the Sequence Editor by clicking the Windows Start menu, and
then select Programs»National Instruments TestStand»Sequence
Editor. After the Sequence Editor loads, you are prompted to log in.
The default input for the Login Name is administrator and the
password is left empty. Click OK to complete the login.
2. After logging in, select File»Open and navigate to C:\Exercises\

TestStand I.
This is the location of all TestStand course exercises.
3. Double-click on Ex 1-1 Computer Test.seq to open the
sequence file.
This is a simple sequence that simulates testing parts of a computer
motherboard (for example, the RAM, ROM, and keyboard). This
particular sequence has tests written in LabVIEW; however, you could
write the tests in LabWindows/CVI or a variety of other programming
environments compiled as DLLs, EXEs, or ActiveX Servers.
The TestStand window should appear as shown below.

4. To run the sequence, select either Execute»Test UUTs or

Execute»Single Pass or click the Run button, as shown in the toolbar
below.
Test UUTs is an execution entry point that runs the sequence in a

continuous loop. Execution entry points are used to run the sequence in
predefined ways. By default, TestStand has only two execution entry
points, Test UUT and Single Pass. Lesson 2 describes execution entry
points in more detail, and Lesson 7 explores how to create an execution
entry point.
Before executing the sequence, a UUT Information dialog box prompts
you for a serial number. Enter any number for the serial number. After
executing the sequence, a Pass/Fail banner indicates the sequence status.
To stop the loop and generate a sequence report, click on the Stop button
in the UUT Information dialog box.
Test UUTs is the execution entry point for running most test systems in
TestStand.
Single Pass is an execution entry point that executes the sequence once
and generates a report. Single Pass is useful for debugging your tests and
determining that your sequence execution proceeds as you intended.

Run Main Sequence allows you to execute the sequence without using
the process model. (The process model is discussed in future lessons.)
This mode can test only how your main sequence proceeds, because no
other parts of the process model are executed in this type of execution.
For now, the only noticeable difference is that no report is generated, as
compared to the Test UUTs or Single Pass entry points. The process
model as used by the Test UUTs and Single Pass entry points is
explained later in this course.
5. Use the Motherboard Test Simulator dialog box to select the tests you
want to fail. To do this, click on the check boxes beside the name of the
part you want to set to fail. (An X appears in the box when you select it.)
Note Checking the CPU test does not cause a failure, because that step is not yet
included in the sequence. This dialog box is called in the Setup step group of this test
sequence file. Lesson 2 includes an explanation of step groups.

6. Notice that another window is created in the Sequence Editor when the
sequence begins execution. This is the execution window, while the
window that was initially open is the sequence file window.
To stop an execution, click Stop in the UUT Information dialog box.

After you finish execution, the execution window displays the report.
You can verify which tests failed by scrolling down the test report
generated at the end of execution. Select Execute»Test UUTs again
and run through several UUTs, setting different tests to fail each time,
to become familiar with the execution of this sequence.
This sequence uses preconditions to determine when tests should
execute. For example, if the Powerup Test is set to fail, all other steps are
skipped. Also, notice that the steps labeled “Diagnostics” are skipped
unless their corresponding test fails. This scenario is common in test
systems. If a test fails, you may want to run a diagnostic to determine
exactly which component failed. But it would be a waste of time to run
a diagnostic if the original test passed. Dependencies for determining
which steps execute are called preconditions. Preconditions are
discussed in more detail later in this course.

Optional: Discussion of TestStand Search Directories

TestStand maintains a list of directories to search for files. To view the
current list, select Configure»Search Directories.
TestStand searches for modules specified in a sequence file beginning at the

top of the list and working toward the bottom. You can move directories up
or down in the list to specify precedence. If the list contains a directory you
do not want TestStand to search, you can uncheck the checkbox next to that
directory. See the TestStand User Manual for more information about the
Search Directories.
The list of search directories is maintained in TestExec.ini in the

<TestStand path>\cfg\ directory. When the test system is distributed,
the Engine Installation Wizard includes TestExec.ini in the files to be
distributed.
7. When the exercise is complete, close the execution window and
sequence display window by selecting File»Close.
End of Exercise 1-1

Exercise 1-2A Running a Sequence File from the LabVIEW

Operator Interface
Objective: To become familiar with running test sequences from the operator interface and
viewing reports generated by TestStand.
The Sequence Editor used in the previous exercise is not the only
application for executing tests. The operator interface used in this exercise
is another interface to execute tests. This interface was built with LabVIEW
and is the interface the operator uses on the production floor.
The operator interface looks similar to the Sequence Editor, because it has
most of the same functionality. The two critical differences between the
operator interface and the Sequence Editor are:
• Currently, the operator interface cannot modify or create sequence files,
unlike the Sequence Editor.
• The Sequence Editor is not provided with source code, and therefore you
cannot modify it. On the other hand, the operator interface source code
is included with the TestStand installation and is meant to be modified
so that every user can create a customized operator interface. The source
code for the default operator interfaces included with TestStand is in the
following directory:
<TestStand path>\Examples\OperatorInterfaces
The purpose of this lesson is simply to explore the default LabVIEW

operator interface and become familiar with some of the differences and
similarities between it and the Sequence Editor.
1. Open the operator interface. From the Windows Start menu, select
Programs»National Instruments TestStand»Operator
Interfaces»LabVIEW. This launches LabVIEW.
The operator interface is an application for opening and running test
sequences. As mentioned earlier, the sample operator interfaces
included with TestStand are intended to be a starting point for the
application that will be installed on the test/production floor. The
operator interfaces allow the execution and debugging of multiple
sequences.

After the LabVIEW operator interface is loaded, the Login prompt

appears.
Log in as administrator; as before, the password should be empty.

Click OK to continue.
2. After logging in, select File»Open Sequence File and navigate to
C:\Exercises\TestStand I.
3. Open Ex 1-1 Computer Test.seq.
This is the same sequence that was run in Exercise 1-1. The window
should appear as shown below.

4. Execute the sequence by clicking on the Test UUTs button. This

displays the UUT Information dialog box (shown below), and opens
the execution display window (shown on the next page). Type in any
value for the serial number and click OK. As in the previous exercise,
select different tests to fail before stopping the test to view the report.
During execution, the execution display window shows the status of

each step and allows you to control the execution using tools such as
breakpoints and stepping mechanisms. These tools are covered in
Lesson 2, The TestStand Environment. When you stop the execution
(remember to click the Stop button instead of entering another serial
number and clicking OK), the execution display window displays the
report. In the figure below, the report is displayed using HTML, which
is the default display format in the operator interface. However, notice
that the operator interfaces do not use a web browser control to display
the HTML commands, as the Sequence Editor does.

The sequence display and execution display are separate windows.

The sequence display window displays all information related to the
sequence file currently loaded into memory. This information includes
information such as the sequence filename, the current user logged in,
and the steps in the sequence. The execution display window shows all
information related to the execution of a sequence file. This information
includes the status of each step in the sequence file, which sequence is
being run, and the sequence report contents. Click on either window to
bring it to the front and view its contents.
Note TestStand can run multiple sequence executions in parallel. Switching back to the
sequence display window and clicking the Test UUT button again causes the sequence
to begin executing a second time in a separate execution display window from the first
execution. Additionally, you can load and execute a separate sequence file in parallel
instead of executing the same sequence file. Lesson 3 includes an example of executing
sequences in parallel.
5. Click the Launch Report Viewer button to launch the application

associated with the type of report you are viewing. If the operator
interface is still configured to print the report in HTML format, the
operating system typically launches Internet Explorer or Netscape to
view HTML report files.

6. When you finish viewing the report file, close the web browser that
TestStand used to display the file. Click on the execution display
window to bring it to the front and close it by selecting File»Close
Execution. Next, bring the sequence display window to the front by
clicking on it, and close the sequence by selecting File»Close Sequence
File. Finally, close the operator interface by selecting File»Exit from
the sequence display window.
End of Exercise 1-2A

Exercise 1-2B Running a Sequence File from the

LabWindows/CVI Operator Interface
Objective: To become familiar with running test sequences from the operator interface and
viewing reports generated by TestStand.
The Sequence Editor used in the previous example is not the only
application for executing tests. The operator interface used in this exercise
is another interface to execute tests. The interface used in this exercise was
built with LabWindows/CVI and is the interface the operator uses on the
production floor.
The operator interface looks similar to the Sequence Editor, because it has
most of the same functionality. The two critical differences between the
operator interface and the Sequence Editor are:
• Currently, the operator interface cannot modify or create sequence files,
unlike the Sequence Editor.
• The Sequence Editor is not provided with source code, and therefore you
cannot modify it. On the other hand, the operator interface source code
is included with the TestStand installation and is meant to be modified
so that every user can create a customized operator interface. The source
code for the default operator interfaces included with TestStand is in the
following directory:
<TestStand path>\Examples\OperatorInterfaces
The purpose of this lesson is to explore the default LabWindows/CVI

operator interface and become familiar with some of the differences and
similarities between it and the Sequence Editor.
1. Open the operator interface. From the Windows Start menu, select
Programs»National Instruments TestStand»Operator
Interfaces»LabWindows/CVI.
The operator interface is an application for opening and running test
sequences. As mentioned earlier, the sample operator interfaces
included with TestStand are intended to be a starting point for the
application that will be installed on the test/production floor. The
operator interfaces allow the execution and debugging of multiple
sequences.

After the LabWindows/CVI operator interface is loaded, the Login

prompt is displayed.
Log in as administrator; as before, the password should be empty.

Click OK to continue.
2. After logging in, select File»Open Sequence file and navigate to
C:\Exercises\TestStand I.
3. Open Ex 1-1 Computer Test.seq.
This is the same file used in the previous exercise. The sequence display
window of the operator interface should resemble the one shown below.

4. Execute the sequence by clicking the Test UUTs button. This displays
the UUT Information dialog box (shown below) and the execution
display window (shown on the next page). Type in any value for the
serial number and click OK. As in the previous exercise, try setting
different tests to fail before stopping the test to view the report.
During execution, the execution display window shows the status of

each step and allows you to control the execution using tools such as
breakpoints and stepping mechanisms. These tools are covered in
Lesson 2, The TestStand Environment. When you stop the execution
(remember to click the Stop button instead of entering another serial
number and press OK), the execution display window displays the
report. In the figure below, the report is displayed using HTML, which
is the default display format in the operator interface. However, notice
that the operator interfaces do not use a web browser control to display
the HTML commands, as the Sequence Editor does.

The sequence display and execution display are separate windows.

The sequence display window displays all information related to the
sequence file currently loaded into memory. This information includes
the sequence file name, the current user logged in, and the steps in the
sequence. The execution display window shows all information related
to the execution of a sequence file. This information includes the status
of each step in the sequence file, which sequence is being run, and the
sequence report contents. Click on either window to bring it to the front
and view its contents.
5. Click on the Launch Report Viewer button to launch the application
associated with the type of report you are viewing. If the operator
interface is still configured to print the report in HTML format, the
operating system typically launches Internet Explorer or Netscape to
view HTML report files.
6. Close the sequence by selecting File»Close Sequence File when the
exercise is completed. Then close the operator interface by selecting
File»Exit.
End of Exercise 1-2B

Notes

Lesson 2
Lesson 2:
In this lesson, you will learn about:

• TestStand sequences, step groups, and sequence
files
• The debugging features in TestStand and how to use
them
• The definition of a process model and the default
TestStand process models
• The features available in the Sequence Editor for
managing test development
Introduction
This lesson discusses TestStand sequences, their component step groups, and sequence files. It then
introduces the debugging tools available in TestStand and explains how to execute them in the
Sequence Editor. It also discusses the concept of a process model, and explains how TestStand can
use the various default process models to execute tests. Test file management tools are also
discussed in this lesson.

Lesson 2 The TestStand Environment
TestStand Sequences
What is a sequence?
• A test sequence consists of a series of test modules
and flow control settings used to test a Unit Under
Test (UUT)
• Each line of a sequence is called a step
Sequence
Step 1
Default Execution
Direction
Step 2
Step 3
What is a sequence?
Before getting into TestStand sequence files, it helps to examine a sequence at its most basic level.
A sequence is a series of TestStand steps combined with the control logic that determines the order
in which those steps are executed. Each step performs a particular action that contributes to the
overall testing of the UUT. For example, in a step you could execute a LabVIEW VI that performs
some type of test. The default operation is such that TestStand begins sequence execution with the
topmost step and executes the steps from top to bottom. However, you can control the sequence’s
execution flow; this is addressed in the next lesson.

TestStand Sequences:
Step Groups
As shown below, all TestStand sequences have
three step groups
TestStand Sequence
Cleanup
Main
Setup
Steps
Step Groups
Within every TestStand sequence, there are three step groups: setup, main, and cleanup. These step
groups are always executed in the same order: setup, main, and cleanup. The step groups organize
a series of sequence steps in a logical and sequential manner. For example, the setup group might
contain initialize or power-up routines, the main group might contain the actual test routines, and
the cleanup group might contain steps to close files or power-down instruments. The default
settings for TestStand are such that the cleanup steps are executed even if there is a run-time error.

TestStand Sequence Files

Sequence files include the MainSequence,
its subsequences and steps, and all included callbacks
Sequence File
MainSequence Subsequence Pre-UUT
Setup Callback
Setup Setup
Main
Main Main
Cleanup Cleanup Cleanup
TestStand Sequence Files

TestStand sequence files are comprised of multiple sequences. This may include multiple
user-defined sequences and/or any callback sequences used with this sequence file (for now, think
of callbacks as essentially predefined sequences; callbacks are discussed later).
To illustrate this concept, consider a bar code scanning application. Assume that for a particular
product, the serial number is read by scanning a bar code, but for all other products, an operator
enters it. The test developer would include the Pre-UUT callback (the callback that includes the
serial number inquiry) in the sequence file for that product, and edit it to include the bar code
scanning routines. Each time that particular sequence file is loaded, TestStand recognizes that it has
its own Pre-UUT callback sequence and uses it. However, when other sequence files are loaded,
TestStand still uses the default Pre-UUT callback, which prompts the operator to enter a serial
number.
Thus, the sequence file is a TestStand application file that contains all information necessary for
TestStand to load and execute a particular test application.
Note TestStand sequences typically contain a sequence named MainSequence, which

is different from the Main step group.

Debugging Sequences
Types of debugging tools:

• Execution tracing functionality
• Breakpoint setting
• Single stepping tools
Step In Step Over Step Out
Debugging Tools
TestStand has a variety of debugging tools that help you verify the execution of your TestStand
applications.
The execution tracing option allows you to view the execution flow for the sequence in the
execution window. If tracing is enabled, the Sequence Editor displays the progress of an execution
by placing a yellow arrow icon to the left of the icon for the currently executing step. You can adjust
the speed of tracing by selecting Configure»Station Options and adjusting the slider on the
Execution tab.
The Sequence Editor and operator interfaces allow you to set breakpoints, step into, step over, or
step out of sequences, and set the next step to execute. You can also view variables and create watch
expressions (combination of variables). These tools allow you to control the sequence execution
manually and identify potential areas that require further modification. The debugging tools are
addressed in greater detail in Exercises 2-1 and 2-2.

Exercise 2-1
Objective: To understand subsequences, setup

and cleanup routines, and execution tracing

Exercise 2-2
Objective: To become familiar with using

breakpoints and debugging tools
in the Sequence Editor.

TestStand Sequences:
The Process Models
What is a Process Model?
A Process Model is a list of steps that specify the
high level flow of execution in a test system
About the Process Models:
• There are 3 available process models:
– SequentialModel.seq
– BatchModel.seq
– ParallelModel.seq
• The default model is SequentialModel.seq
• The process models have two modes of operation:
– Test UUTs
– Single pass
The TestStand Process Models

A process model is a list of steps that specify the high-level flow of execution in a test system. In
other words, the process model is the flow of execution of the test executive.
TestStand has three available process models. By default, TestStand uses the sequence file
SequentialModel.seq as its process model. The TestStand process models contain sequences
that define operations TestStand performs before and after it tests a UUT. To invoke (or execute) a
sequence in a process model, run one of the Execution Entry Point sequences in the model.
The TestStand process models have two modes of operation called execution entry points. They
appear as the Test UUTs and Single Pass selections in the Execute menu. Single Pass is usually
for debugging purposes; it executes the selected sequence file only once and generates a test report.
Test UUTs is for testing multiple UUTs. It loops until the operator quits and generates a test report
for all UUTs. The Test UUTs mode is discussed next.
Note If you modify the process models under \TestStand\Components, notice that
there are two subdirectories for the process models: NI and User. Always copy the
process models into the User directory so that you maintain a copy of the originals.

The TestStand Process Models

• SequentialModel.seq
(Default Process Model)
– Multi-purpose process model ideal for most testing
applications
• BatchModel.seq
– Process model used to control a set of test sockets that tests
multiple UUTs as a group or “batch”
• ParallelModel.seq
– Process model used for handling multiple independent test
sockets
Available TestStand Process Models

As mentioned in the previous slide, there are three process models in TestStand. The default
process model is SequentialModel.seq. This sequence file is a multi-purpose process model
that is ideal for most testing applications. The other two process models are designed to make it
easier to implement running the same test sequence on multiple UUTs at the same time. They are
discussed in more detail below.
The Batch process model, BatchModel.seq, can be used for controlling a set of test sockets that
test multiple UUTs as a group. For example, you might have a set of circuit boards attached to a
common carrier. The Batch model ensures that you start and finish testing all boards at the same
time. The Batch model also provides batch synchronization features in which you can indicate that
a step applies to the batch as a whole and therefore the step would only run once per batch instead
of once for every UUT. Another convenient feature is the ability of the Batch model to generate
batch reports that summarize the test results for all UUTs in the batch.
The Parallel process model, ParallelModel.seq, can be used for handling multiple
independent test sockets. The Parallel model allows you to start and stop testing on any socket at
any time. For example, you might have five test sockets for testing radios. The Parallel model
allows you to load a new radio into an open socket while the other sockets are busy testing other
radios.

Default Process Model

Sequential Model: Test UUTs mode
Pre-UUT Pre-UUT Loop
Callback
Setup
Pre-UUT
Main
Cleanup Main Sequence
Loop until
Main Sequence operator quits
Post-UUT
Setup
Main
Generate Report
Cleanup
Post-UUT Loop
The Default Process Model: Test UUTs Mode

The flowchart above depicts the order in which MainSequence and all the TestStand callback
sequences are executed for the Test UUTs mode of the Sequential process model. When the Test
UUTs mode is initiated, TestStand executes the Pre-UUT Loop Callback (test system setup
operations), followed by the Pre-UUT Callback (UUT setup operations). These callbacks are
always part of the process model, unless you modify the process model yourself (discussed in the
customization lesson later in the course).
The next step is the MainSequence step, which the user creates using the Sequence Editor.
TestStand then executes the Post-UUT Callback (UUT clean up operations) and updates a test
report. Execution then returns to the Pre-UUT Callback for the next UUT to be tested. On
completion of testing, TestStand steps out of the loop, generates a test report, and executes the
Post-UUT Loop Callback test (system clean up operations).
The Sequential process model contains model callbacks, which are normal TestStand sequences,
with the exception that these callbacks perform specific tasks during sequence execution. For
example, the Pre-UUT Loop Callback can run setup sequences for testing. The model callbacks
can serve as hooks for you to customize the process model for each MainSequence without
altering the process model directly.

SequentialModel.seq
SequentialModel.seq
Execution entry points in process models, such as Test UUTs and Single Pass, use callbacks to
invoke the MainSequence in your sequence file.
Each sequence file must then define a sequence by the name of MainSequence. The default process
model, SequentialModel.seq, contains a MainSequence callback that is merely a place holder.
The MainSequence in your sequence file overrides the MainSequence place holder in the
SequentialModel.seq.
As shown in the slide above, the default TestStand process model is itself just another sequence file
called SequentialModel.seq. Thus, you can completely edit and customize the process model.
It includes all the callback sequences (as displayed in the pull down View ring), various steps used
for sequencing logic and keeping track of certain TestStand variables, and execution entry points.
Exercise 2-3 introduces you to the default process model sequence file in greater detail.

The Process Model

& TestStand Architecture
ActiveX
Clients
Custom
Operator Sequence
Interface Editor
PROCESS
Application Programming Interface MODEL
TestStand Engine (ActiveX Server) Callbacks
Callbacks
CVI DLL ActiveX TestStand HT

LV Servers Sequence Basic
The Role of a Process Model in TestStand

This slide shows the role of a process model and callbacks in the TestStand architecture.
Essentially, the TestStand Engine executes a model sequence file using the specified process model
to direct the flow of operations in executing sequence files. While executing the process model, the
engine initiates callbacks at the appropriate time to perform their predetermined tasks. In this way,
you can implement modifications without directly modifying the TestStand Engine. Modifications
and customizations are addressed in the Advanced TestStand course.

Exercise 2-3
Objective: To understand the default process

model

Workspaces and Source Control
• Workspaces
– organize sequence files, code modules, and other files
into projects
• Projects
– enables you to access related files quickly
• Source Control
– check files and projects in and out of a source code
control system
• Differ
– graphical tool that enables you to compare and merge
differences between two sequence files
Workspaces and Source Control

A workspace is a TestStand tool that you can use to organize sequence files, code modules, and
other files into projects. Projects enable you to access related files quickly. You can check files and
projects in and out of a source code control system from within the TestStand environment. You
can also share workspaces with other users by checking a workspace file into source code control.
The workspace window displays the contents of a TestStand workspace (.tsw) file. A workspace
file displays a list of any number of TestStand project (.tsp) files. In TestStand, a project file can
contain any type of file or folder but a workspace file can contain only projects.
TestStand integrates with any source code control system that supports the Microsoft SCC
interface. You can check files and projects in and out of your source code control system from a
TestStand workspace. TestStand has been tested with the following source code control providers:
Microsoft Visual SourceSafe, Perforce, MKS Source Integrity, and Rational ClearCase.
The TestStand Differ is a graphical tool in the Sequence Editor that enables you to compare and
merge differences between two sequence files. The TestStand Differ compares the sequence files
and presents the differences in a new window.
For more details on these features, please see the TestStand User Manual.

Workspaces and Projects Demo
Workspaces and Projects Demo

This demo illustrates many of the features discussed on the previous slide. To use this demo, select
File»Open Workspace File from the Sequence Editor menu. Open the TestStand workspace file
C:\TestStand\Examples\Example.tsw. This workspace contains projects consisting of all
the shipping examples that install with TestStand. Use the tree view to browse through various
projects. Notice that the projects can contain not only sequence files but also the associated code
modules. By right-clicking on the Examples property at the top of the tree view, you can add and
remove files from the workspace as well as check files in and out of source control. The computers
used for this course do not have source control software installed on them so you will not be able
to demo the source control tools within this class.
You can use the TestStand Differ tool by opening a sequence file in the Sequence Editor and
selecting Edit»Diff Sequence File With from the menu. A graphical window will then be
displayed that shows you the differences between the compared sequence files.

Lesson 2 Summary:
• A test sequence is a series of test modules and flow control
settings used to test a UUT
• There are three step groups in a sequence: Setup, Main, and
Cleanup
• Sequence files contain user-defined main sequences and
callback sequences required for sequence execution
• A process model defines the high-level flow of execution for a
test executive
• The TestStand default process model is a sequence file called
SequentialModel.seq
• Workspaces, projects, and source code control features help
provide ways to better manage your test files and structure
• The TestStand Differ enables you to make changes to and
compare sequence files
Summary
This lesson discussed the basic components of the TestStand environment: sequences, step groups,
and process models.
In a sense, you can think of TestStand as providing fully customizable “templates” for every aspect
of testing. There is a default template available for the process itself, TestStandModel.seq, and
a default order for sequences: setup, main, and cleanup. These templates should work for the
majority of test environments, but as you work through the exercises in this course, you will see
that you can easily modify each “template” to suit your particular needs.
Taking a top down perspective, a process model consists of a particular ordering of sequences and
callbacks which match a testing process. The sequences themselves consist of a group of steps. The
groups are, in turn, made up of steps configured by test developers. These steps correspond to a
wide variety of actions, including testing a UUT, message popup for status, and so on. The next
lesson discusses how these individual steps are configured to create sequences.

Lesson 2 The TestStand Environment Exercises
Exercise 2-1 Understanding the Sequence File

Objective: To understand subsequences, setup and cleanup routines, and execution tracing.
Subsequences allow the test developer to modularize logical portions of the

test into smaller sequences that are easier to manage and maintain. Breaking
up a sequence file into manageable segments is similar to how a program
developer breaks up sections of a program into many separate files. Each
smaller segment has a very specific purpose and contributes some basic
function to the calling sequence it is a part of. In addition to the sequence it
was designed for, many other sequences can use this subsequence. This
reusability and modularity make subsequences very useful, and TestStand
makes it very easy to create and implement them.
Part A: Calling Subsequences

The following example shows how one sequence can call another sequence.
In this sequence file are two sequences called from within the main
sequence file. This is how TestStand allows one sequence to call another
sequence.
1. In the Sequence Editor, select File»Open and navigate to
C:\Exercises\TestStand I\ and open Ex 2-1 Computer
Motherboard Test.seq.
In this sequence file, the sequences named CPU Test and CPU
Diagnostic Test are subsequences. In TestStand, a sequence can call
another sequence in the same sequence file or a different sequence file.
In this case, the subsequences are in the same sequence file. The light
blue icon for the step type denotes a call to a subsequence. Sequences
are discussed in greater detail later in the course.

2. Execute the sequence by selecting Execute»Single Pass.

Notice that in the report, the step results in the subsequences are
separated from the step results in the calling sequence. Close the
Execution window by selecting File»Close or clicking the X icon on the
window title bar.
3. To open a subsequence, right-click on the blue sequence call icon and
select Open Sequence, as shown below. This displays the selected
sequence call.

4. The Sequence Editor and operator interfaces allow several sequence

files to be open simultaneously. To toggle between open sequences in
different sequence files, use the Window menu, as shown below.
However, these sequences are in the same sequence file.
5. Use the View Ring to toggle between different sequences in the same
sequence menu.
6. Close the subsequence window by selecting MainSequence from the

View Ring.
Part B: Using Setup and Cleanup Groups

The view for an individual sequence has five tabs: Main, Setup, Cleanup,
Parameters, and Locals. The Main, Setup, and Cleanup tabs are
described below, and the Parameters and Locals are described in Lesson 4.
Select a tab to choose which part of the sequence to view.

The Main, Setup, and Cleanup tabs each show one step group in the
sequence. To view the contents of each tab, click the tab. The steps you
insert in each step group have the following purposes:
• Main: Test the UUT.
• Setup: Initialize or configure instruments, fixtures, and the UUT.
• Cleanup: Power down or reset instruments, fixtures, and the UUT.
The Main group contains the bulk of the steps in a sequence, typically the
steps that test the UUT. In this sequence, the Main group contains all steps
that test the UUT, such as Powerup Test, ROM Test, RAM Test, and so on.
The Setup group contains steps that initialize or configure the test system.
In this sequence, the Setup group contains the Simulation Dialog step that
displays the dialog box used to select which computer components should
fail. It also contains a step to turn on a simulated vacuum table for testing
each UUT.
The Cleanup group contains steps that power down or deinitialize the
instruments, fixtures, and UUT. In this sequence, the Cleanup group
contains a step for powering down a simulated vacuum table that was turned
on in the Setup group.
Discussion of Execution Tracing

Notice that sequence execution is traced. If not, ensure that
Execute»Tracing Enabled is checked.
If the computer is too fast to view execution tracing, slow down the
execution tracing by selecting Configure»Station Options, which displays
the Station Options dialog box.

Move the Speed slider toward Slow, which introduces a delay while tracing.
Enable tracing inside of Setup and Cleanup by checking the appropriate

checkbox, as shown above.
Click OK to close the dialog box. With the Ex 2-1 Computer

Motherboard Test.seq sequence file as the active window, start another
execution by selecting Execute»Single Pass and notice how tracing is
affected.
7. When this execution is finished, close the sequence file and execution
windows.
End of Exercise 2-1

Exercise 2-2 Running a Sequence File with Breakpoints and

Single Stepping
Objective: To become familiar with using breakpoints and the debugging tools in the Sequence
Editor.
When creating a sequence file, you may want to observe sequence execution
to make sure the sequence behaves as you intend. During debugging, you
may want to observe execution in some sections of a sequence but not
others. In this case, it is convenient to allow the sequence to execute until it
reaches a section that needs analysis.
TestStand allows you to insert convenient stopping points, known as

breakpoints. Like most modern development systems, TestStand allows you
to set and remove multiple breakpoints for every sequence file.
Part A: The Step Debugging Tools
1. In the Sequence Editor, select File»Open, navigate to

C:\Exercises\TestStand I\, and open Ex 2-2 Computer.seq.
2. Click on the margin space to the left of the CPU test. A red Stop button
appears. This means that a breakpoint has now been placed on that test.
This exercise now explores the use of breakpoints. To remove the
breakpoints later, click each Stop button.

3. Click the Run button. This executes the sequence in Test UUTs mode
and brings up the familiar UUT information dialog box. Enter any
number and click OK.
Run button
Step Into Step Over Step Out Of

button button button
4. The execution pauses at the first breakpoint—in this case, the CPU
Test. Notice that the step into, step over, and step out of buttons in the
toolbar are activated.
Click the step into button. The execution pauses at the first test in the
CPU subsequence. Click on the step over button to stop on the next test.
Note Advanced debugging techniques are covered later in this course.
5. The Run button is now the Resume button. Click on the Resume button
to continue executing to the next breakpoint.
Resume button
Terminate Execution button
6. Click on the Terminate Execution button to terminate. The report

displays the results of all steps that executed.
Note These same debugging options are available in the operator interfaces. However,
these tools will appear under menus rather than as task bar buttons.
End of Part A

Part B: The Watch Window

1. Close the report and return to the Sequence Editor. Remove the
breakpoint that was set on the CPU Test by clicking on the stop icon to
the left of that step. Set a new breakpoint on the Powerup Test by
clicking to the left of that step, which should cause a stop icon to appear.
Then click on the Run button. Enter an arbitrary value for the UUT
serial number and do not check any of the boxes so that all of the tests
will pass.
2. In the lower right corner of the execution window is a section for

watching variables during the sequence execution. This area, the watch
window, is useful for watching the values of variables and expressions
during sequence execution to make sure that values are being set as
expected. One way to add a new value to be watched is to right-click in
this window and select Add Watch, as shown below.
Note You can invoke the watch window only while the execution is running. Therefore,
you should place a breakpoint in a sequence file before it begins running if there are
variables or expressions to watch while debugging the file.

3. This launches the expression browser, which is discussed in a later

lesson. Click the + sign next to Locals and notice the following list of
local variables.

4. Click the variable named PowerFail and click the Insert button.
Then click OK to insert this variable into the watch window. The watch
window should now resemble the following screen.
5. Repeat steps 2 through 4 for the variables CPUFail, ROMFail,

RAMFail, KeyboardValue, and VideoValue. The resulting window
will resemble this screen.

6. Click the Resume button to continue the execution of this sequence.

When prompted, enter another arbitrary number for the UUT Serial
Number. This time, select the Powerup Test to fail and look at the watch
window when you click the OK button to allow the sequence to
continue. The value for PowerFail will change to True as shown below.
This shows that after you select the test and click the OK button, the
value of this variable changes.
7. Click Resume again to complete the execution of this sequence.

Continue running this sequence and select a different test (or series of
tests) to fail and watch how the different variables change in response to
the selections you make each time. This is a simple use of the watch
window, but it demonstrates how you can use this debugging tool to
examine variables and expressions during sequence execution.
Optional: Another Way to Add Values to the Watch Window

With the breakpoint still in place, run the sequence again by selecting
Execute»Single Pass. This time, click on the tab labeled Context.
The expression browser is helpful for creating expressions and using
functions. However, there is another way to add values to the watch
window, which involves clicking on another tab in this window called
Context. In the context list is the same sequence context information
available in the expression browser. However, from this list you can
select an expression to watch and drag it into the watch window. For
viewing variable values, dragging and dropping expressions from the
context menu is easier than using the expression browser to generate
expressions. Both methods produce the same results.

8. Select the same expressions to watch as in steps 2-5 using this

drag-and-drop method from the Context list. Repeat steps 6 and 7 and
observe the values for the expressions as you select the different tests to
pass and fail.
9. When finished with the exercise, select File»Close to close the
execution window, then repeat this selection to close the sequence file
window also.
End of Part B
End of Exercise 2-2

Exercise 2-3 Understanding the Sequential Process Model

Objective: To become familiar with the TestStand Sequential process model by executing a
sequence using execution entry points.
Testing a Unit Under Test (UUT) requires more than just executing a set of
tests. Typically, the test executive must perform a series of operations before
and after it executes the sequence that performs the actual tests. Common
operations include identifying the UUT, notifying the operator of pass/fail
status, generating a test report, and logging results. These operations define
the testing process. This set of operations and their flow of execution is
called a process model. Having a process model is essential so that you can
write different test sequences without repeating standard testing operations
in each sequence.
Part A: Running a Sequence Directly

First, examine the execution of a sequence without using a process model.
1. Using the Sequence Editor, open Ex 2-3 Computer Motherboard
Test.seq.
2. Select Execute»Break at First Step. The Break at First Step option
causes the execution to pause on the first step of the sequence for
debugging purposes.
3. Select Execute»Run MainSequence. The execution pauses on the first
step of the sequence, as shown.

4. Single step through the sequence by clicking the Step Over button in the
toolbar or selecting Debug»Step Over. Continue to single step until the
sequence completes execution.
Notice that only the steps in the MainSequence of the Ex 2-3
Computer Motherboard Test.seq were executed. No additional
steps were run and no report was generated.
Part B: Running a Sequence Using the Sequential Process Model

A process model defines a set of entry points. Each entry point gives the test
station operator different ways to invoke a main sequence. For example, the
default Sequential process model in TestStand provides two entry points:
Test UUTs and Single Pass. The Test UUTs entry point initiates a loop that
repeatedly identifies and tests UUTs. The Single Pass entry point tests a
single UUT without identifying it. Such entry points are called execution
entry points. Execution entry points appear in the Execute menu of the
Sequence Editor or operator interface.
Complete the following steps to run Ex 2-3 Computer Motherboard

Test.seq using the execution entry points.
1. Uncheck Execute»Break at First Step. Select Execute»Single Pass.
Select one of the tests to fail in the Simulator dialog box. Notice that
after TestStand executes the steps in the main sequence, the Single Pass
entry point generates a test report. Examine the test report. It contains
information on the results of each step that TestStand executes. The test
report feature is examined in more detail in a later lesson.
2. Close the execution window by selecting File»Close or clicking the X
icon on the window title bar.
3. Select Execute»Test UUTs. Before executing the steps in the main
sequence, the process model displays a UUT Information dialog box
requesting a serial number. Enter any number and click the OK button.
Again, select a test to fail in the Test Simulator dialog box and observe
the execution window as the sequence is executing. After completing the
steps in the main sequence, the process model displays a banner that
indicates the sequence result. Click the OK button to close the banner
prompt. The process model now displays the UUT Information dialog
box again. Type in another serial number and click the OK button to
loop on the sequence again. Repeat this procedure for several serial
numbers and click the Stop button to complete the execution. TestStand
generates a test report for all UUTs. Examine the test report and verify
that it has indeed recorded the results for each UUT.
4. Close the execution window by selecting File»Close or clicking the X
icon on the window title bar.

Part C: Examining the Sequential Process Model

The process models are in the form of a sequence file. This means you can
edit the process models just like any other sequence. TestStand ships with
three fully functional process models. One of these, the Sequential process
model, is examined in this exercise.
1. In the Sequence Editor, select File»Open and navigate to
<TestStandpath>\Components\NI\Models\
TestStandModel\ and open SequentialModel.seq, the default
TestStand process model sequence file.
2. Select All Sequences from the sequence window View selector. This
shows all sequences contained in SequentialModel.seq, as shown
on the next page. SequentialModel.seq has several types of
sequences, including Execution Entry Points, Configuration Entry
Points, and Callback Sequences. You will examine the execution entry
points for the Sequential process model in this exercise.
Notice that the first two sequences are Test UUTs and Single Pass,
denoted by a reddish-orange colored icon. These are the execution entry
points you have used to execute the example sequences in this and
previous exercises. Having multiple execution entry points gives the
operator choices for different ways to invoke a sequence execution. Each
execution entry point appears as a menu entry in the Execute menu.
3. Examine the Single Pass sequence by selecting it from the sequence

window View selector ring. Notice that after some preliminary
configuration steps, this sequence calls a subsequence called
MainSequence. This is where the process model executes the test
sequence you create in the Sequence Editor. After the MainSequence is
called, the process model calls a subsequence called Test Report
Callback. The Test Report Callback sequence generates the Test Report
for the sequence.

4. Set a breakpoint on the first step of the Single Pass sequence by clicking
to the left of the step or right-clicking on the step and selecting Toggle
Breakpoint from the pop-up menu. A small red stop button to the left
of the step indicates a breakpoint.
5. Return to the Ex 2-3 Computer Motherboard Test.seq sequence
window by clicking on it or selecting it from the Window menu. Select
Execute»Single Pass. The execution window appears and immediately
pauses on the Check for Proper Use step of the Single Pass sequence.
Click the Step Over button in the toolbar or select Debug»Step Over
until the sequence is paused with the execution pointer on the
MainSequence Callback step. Click the Step Into button or select
Debug»Step Into to step into the main sequence. Notice that the
execution has now proceeded to the steps of the Ex 2-3 Computer
Motherboard Test.seq sequence. Step over several of the steps and
then click the Step Out button or select Debug»Step Out to return to
the process model sequence. Notice that the sequence execution has now
returned to the steps of the Single Pass sequence. Resume normal
execution by clicking on the Resume button in the toolbar or selecting
Debug»Resume. You may want to remove the breakpoint before
continuing with the execution but this is not necessary.
6. Close the execution window and all sequence windows.
End of Exercise 2-3

Notes

Notes

Lesson 3
Creating Sequences
Lesson 3:
Creating Sequences
In this lesson, you will learn how to:

• Add steps to a TestStand sequence
• Specify a test module for a step
• Configure step properties
Introduction
This lesson describes the steps involved in creating a TestStand sequence. You will learn how to
create a new TestStand sequence, specify the test modules for each step, and configure the step
properties.

Lesson 3 Creating Sequences
How to Create Test Sequences
• The Sequence Editor allows you to build test

sequences
• Build sequences by adding steps for each test or
action you want to execute
• There are four actions involved in adding each step
to the sequence:
1) Specify the adapter
2) Select the step type
3) Specify the test module
4) Configure the step properties
How to Create Test Sequences

The TestStand Sequence Editor is the development environment for building test sequences.
The Sequence Editor is an intuitive Windows Explorer style interface where steps can be copied,
moved, pasted, or created to build a sequence. There are four steps involved in creating each step:
1. Specify the adapter corresponding to the programming environment in which the test module
is (or will be) written.
2. Select the step type.
3. Specify the test module the step will call.
4. Configure the various step properties.
The following sections examine each step in detail.

Adding a Step to a Sequence:

Step 1 - Specify the Adapter
Step 1 : Specify the Adapter

Before inserting a new step, you must select the appropriate adapter from the Adapter Selection
Ring, as shown above.
Adapters are the interfaces between TestStand and the external application development
environment (ADE) in which you can write test modules. Each external language or type of
compiled file supported by TestStand has its own adapter. Currently, TestStand has seven adapters:
• DLL Flexible Prototype Adapter—Calls Dynamic Linked Libraries (DLLs)
• C/CVI Standard Prototype Adapter—Calls LabWindows/CVI source and object files
• LabVIEW Standard Prototype Adapter—Calls LabVIEW VIs
• Automation Adapter—Calls ActiveX Automation servers
• HTBasic Adapter—Calls HTBasic subroutines
• Sequence Adapter—Calls subsequences
• <None> Adapter—Creates a step that does not call a test module


Step 2 - Select the Step Type
Built-in step types:
• Tests
- Pass/Fail Test
- Numeric Limit Test
- MultiNumeric Limit Test
- String Value Test
• Action
• Sequence Call
• Statement
• Message Popup
• Call Executable
• Synchronization
• Property Loader
• Database
• Goto
• Label
• IVI
Step 2: Select the Step Type

The second action in creating a step is to select the step type and insert it in the sequence window
by right-clicking and selecting the Insert Step option from the pop-up menu. All defined step
types, both built-in and user-defined, appear in the pop-up menu. Select the correct step type for
the test module this step calls. TestStand has the following step types:
Tests are steps for testing UUTs and making pass/fail determinations. There are four built-in test
types in TestStand. Each test type has different associated data and properties.
• Pass/Fail Test: The test module passes a Boolean value (True or False) to determine if the
step passes or fails.
• Numeric Limit Test: The test module passes a numeric value, which is compared to high and
low limits in TestStand.
• MultiNumeric Limit Test: The test module passes multiple numeric values, which are
compared to sets of high and low limits.
• String Value Test: The test module passes a string, which is compared to an expected string
in TestStand.
Actions are steps that perform operations (for example, initializing an instrument). They do not
pass result data back to TestStand, but instead either execute their operation successfully or
generate a run-time error.

Step Types
Numeric limit test Property Loader User-defined
• Measured value Database: step type
• Limits (H, L) • Open/Close Database
String limit test • Open/Close SQL Statement
• Data Operations
• Returned String
• Comparison String Synchronization:
• Lock
Pass/fail test • Semaphore
• Result (T/F) • Rendezvous
• Queue
Action • Notification
• Wait
Sequence call • Thread Priority
Label • Batch Synchronization
• Batch Specification
Statement IVI:
Goto • Dmm
• Scope
Message popup • Fgen
• Tools
Step Types
• Sequence Call—Calls another sequence (which is considered a subsequence of the calling
sequence).
• Statement—Evaluates an expression or sets values of TestStand variables.
• Message Popup—Displays a run-time message in a pop-up dialog box.
• Call Executable—Allows .exe files to be executed from TestStand.
• Property Loader—Allows for dynamic limit/property loading from a file or database. The
property loader step is discussed in more detail in Lesson 10.
• Goto—Branches to another step in the sequence.
• Label—For documentation purposes in the sequence and useful as a target for a Goto step.
• Database—Enables you to manipulate data in tables.
• Synchronization—Enables you to synchronize multiple threads of sequence execution from
within a sequence.
• IVI—Enables you to easily configure and acquire data from IVI class compliant instruments.
TestStand allows you to copy step types and modify their properties to suit your needs. Modifying
and creating custom step types is discussed in the TestStand II course.


Step 3 - Specify the Test Module
• Each step may have an associated test module
• Multiple steps can access the same module
Test Modules
Sequence
LabVIEW VI
Step 1
Step 2
CVI code
Step 3
Step 3: Specify the Test Module

The third step in adding a step to a sequence is to specify the test module that the step calls.
Although some step types, such as Statement or Message Popup, do not require you to specify a
test module, many others, such as Numeric Limit Test, do. A test module can be:
• A LabVIEW VI
• A LabWindows/CVI source file
• An object file
• A static library
• An HTBasic subroutine
• A C DLL
• An automation server
• A TestStand sequence
Although each step can call only one module, multiple steps can call the same module.
A step is a component of a TestStand sequence. A test module is a software module written in an

external application development environment (ADE) that performs a particular task.
To specify a test module for a step, right-click on the step and select Specify Module from the
pop-up menu. In the dialog box that appears, enter information such as where the test module is
located or what type of data to pass to it. Each adapter has a separate Specify Module dialog box.
The Edit LabVIEW VI Call dialog box is shown on the next slide.

Specifying the Module

• Selecting Specify Module for a step brings up an Edit
LabVIEW VI Call dialog box
• TestStand has different dialog boxes for different
adapters
Edit LabVIEW VI
Call Dialog Box
Specifying the Module

Each adapter has its own Specify Module dialog box, because different information is needed to
create the link depending on the programming language used to write the test module. For example,
a LabVIEW step needs to know the location of the VI it calls, while a DLL test needs not only the
DLL location, but also the specific function to call within the DLL, and the parametric data to pass
to the function.

Specifying the Module:

Search Directories
One of these dialog boxes will appear if the module is
not located within the configured search directories
The module is not within a The third option shows a path
subdirectory of the configured that is relative to one of the
search directories configured search directories
Specifying the Module: Search Directories

When you select a module and it is not located in one of the configured search directories, you are
prompted to resolve the path to the module. To edit your search directory settings, select
Configure»Search Directories.
Notice that when you add a directory to the list of search directories you have the option of
including its subdirectories in the search.
If the path to the module is not in a subdirectory of a configured search directory then you are given
two options: add the directory of the module to the list of search directories or reference the module
in an absolute path.
If the module is located in a subdirectory of a configured search directory but the option Search
Subdirectories was not enabled for that directory, you are given the additional option to reference
the module using a path relative to the search directory.


Step 4 - Configure the Step Properties
• Each step in the sequence has a set of properties

• There are six categories of properties associated with
each step:
– General (includes preconditions)
– Run Options
– Post Actions
– Loop Options
– Synchronization
– Expressions
Step 4: Configure Step Properties

In TestStand, each step has a set of associated properties. The final action in creating a sequence
step is to configure these properties so that the step executes correctly in the sequence. The main
categories of properties that apply to all step types are preconditions, run options, post actions, loop
options, synchronization, and expressions.
Access a step’s properties by right-clicking on the step and selecting Properties, which launches
the Properties dialog box. The next section introduces each Properties dialog box, which is
described in greater detail in Exercise 3-1.
The Properties dialog box has the following six tabs:

• General
• Run Options
• Post Actions
• Loop Options
• Synchronization
• Expressions

Step Properties: General Tab
Step Properties: General Tab

The Properties dialog box opens with a view of General tab, which shows the adapter type, the
step type, a description of the step, and user-defined comments.
The General tab has command buttons that vary according to the step type. For example, a Numeric
Limit test has an Edit Limits button to modify the step limits, while a String Value test has an Edit
Expected String button to specify the desired string for comparison with the step results.
Use the Specify Module button to launch a dialog box for specifying a code module (or sequence)
for the step and values to pass as arguments to the code module. (This dialog box is the same one
you see when you right-click on a step and select Specify Module.) Each adapter has a unique
dialog box to obtain the information the adapter needs.
The Preconditions button is addressed in the next slide.
The Advanced button is discussed in the TestStand II Course.

Step Properties: Preconditions

• The precondition property specifies the conditions
that must be true for a step to execute
• You can set sequence execution logic based on the
status of other steps, the value of TestStand
variables, and the value of user-defined expressions
Step Properties: Preconditions

For most applications, you will want to execute many of the steps in a sequence only under certain
conditions. In TestStand, you can set preconditions based on the status of other steps, the value of
TestStand variables, or user-defined expressions consisting of one or more of these values.
TestStand also can execute different levels of precondition expressions that range from simple to
complex, enabling you to create highly flexible sequences.
The main window, Preconditions for <test>, displays the conditions that must be true for the
current step to execute. You can organize several precondition statements by using AnyOf or AllOf
(Boolean OR and AND statements, respectively).
Use the Edit/View Expression section to create your own expressions or to view expressions
entered from the main window.
Use the Insert Step Status section to build precondition expressions for display in the main window,
such as Insert Step Pass (the current step does not execute unless a specified step passes), Insert
Step Fail (the current step does not execute unless a specified step fails), Insert Step Error (the
current step does not execute unless an error has occurred), and Insert Step Executed (the current
step does not execute unless a particular step has run, regardless of whether it passed or failed).

Step Properties: Run Options Tab

You can set the following Run Options:
• Load/Unload dynamic/static
test module
• Precondition evaluation
• TestStand window activation
• Record Results
• Step Failure Causes
Sequence Failure
• Debugging features:
– Run mode: normal, skip,
force pass, force fail
– Breakpoint
– Ignore Run-time Errors

The Run Options tab allows you to configure how TestStand executes the test module called by
the step including Load Option, Unload Option, Run Mode, Precondition Evaluation in
Interactive Mode, and TestStand Window Activation.
The Load Option ring control contains the following items:

• PreLoad when execution begins—Loads the test module into memory when the sequence file
is executed (fast executing time, slower startup on execution of sequence file).
• PreLoad when opening sequence file—Loads the test module when the sequence file is first
opened (fast execution, fast startup when executing sequence file, slower when first loading
sequence).
• Load dynamically—Loads the test module right before it is executed (slower execution time,
least memory intensive).
• Unload when precondition fails—Unloads the test module if it will not be executed due to a
failing precondition (slower execution, less memory intensive).
• Unload after step executes—Unloads the test module after completing execution of step
(slower execution, least memory intensive).
• Unload after sequence executes—Unloads the test module from memory on completion of
sequence exeuction (faster execution, slower after completion of sequence).
• Unload when sequence file is closed—Unloads the test module when closing sequence file
(fast execution and completion of sequence, slower when closing sequence).
Note Execution time refers here to the time for the entire test sequence(s) to complete.


(Continued)
Step Properties: Run Options Tab (Continued)

The Run Mode ring control contains the following items:
• Normal—Runs the step when preconditions are met.
• Skip—Does not execute the module but sets the status to SKIPPED.
• Force Pass—Does not execute the module, but sets the step status to PASSED.
• Force Fail—Does not execute the module, but sets the step status to FAILED.
The Precondition Evaluation in Interactive Mode ring control contains the following items:
• Use Station Option—Uses current station option. Configure»Station Options determines
whether to evaluate the precondition in interactive mode.
• Evaluate Precondition—Always evaluates the precondition for the step when running in
interactive mode.
• Do Not Evaluate Precondition—Does not evaluate the precondition for the step when running
in interactive mode.


(Continued)
Step Properties: Run Options Tab (Continued)

The TestStand Window Activation ring control contains the following items:
• None—Does not specifically activate or deactivate the TestStand window. Activation of
windows will depend on prior window state and window activation of step.
• Activate When Step Completes—Activates the TestStand window upon step completion.
Does not depend on state of window prior to step executing.
• If Initially Active, Re-Activate When Step Completes—Specifies the TestStand window
should be activated upon completion of step if the TestStand window was previously the active
window.
Other Checkboxes on the Options tab control the following items:

• Record Results—Specifies whether results are logged in a test report.
• Breakpoint—Sets a breakpoint on the step. Execution of the sequence pauses at the breakpoint
for debugging purposes. You also can set breakpoints using the Toggle Breakpoint command
in the pop-up menu.
• Step Failure Causes Sequence Failure—Specifies whether TestStand sets the sequence status
to FAILED when the step status is FAILED.
• Ignore Run-Time Errors—Allows any run-time errors generated by this step to be ignored
for debugging purposes.

Step Properties: Post Actions Tab

You can specify various actions to occur based on the
result of a test
Available Post Actions:

– Go to a certain step
– Call a callback
– Break
– Terminate or execute a
user-defined expression
Step Properties: Post Actions Tab

The Post Actions tab allows you to specify actions to be performed based on whether a step passes
or fails. In addition, you can create your own custom conditions. The Post Actions tab contains the
following controls:
• Goto the next step—Executes the next step in the sequence.
• Goto a destination—Branches to the step in the sequence specified in the Destination
pulldown menu (appears if the option is chosen).
• Terminate execution—Terminates the sequence execution.
• Call Sequence—Calls a particular sequence specified in the Sequence pulldown menu.
• Break—Suspends execution at this step. You can then use the debugging tools available to step
through the sequence, or use the Resume option in the Debug menu to continue the sequence
execution.

Step Properties: Loop Options Tab

Allows looping on a step based or a fixed number of
iterations, a pass/fail count, or a user-defined condition

With this step property, you can configure TestStand for several types of step looping. You can
configure a step to loop for a fixed number of iterations or until a given number of pass or fail
counts is achieved. In addition, you can use TestStand expressions (discussed in Lesson 4) to define
a custom looping condition.
The Loop Options tab contains the following controls:

• Loop Type—Configures the type of looping required. The available options are:
– None—TestStand does not loop on the step. This is the default value.
– Fixed number of loops—TestStand loops on the step a specific number of times and
determines the final pass or fail status of the step based on the percentage of loop iterations
in which the step status is PASSED.
– Pass/Fail count—TestStand loops on the step until the step passes or fails a specific
number of times or until a maximum number of loop iterations complete. TestStand
determines the final status of the step based on whether the specific number of passes or
failures occur or the number of loop iterations reaches the maximum.


(Continued)
Step Properties: Loop Options Tab (Continued)

• Custom—Allows you to customize the looping behavior for the step. You specify a Loop
Initialization expression, a Loop Increment expression, a Loop While expression, and a final
Loop Status expression. TestStand uses the loop expressions in the following order:
Loop_Initialization_Expression;
while (Loop_While_Expression == True)
{
Execute_Step;
Loop_Increment_Expression;
}
Loop_Status_Expression;
• Record Result of Each Iteration—Adds the step result to the sequence results list after each
loop iteration. TestStand also adds the final result that it computes for the step loop as a whole
if the Record Results property for the step is enabled.

Step Properties: Synchronization Tab

Allows the test developer to synchronize the step for
batch testing and control the thread accessibility of the
step.
Step Properties: Synchronization Tab

In addition to the synchronization step types, you also can specify common synchronization
properties on any step. The Synchronization tab contains the following controls:
• Use Mutex to Allow Only One Thread to Execute the Step—Specifies that a step acquires
a mutex before it runs and releases it after it completes. A mutex is a synchronization object
that guarantees exclusive access to a resource.
• Batch Synchronization—Specifies that a step enters a batch synchronization section before it
runs and exits the section after it completes. The Batch Synchronization ring control contains
the following items:
– Use Sequence File Setting—Uses the setting denoted in the Sequence File Properties.
– Use Model Setting—Uses the synchronization specified in the process model that is used.
– Don’t Synchronize—Can be used to avoid having the step synchronized with batch.
– Serial—Allows only one thread from the batch to access the step at a time.
– Parallel—Allows all batch threads to access the step simultaneously.
– One Thread Only—Allows only one thread in the batch to access the step. All other
threads in the batch will be denied access to the step and will skip the step.

Step Properties: Expressions Tab

Allows the test developer to define arbitrarily complex
pre and post expressions
Step Properties: Expressions Tab

The Expressions property tab defines expressions that TestStand evaluates before (Pre Expression)
or after (Post Expression) a test module executes. For example, you can use the Pre Expression to
initialize certain variables required for a particular step, and this can be followed by the Post
Expression, which resets the variables to other values in preparation for other steps. TestStand
evaluates the Status Expression to determine whether a step passes or fails.
For example, for a numeric limit step, the default status expression compares the result returned
from the test module with high and low limits to determine whether the step’s status is “Passed”
or “Failed” using the comparison criteria you selected.

Exercise 3-1
Objective: To create steps in the

Sequence Editor

Exercise 3-2
Objective: To create and edit a new sequence

file using step looping

Useful Step Type Features

The step types below have features that could be useful in your
test sequences
• Sequence Call Step Types

– Execute sequence in a new thread
– Execute sequence in a new execution
– Execute sequence on a remote machine
• IVI Step Types

– Provide communication with IVI class drivers
– Permit simulation mode for prototyping test
sequences
Useful Step Type Features

TestStand contains many useful step types. For example, the Sequence Call step type enables you
to make various types of sequence calls. The IVI step types allow direct communication with IVI
class drivers and give you the ability to run sequences in simulation modes.

Sequence Call Options

• Multithreading and Remote Execution Options
Sequence Call Options

The Sequence Call step type makes it simple to execute parallel and remote sequences in TestStand.
Use the Multithreading and Remote Execution section of the sequence call specify module
dialog box to execute a subsequence in a new thread within the same execution or in a new local or
remote execution.
The Multithreading and Remote Execution section contains the following options:
• None—Executes the subsequence within the same thread and execution as the calling
sequence.
• Run Sequence in New Thread—Executes the subsequence in a new thread within the same
execution. This allows the subsequence to run asynchronous to the calling sequence.
• Run Sequence in a New Execution—Allows TestStand to launch the subsequence in a new
execution that runs in parallel to the calling sequence execution. The subsequence can also be
launched in a new execution of an execution entry point, i.e. Test UUTs or Single Pass, within
the specifed process model.
• Run Sequence on a Remote Computer—Executes the specifed subsequence on a remote
computer located on the network. The results of the subsequence will be returned to the calling
sequence located on the client computer.

IVI Step Type Demo
• Using IVI Scope step type
IVI Step Type Demo

IVI step types offer a configuration-based approach to instrument control. The following demo will
illustrate acquiring a waveform from a scope using the IVI step types. It then displays the waveform
and estimates the frequency using LabVIEW. Follow the steps below to run the example.
Ensure that you have a logical name “SampleScope” installed on your computer. For more
information about logical names and IVI please refer to the Appendix A of this course.
1. Open C:\Exercises\TestStand I\IVIExample.seq.
2. Ensure that your report options are set to “Insert Graph” and report type are set to HTML.
3. Select Execute»Single Pass to execute the sequence.
4. You will see a dialog which displays the waveform as shown above.
5. Close the dialog and you will see a report which displays the waveform and also gives you the
frequency estimate of the the wave. You will need the complete IVI driver toolset installed on
your computer to change the frequency.

Exercise 3-3
Objective: To create a sequence

using different step types

Optional Exercise 3-4
Objective: To show how TestStand runs

multiple sequences in parallel

Lesson 3 Summary:
Creating Sequences
• Use the Sequence Editor to edit and build
sequences
• There are four actions to add a step to a
sequence:
1) Specify the adapter
2) Select the step type
3) Specify the test module
4) Configure the step properties
In this lesson, you learned about the basic building blocks for building a sequence: specifying an
adapter, selecting a step type, specifying the test module, and configuring the step properties.
Your decision for choosing an adapter is based on the programming environment in which you
develop your tests. Notice that TestStand provides you with the flexibility of using different
adapters for each step. Through this adapter interface, you can quickly port existing test code to
TestStand.
TestStand provides you with a variety of built-in steps. Remember that there are three step groups
in each sequence: setup, main, and cleanup.
Specifying the test module allows you to select an existing test module or, as you will later learn,
you can build a new module starting from a code template.
Finally, after you add a step to a sequence, you configure the step’s properties. By configuring the
step properties, you can specify a wide range of behaviors, such as skipping the step (Run Options),
executing the step only under certain conditions (Preconditions), looping on the same step a fixed
number of times or until a condition occurs (Loop Options), performing an action after the step
completes (Post Action), or initializing or computing a value before or after the step runs
(Expressions).

Lesson 3 Creating Sequences Exercises
Exercise 3-1 Creating Steps in the Sequence Editor

Objective: To add new steps to a main sequence that will set off an alarm if the ROM Test fails.
Earlier lessons defined the Sequence Editor as the GUI interface to
TestStand for creating and modifying sequence files. Now that this
functionality has been defined, it is important to learn how to add steps to a
sequence file to create a testing sequence for a UUT. When a test fails, there
should be a way to notify the operator of the failure. Seeing this information
in the report may be insufficient, and some other notification method might
be appropriate. In this exercise, the sequence file will set off an audible
alarm whenever the ROM test fails for any UUT.
1. In the Sequence Editor, select File»Open and select
C:Exercises\TestStand I\Ex 3-1 Add Beep Step.seq.
2. Create two steps that set off an alarm if the ROM Test fails.
Before inserting a step that calls a code module, you must specify the
module adapter that the step uses. Select the adapter in the Adapter
Selector Ring to be the DLL Flexible Prototype Adapter. The step
uses the DLL Flexible Prototype Adapter to call a function in a DLL.
3. Right-click on ROM Test and select Insert Step»Action.

An Action step type calls code modules that perform actions necessary
for testing, such as initializing an instrument. By default, action steps do
not pass or fail, so they are not used for actual product tests. You will use
steps for testing later in this course. Name this step AlarmStart. You
can always rename a step later by right-clicking on it and selecting
rename from the context menu.

4. Right-click on the AlarmStart step and choose Properties, as shown

below, or double-click on it to open the Step Properties dialog box.

5. The Step Properties dialog box is shown below.
The Step Properties dialog box contains several options for configuring
the step, including:
• When to load the step
• What conditions will cause the step to execute
• What information TestStand examines to determine whether a test
passes or fails
• Whether TestStand executes the step in a loop
• Ways to sychronize the step with other executions

6. Click on the Specify Module button. This brings up the Edit DLL Call
dialog box. Click the Browse button and select the file Dllfuncs.dll
from the CVI Project Files directory, for the DLL Pathname.
Click OK to select this file.
A dialog box may appear with options for the file path. Choose the
option to use a relative path for the file you selected, so that the path
to the code source is stored relative to the sequence file. Click OK to
return to the Edit DLL Call dialog box.
If the module is not within a subdirectory of the configured search

directories, you are prompted to resolve the path by adding the file you
selected to the search directories, use an absolute path to the file, or use
a relative path for the file.
Select the StartBeep function. All functions exported from the DLL are
listed under the Function Name Control. For this exercise, only the
StartBeep and StopBeep functions are used (the process for adding a
step for the StopBeep function is described later).

Select the Edit Prototype option and set the values as shown below. The
tone parameter sets the beep frequency, which is 1000 Hz in this case.
Note You must build a DLL with a type library for the function prototypes to appear in
the Function Prototype tab at the bottom of the dialog box and for all parameters to
appear in the Parameter menu ring. To create a type library in LabWindows/CVI, you
must create a Function Panel file first.
Do not run the sequence until all the steps in this exercise have been
completed. Click OK to close the Edit DLL Call dialog box.
7. Click the Preconditions button to open the Preconditions Editor.
A precondition specifies the conditions that must be true for TestStand
to execute a step during the normal flow of execution in a sequence.
For example, you might want to run a step only if a previous step passes.
In this case, this step should execute only if the ROM test fails.

In the Preconditions - MainSequence dialog box shown below, you enter

the conditions that control when this particular test executes.
For this exercise, click the ROM Test in the Insert Step Status section.
Click the Insert Step Fail button. This inserts the condition that the
AlarmStart step executes only if the ROM test fails. Notice that other
options for conditions include running the current step only if another
test passed, caused an error, or has executed. It is also possible to create
expressions that can be evaluated and used as conditions for executing a
step. Inserting more than one precondition and the use of TestStand
expressions are discussed later in this course.
After entering the preconditions, click OK to finish.

8. After setting the step’s preconditions, configure and examine other step
properties.
If the AlarmStart Action Properties dialog box is closed, open it by
double-clicking on the Alarm Start step in the sequence window. Click
the Run Options tab to examine the run options and ensure that Run
Mode is Normal, with the step results recorded in the report. Examine
the other Load, Unload, Run, Precondition Evaluation, and Window
Activation options. Ensure that the settings are as shown below before
continuing.
Although some options are self-explanatory, it is helpful to understand

the various Run Mode options and how to use them to configure
TestStand step execution. The options are useful in debugging, to test
the various states of each step, and for understanding how the
preconditions relate to each other.
• Force Pass—TestStand does not execute the step and does not
evaluate its preconditions. Instead, TestStand sets the status of the
step to PASSED automatically.
• Force Fail—TestStand does not execute the step and does not
evaluate its preconditions. Instead, TestStand sets the status of the
step to FAILED automatically.

• Skip—TestStand does not execute the step and does not evaluate its
preconditions. Instead, TestStand sets the status of the step to
SKIPPED automatically.
• Normal—TestStand executes the step normally. This is the default
value.
9. Click the Post Actions tab, as shown below.
The Post Actions tab specifies an action that occurs after a step executes. In
the case of a step that is specified as an Action step such as the StartBeep
step, the only post action option for the step is to use the Custom Condition
option since an Action step does not “Pass” or “Fail”. For other types of test
steps the post action can be conditional on the pass/fail status of the step or
any custom condition expression. For example, you may want to jump to a
particular step in the sequence if this step fails. By default, the On Pass and
On Fail actions are “goto next step.” Review the other available options,
ensuring that the final options are configured as shown above.

10. Click the Loop Options tab.
You can use the Loop Options tab to configure an individual step to run
repeatedly in a loop when it executes. In this case, configure the step to
loop 25 times and record the results of each iteration. Ensure that the
settings are the same as shown above.
Notice that as changes are made in this window, TestStand automatically
builds an expression in the Loop While Expression and Loop Status
Expression controls. An expression is a formula that TestStand evaluates
to obtain a new value from the values of multiple variables or properties.
Expressions are discussed further in the next lesson.
The step runs 25 times, and the step returns a FAILED status if any
iteration fails. This is determined by the loop result, which is Fail if less
than 100 percent of the iterations pass.
Click OK to close the AlarmStart Properties dialog box. The sequence
file should now be the active window.

11. Create another action step by right-clicking on the AlarmStart step

and selecting Insert Step»Action. Name the step AlarmStop.
Right-click on the AlarmStop step and select Specify Module,
repeating the steps given in Step 6 above, but selecting the function as
shown below. This step stops the PC speaker from beeping.
12. Save Ex 3-1 Add Beep Step.seq. Execute the sequence by

selecting Execute»Test UUTs. You should hear the PC speaker beep if
you make the ROM test fail. (Note that some PCs may not have a
speaker. If the sound is not enabled on the machine, and this course is
being taught at a National Instruments training facility, ask the instructor
for assistance.)
End of Exercise 3-1

Exercise 3-2 Configuring Loop Options

Objective: To build a sequence that loops on a step depending on the step results.
One of the many sequence execution options displayed in the last exercise
was Loop Options. In TestStand, there are many different ways to choose to
loop on a step, and there are many different results you can set at the end of
the loop. This exercise examines some of these loop types and results.
1. In the Sequence Editor, select File»New Sequence File. Then select
File»Save As to save the empty sequence file as
C:\Exercises\TestStand I\Ex 3-2 Loop Step On
Fail.seq.
2. Set the Adapter Selector Ring to the LabVIEW Standard Prototype
Adapter.
3. In this step, random numbers returned from the test module are tested.
The random numbers lie between 0 and 1. The test results are limit
checked, and if the value is less than 0.5, indicating a failure, the step
repeats.

Right-click in the sequence window and select Insert Step»Tests»

Numeric Limit Test. Name it RandomNumber. Right-click on the
step and select Specify Module. Click on the Browse button and
select the VI, C:\Exercises\TestStand I\VIs\Random
number.vi.
The other options in the Specify Module dialog box are discussed later
in the course. Click OK when finished.
4. Right-click on the step again and select Edit Limits. Set the limits as
shown below. This indicates a Failure if the returned measurement
(random number) is less than 0.5 and a Pass if it is greater than or equal
to 0.5.

5. Set the loop options so that the step loops five times or until the test
passes. Right-click on the step again, and this time select Properties.
Click the Loop Options tab and set the loop options as shown below.
6. The sequence is now set up to run as desired. Run the sequence several
times and examine the report each time. The report should look similar
to the report shown on the next page.
Note The report is arranged to display a summary about the execution before displaying
information about each loop iteration. If the RandomNumber step had been the third step,
it would be the third item listed in the report and would be followed by the results of the
fourth step. For example, in the test report shown on the next page, the RandomNumber
step eventually passed. Notice that the first “RandomNumber” in the report contains
more information than the others, including the number of passes, failures, and the total
number of iterations of the step. Because the RandomNumber step had looping options
set, the next item in the report is the result of each iteration of the loop. After the results
of each iteration of the loop are reported, the report lists the results of the fourth step.

7. Save the finished sequence file before moving on to the next exercise.
End of Exercise 3-2

Exercise 3-3 Creating a Sequence

It is also useful to combine steps of different types in a sequence. This
exercise builds on skills you have learned in previous lessons. In the first
part, you create a sequence to be used as a subsequence. The second part
shows how to use steps created using different adapter types together in the
same sequence.
Part A: Creating the CPU Subsequence

1. In the Sequence Editor, select File»Open and open
C:\Exercises\TestStand I\Ex 3-3 Creating a Sequence
File.seq.
2. Right-click on the Powerup Test step. Select Insert Step»Sequence
Call. Rename the step CPU Test.
This step calls a specified sequence file as a subsequence during
sequence execution. For this to work, there must be an existing sequence
for this step to call. Therefore, the next step is to create the sequence
CPU Test, which is called as the subsequence.
Note The step and sequence to be called do not need to have the same name. However,
for this exercise it is easier to remember the sequence name if the step name is the same.

3. Click in the View Ring and select the All Sequence view as shown.
4. Notice that there is currently not a sequence named CPU Test in this
sequence file. You can create this sequence in this sequence file by
right-clicking in the window and selecting Insert Sequence as shown.
5. Rename the sequence CPU Test.

6. Click the View Ring and select the CPU Test sequence. This opens the
CPU Test sequence, which does not currently contain any steps. This
is the sequence you will create.

7. Be sure the LabVIEW Standard Prototype Adapter is selected in the

Adapter Selector Ring. Click the Setup tab to change to the Setup step
group window. The setup for this subsequence requires one function.
Right-click in the window and select Insert Step»Action. Rename the
step to Pick Test to Fail.
8. Right-click on this action step and choose Specify Module.

9. Click the Browse button and select the VI,

C:\Exercises\TestStand I\VIs\CPU PreTest.vi. Click OK
to select this VI as the code module.
10. A dialog box may appear with options for the file path. Choose the
option to use a relative path for the file you selected, so that the path
to the code source is stored relative to the sequence file. Click OK to
return to the Edit LabVIEW VI Call dialog box.
11. Make sure the Sequence Context ActiveX Pointer checkbox is

enabled. When completed, the dialog box will appear as shown below.
Click OK to return to the sequence file window.

12. Click the Main tab to switch from the Setup step group window to the
Main step group window. Right-click in the sequence display window
and select Insert Step»Tests»Pass/Fail Test. Rename the step
Register Test.
13. Repeat step 12 three more times to create the Instruction Set
Test, Cache Test, and FPU Test steps, as shown below.

14. Right-click on the Register Test step. Select Specify Module to

bring up the Edit LabVIEW VI Call dialog box. Click the Browse button
to select the code module VI, C:\Exercises\TestStand I
\VIs\Register Test.vi.
15. Click OK to return to the Edit LabVIEW VI Call dialog box. Choose the
option to pass the Sequence Context ActiveX Pointer as a parameter
to the VI. The dialog box should resemble the one shown below.
16. Repeat all of steps 14 and 15 for the Instruction Set Test step,
except select Instruction Set Test.vi.
17. Repeat all of step 14 and 15 for the Cache Test step, except select
Cache Test.vi.

18. Repeat all of step 14 and 15 for the FPU Test step, except select FPU
Test.vi. The finished screen is shown below. The name of the resource
being called at each step appears in the Descriptions column in the right
window pane.
19. Click on the Parameters tab. Right-click in the right window pane and
select Insert Parameter»Boolean to create a Boolean parameter that is
passed into this sequence when it is called as a subsequence. Parameters
are discussed in greater detail in Lesson 4.
20. Rename this parameter CPUFail. Save the sequence and use the View
Ring to select the MainSequence sequence again.

21. Click the Main tab to view the Main step group window of the
MainSequence. Right-click on the CPU Test step and select Specify
Module to select which sequence should be called at this step. In the
resulting dialog box, click the Use Current File option and select the
sequence CPU Test from the Sequence Ring as shown.
The CPU Test sequence created during this exercise has been selected
as the sequence to be called at this step. Remember that this sequence
requires a parameter called CPUFail to be passed to it. Notice that when
you select the CPU Test sequence, the CPUFail parameter is
automatically added to the list of parameters to be passed to the
sequence. This is because the Use Prototype of Selected Sequence
option is checked.

22. You still need to specify the value for this parameter. Click the Browse
button to launch the expression browser. In the expression browser, click
the + sign next to “Locals” and then click the CPUFail variable. Click
Insert to select that expression as the value to be passed.

23. Click OK to return to the Edit Sequence Call dialog box, which should
now resemble the following screen.
24. Click OK to return to the sequence file window. Run the sequence file
by clicking the Run button. The report now contains a section to report
that the sequence CPU Test was run. Additionally, another section lists
the results of each of the four tests created in this exercise. Close the
report, but leave the sequence file open for the next part of this exercise.
End of Part A

Part B: Using Different Adapter Types in the Same Sequence

So far, every sequence has been constructed using the same adapter type.
However, TestStand allows you to use different adapter types in the same
sequence. The rest of this exercise shows how to modify the CPU Test
sequence so that it uses different adapter types for some of the steps. Then,
you will run the sequence again to show that the changes do not affect how
the sequence behaves, other than where it looks for the code resources.
1. Select the CPU Test sequence from the View Ring. Right-click on the
Instruction Set Test and Cache Test steps and select Cut to
remove these steps. Select the C/CVI Standard Prototype Adapter in
the Adapter Selector Ring.
2. Right-click on the Register Test step and select Insert Step»

Tests»Pass/Fail Test. Rename the step Instruction Set Test.

3. Select the DLL Flexible Prototype Adapter in the Adapter Selector

Ring.
4. Right-click on the Instruction Set Test and select Insert Step»

Tests»Pass/Fail Test. Rename the step Cache Test.

5. Right-click on the Instruction Set Test step and select Specify

Module from the menu. Click Browse and select the code module,
C:\Exercises\TestStand I\CVI Project Files\Computer
cvi.dll. Click OK to proceed to the C/CVI Module Call dialog box.
6. Select the function InstrSetTest from the Function Name Ring.

7. Check the options to Pass Sequence Context and to use Standard

Prototype. Click OK to return to the Sequence Editor.
8. Right-click on the Cache Test step and select Specify Module from
the menu. Click Browse and select the code module,
C:\Exercises\TestStand I\CVI Project Files\Computer
dll.dll. Click OK to proceed to the Edit DLL Call dialog box.
9. Select the function Cache Test from the Function Name Ring.
10. Select the first parameter, seqContextCVI, and fill in the following
information:
Parameter: seqContextCVI
Value Expression: ThisContext

11. Select the result parameter and fill in the following information:
Parameter: result
Value Expression: Step.Result.PassFail
Result Action: No Action
12. Select the errorOccurred parameter and fill in the following
information:
Parameter: errorOccurred
Value Expression: Step.Result.Error.Occurred
13. Select the errorCode parameter and fill in the following information:
Parameter: errorCode
Value Expression: Step.Result.Error.Code
14. Select the errorMsg parameter and fill in the following information:
Parameter: errorMsg
Value Expression: Step.Result.Error.Msg

The resulting dialog box should resemble the one shown below.
The Function Call tab at the bottom of the screen contains the actual
function call. Click OK to exit the Edit DLL Call dialog.
15. Select the MainSequence from the View Selector Ring. Save the
sequence and run it by clicking the Run button. The sequence file
should execute the same as before, and the report should be identical
also. The only difference is that two of the steps in the CPU Test
subsequence are now calling DLLs using different adapter types, instead
of calling LabVIEW VIs using the LabVIEW adapter. When the
exercise is complete, close the sequence file.
End of Part B

Optional Discussion on DLL and C/CVI Prototype Adapters

What are the differences between the DLL Flexible Prototype Adapter and
the C/CVI Standard Prototype Adapter?
This exercise introduced the C/CVI Standard Prototype Adapter. Both the
C/CVI Standard Prototype Adapter and the DLL Flexible Prototype Adapter
can call DLLs, but they use different methods to call these code modules.
This discussion compares these two adapter types and describes the benefits
of each.
C/CVI Standard DLL Flexible

Feature Prototype Prototype
Test functions can have a variety of prototypes No Yes
Allows you to pass any argument to a test function No Yes

directly
Automatically passes a predefined set of common Yes No

arguments to each test function
Allows debugging C source files from TestStand Yes1,2 No
Allows debugging DLL functions from TestStand Yes1,2 Yes1,3
Code modules can be C source files, object files, or Yes No (DLLs

static libraries only)
Can call DLLs created with MSVC++, Borland Yes Yes

C++, Delphi, or another compiler
Backward compatible with LabWindows/CVI Test Yes No

Executive Toolkit
Can create source code from code templates Yes4 Yes
Can use TestStand API within code modules Yes Yes
1. Requires LabWindows/CVI 5.0 or later.

2. You must configure the LabWindows/CVI Standard Prototype Adapter to execute
steps in an external instance of LabWindows/CVI.
3. You must launch the Sequence Editor or operator interface from the DLL
development environment.
4. Creation and editing of source code is integrated with the LabWindows/CVI
environment.
When developing new tests, C/C++ users must decide whether to use the
C/CVI Standard Prototype Adapter or the DLL Flexible Prototype Adapter.
Each adapter has advantages. Use the adapter that best suits your particular
needs.

The C/CVI Standard Prototype Adapter uses a standard prototype, while the
DLL Flexible Prototype allows a choice of various function prototypes. The
DLL Flexible Prototype Adapter gives you more flexibility when you define
your test functions. You can pass any number of arguments directly to a test
function. This makes it convenient to access TestStand variables or
properties in the function. Of course, you can always use the TestStand API
to access TestStand variables and properties from test functions that you call
with either adapter.
The C/CVI Standard Prototype Adapter allows you to step into C

source files and DLLs from TestStand using an external instance of
LabWindows/CVI. However, you can always debug a DLL from your
C/C++ development environment by launching the Sequence Editor or
operator interface as an external process from the development
environment. The C/CVI Standard Prototype Adapter makes debugging
more convenient for LabWindows/CVI users by allowing them to step into
their C source or DLL directly from TestStand.
The C/CVI Standard Prototype Adapter also allows you to use object files,
static libraries, and C source files (in LabWindows/CVI). In addition, the
C/CVI Standard Prototype Adapter has tighter integration with the
LabWindows/CVI environment for creating and editing code. Finally, the
C/CVI Standard Prototype Adapter uses a fixed prototype to which it passes
a predefined set of parameters. You do not need to specify the argument
values to pass to your test functions.
When making your decision, keep in mind that it might be difficult to switch
from one adapter to the other once you start test and sequence development.
End of Exercise 3-3

Exercise 3-4 Running Sequences in Parallel (Optional)

TestStand can run multiple sequences in parallel. Each sequence is given a
separate thread to run in when executed. This exercise demonstrates a
simple example of multithreading by showing how to run the same sequence
multiple times in both the Sequence Editor and one of the operator
interfaces. You will learn that it is possible to run different sequences at the
same time instead of running the same sequence many times
simultaneously. Additional multithreading features in TestStand are
discussed in the TestStand II course.
Note For this exercise, be sure to select the Execute»Tracing Enabled option or select
Configure»Station Options and adjust the slider on the Execution tab. When this option
is enabled, the sequence execution includes yellow arrows indicating the current
sequence execution step. When this option is not enabled, there are no visible markers to
indicate the current step being executed in any sequence execution window.
1. In the Sequence Editor, open the sequence file,

C:\TestStand\Examples\Demo\Misc\RunForever.seq. This
example ships with TestStand. This sequence file runs a series of steps
and then loops back to the beginning of the sequence and runs the steps
again. This process continues until the sequence is terminated manually.

2. Set the sequence display window so that multiple windows are viewable
in the Sequence Editor.

3. Click the Run button and notice that the sequence begins executing and
continues running when it reaches the end of the sequence file.

4. Click on the runforever.seq [Executing] window. The execution

window continues running. Notice that with this window as the active
window, the Run button is once again enabled.

5. Click the Run button again and notice that a second execution window
opens. Notice that the two sequence executions are both running and are
executing independently from one another. Click the Run button several
more times and notice that you can run many executions simultaneously
and independently from one another.
6. Because this sequence has no built-in way to stop itself, you may stop
the sequence execution by clicking the X button in the top right corner
of the execution window or selecting Terminate All Executions under
the debug menu. When you click this button, the following dialog box
appears. Select the option to Terminate Execution. This allows
TestStand to halt the execution cleanly and run any cleanup steps for the
executing sequence. Repeat this process for each sequence execution.

7. When finished closing all sequence execution windows, close the

sequence file to complete the exercise.
End of Exercise 3-4

Notes

Lesson 4
TestStand Parameters,
Variables, and Expressions
Lesson 4: TestStand Parameters, Variables,

and Expressions

• Parameters
• Local Variables
• Sequence File Global Variables
• Station Global Variables
• RunState Properties
• The Expression Browser (to view variables and
build complex expressions)
Introduction
One of the most powerful TestStand features is its flexible framework for sharing data. In this
lesson, you will learn about TestStand parameters and the three types of TestStand variables: locals,
sequence file globals, and station globals. You will also learn about runstate properties and how to
utilize the TestStand Expression Browser to use variables and properties in expressions throughout
the TestStand environment.

Lesson 4 TestStand Parameters, Variables, and Expressions
TestStand Parameters and Variables

• Used to share data between steps of a
sequence or among several sequences
• Different methods for sharing data:
– Parameters
– Local Variables
– Sequence File Global Variables
– Station Globals
TestStand Variables
One of the most important functions that test executive software provides is a method for sharing
data among tests and sequences. In TestStand, there are three different types of variables for sharing
data collected by tests. The three variable types differ only in their scope, or where they can be
accessed.
• Parameters—Used only within a sequence to pass data between subsequences and the calling
sequence. A subsequence is a sequence called as a step from within another sequence (that is,
the calling sequence).
• Local Variables—Share data within a single sequence file between the steps of a sequence.
• File Global Variables—Share data between multiple sequences within a single sequence file;
share data between steps of the sequences within that sequence file.
• Station Globals—Share data between multiple sequence files. Station globals are defined for
a particular installation of TestStand, and any sequence files running on the station can access
them.

TestStand Parameters
• Directly pass data between calling sequence and
subsequence
• Define in Parameters tab of sequence display
window
Sequence File
Subsequence 1
Parameter 1
Calling Sequence Parameter 2
Data 1
Data 2 Subsequence 2
Parameter 1
Parameter 2
Parameters
Sequences may have parameters for passing data from one sequence to another. In LabVIEW, using
parameters with sequences in TestStand is analogous to passing data between VIs using connectors
in the block diagram of the top level VI. For LabWindows/CVI, using parameters in TestStand is
analogous to passing data through function parameters. To create parameters in the sequence
display window, use the Parameters tab and select the desired data type. Any step within the
sequence can then access (read or write) the parameters.
Parameters are typically used to pass data between top-level sequences and subsequences. Identify
subsequence parameters and specify their values in the Edit Sequence Call dialog box, which
appears when you insert a Sequence Call step into a sequence and specify the module. The Edit
Sequence Call dialog box is shown on the next slide.

Parameters:
Passing data to subsequences
Parameters: Passing data to subsequences

As shown in the slide above, SequenceFile2.seq is the sequence file and MainSequence is
the sequence to be called as a subsequence. The first parameter in the subsequence is passed a
constant numeric value of 10, while the second parameter is passed the value of a parameter in the
calling sequence. Under the How Passed column, the by reference setting indicates that the
parameter being passed is a reference to an argument, instead of a copy of its value. Passing a
parameter by reference allows the subsequence to change the actual value of the argument
(affecting the calling sequence), hence allowing the parameter value to be updated during run time.

Local Variables
• Share data among all steps in a sequence
• Access using expressions and/or test
modules
Sequence A
Step 1
Seq A
Locals
Step 2
Local Variables
Local variables are shared within a single sequence. All sequence steps can get (read) or set (write)
the value of the local variables defined for a sequence. The value of a local variable can be read or
written in any TestStand expression associated with steps in that sequence, or in any of the test
modules called by those steps. Thus, each sequence has its own set of local variables.
For example, you can store a local variable called Serial Number at the beginning of the sequence,
and then retrieve this serial number in subsequent tests to help you decide which specific tests
to run.

Creating Local Variables

• Each sequence has a local variables tab
• Create a new local variable by right-clicking in this
window and selecting the appropriate data type
Creating Local Variables

Each sequence has a Locals tab, which shows all local variables defined for that particular
sequence. To add a new local variable to the sequence, right-click inside the right pane of the Locals
window, select Insert Local, choose the variable type, and name the variable accordingly. The
variable types available in TestStand are Number, String, Boolean, ActiveX references, and arrays
of these data types. In addition, you can create your own custom data types. The lesson on
TestStand types explains how to create custom data types.

Exercise 4-1
Objective: To add a local variable to a

sequence and pass data between steps

Sequence File Global Variables

Share data between all sequences of a sequence file
Sequence File
Sequence A
Step 1
Seq A
Locals
Step 2
Sequence File
Globals
Sequence B
Step 1
Seq B
Locals
Step 2
Sequence File Global Variables

Sequence file global variables are similar to local variables, except that they have a larger scope of
usability. Besides being accessible from all steps in a given sequence (like local variables), any
other sequence in the sequence file can access file global variables. Thus, each sequence file has its
own unique set of global variables.

Creating Sequence File Globals

• Select sequence file globals from the view selector ring to
display globals
• Create a new global variable by right-clicking, choosing Insert
Global, and selecting the appropriate data type
Creating Sequence File Global Variables

Creating a global variable is similar to creating a local variable. Choose Sequence File Globals
from the view selector ring control of a sequence file window (indicated by View:). This displays
the Globals window, which displays all global variables defined for the sequence file. Right-click
in the right pane of the Globals window, select Insert Global, select the variable type, and rename
it to create a new sequence file global.

Station Globals
Station globals have the largest scope: they share data
between multiple sequence files
Sequence File A
Sequence A
Seq A
Step 1 Step 2 Locals Seq File
Globals
Sequence B Seq B
Step 1 Step 2 Locals
Station Globals
Sequence File B
Sequence A
Seq A
Step 1 Step 2 Locals Seq File
Globals
Sequence B Seq B
Step 1 Step 2 Locals
Station Globals
Station globals have a larger usability scope than either locals or sequence file globals. They pass
data between different sequence files. Station globals are defined for a particular test station and
their values are written to StationGlobals.ini each time the Sequence Editor is closed. This
enables TestStand to keep track of data values even when it is shut down. This allows users to save
state information, such as the last operator to run a test.
The values of station global variables are persistent across different executions and even across
different invocations of the Sequence Editor or run-time operator interfaces. In addition, the
TestStand API includes an ActiveX method that may be called to update StationGlobals.ini
explicitly.

RunState Property Object
• Contains all the property objects that describe the

state of execution in the sequence invocation
• Some of the RunState properties are shown below
RunState Property Object

The RunState property object contains all the property objects that describe the state of execution
in the sequence invocation.
The RunState property object contains many subproperties. Some of these are listed below with
a brief description:
• Engine—Engine object in which the sequence invocation executes
• Root—Sequence context for the root sequence invocation
• Main—Sequence context for the least nested sequence that is not in a process model
• ThisContext—Reference to the current sequence context
• Caller—Sequence context for the sequence that called the current sequence
• Report—Report object for the execution
• Execution—Execution object in which the sequence invocation runs
• Sequence—Run-time copy of the Sequence object for the sequence invocation
• Thread—Thread object in which the sequence invocation executes

RunState Subproperties
• Some subproperties are not filled until run time since

their contents depend on the invoked sequence
Empty Filled
RunState Subproperties
It is important to note that some of the properties listed under the RunState property object are
empty when a sequence is not being executed. To find which subproperties are available when a
sequence is not being executed, select View»Browse Sequence Context from the menu and
expand the RunState property object. The majority of the RunState subproperties will be listed
at this time. However, some of the subproperties that are containers will not contain any
information, such as the Root, Main, Caller, and Execution properties.
To view which RunState subproperties are available during a sequence execution and what
information is contained in these properties, place a breakpoint on a step within the sequence.
Execute the sequence and when TestStand reaches the breakpoint, select the Context tab from the
execution display. Expand the RunState property object to view the available properties
according to the current sequence invocation.

RunState Property Example
How to access UUT Serial Number:

• Set Breakpoint
• Execute Sequence (Execute»Test UUTs)
• Browse RunState to UUT Serial Number
(RunState.Root.Locals.UUT.SerialNumber)
• Copy Property Path
RunState Property Example

This example illustrates how to use the RunState property object to obtain the UUT serial number
in a test sequence. The UUT serial number can be accessed from the RunState property in
different ways. This example obtains the UUT serial number from the Root subproperty. Since the
Root subproperty only contains information when the sequence is executing, the UUT serial
number will only be visible via the Root subproperty at run-time. Follow the steps below to find
the UUT serial number in the RunState property and incorporate using the serial number in your
test sequence.
1. Place a breakpoint on a step in your sequence where you want to access the UUT serial number.
2. To execute the test sequence, select Execute»Test UUTs.
3. When the execution pauses on the breakpoint, select the Context tab.
4. Browse to the RunState.Root.Locals.UUT.SerialNumber property.
5. Right-click on the serial number property and select Copy Property Path to copy the above
path to your clipboard.
6. Finish executing the sequence and return to the main sequence display.
7. Paste the path of the property into the expression window in your sequence where you need to
use the UUT serial number.

The Expression Browser

• Simplifies building complex expressions
• Launch from the Browse button next to any

expression window
• Includes two tabs:

– Variables/Properties
– Operators/Functions
The Expression Browser

The TestStand Expression Browser allows you to use the TestStand variables you create within the
Sequence Editor.
An expression is a formula that calculates a new value from the values of multiple variables or
properties. You can use TestStand expressions to evaluate a value in place of hardcoding a value
for a simple variable or property value. Throughout the Sequence Editor, there are locations (input
controls) where you can create a custom expression for evaluation purposes during sequence
execution. This is possible from many locations such as the Post Actions, Loop Options, and
Expressions property tabs, and also from within the Statement, Limit Loader, and Message Popup
steps.
You can enter an expression in any TestStand control that has a Browse button beside it. Clicking
on this button brings up the expression browser, which is a tool for building your expressions, and
is especially useful for the novice user. You can also launch the Variable Browser by selecting
View»Browse Sequence Context. This browser is similar to the expression browser, except the
functions and operators do not appear. Although it is not necessary to use the expression browser
to enter an expression, it is useful for locating variables and functions when building complex
statements. The next slide shows how to use the expression browser features.

Using the Expression Browser
Using the Expression Browser

The expression browser includes two tabs: Variables/Properties and Operators/Functions.
The Variables/Properties tab displays all variables and properties accessible to the current
context. The Operators/Functions tab includes all valid TestStand operators (such as those used
for comparison, addition, and so on) and functions (mathematical, string handling, and so on).
Using these two sections in conjunction allows you to build complex expressions quickly and
easily. The expression browser also includes a Check Syntax button that determines whether the
expression syntax is correct. You can then insert the expression into the appropriate context of the
current window.
There are terms you should understand as you develop more complex TestStand sequences using
the Expression Browser:
• SequenceContext—Contains references to all global variables, local variables, and step
properties in active sequences. The sequence context contents change depending on the
currently executing sequence and step.
• ThisContext—Refers to the current sequence context. You usually use this property to pass the
entire sequence context as an argument to another sequence or a step module. Sequence
contexts are ActiveX Automation reference handles you can use in conjunction with test
modules.
• RunState—Contains properties that describe the state of execution in the sequence invocation.

Defining Variables and Parameters

• Expression Browser allows you to add and remove
variables and parameters in your test sequences
Defining Variables and Parameters

Often times when creating expressions in the Expression Browser you will realize that it would be
better to use an additional variable or parameter that you have not previously defined in the
Sequence Editor. In order to prevent you from leaving the Expression Browser to define the new
variable or parameter in the tab or window mentioned previously in this lesson, the Expression
Browser allows you to define variables and parameters from within it. You can declare new locals,
parameters, file globals, and station globals from within the Expression Browser. When you
right-click on the variable type or parameter in the Expression Browser, a pop-up menu appears
that allows you to select the data type of the new variable or parameter you wish to define. This
pop-up menu offers the same declaration choices as the other variable editing views in the
Sequence Editor. Once the variable or parameter has been defined from within the Expression
Browser it appears in the respective tab or window within the Sequence Editor as if you had defined
it there originally.

Exercise 4-2
Objective: To create locals, file globals, and

station globals and use the expression browser
to understand the scope of variables

Exercise 4-3
Objective: To modify the limit properties of a

Numeric Limit Step

Exercise 4-4
Objective: To use expressions and parameters

in subsequence executions

Exercise 4-5
Objective: To create a test which dynamically

selects which sequence to run

Lesson 4 Summary:
Parameters, Variables, & Expressions
• TestStand has different scopes for data sharing
– Parameters share data between calling sequences and
subsequences
– Local variables share data between steps in a sequence
– Global variables share data between all sequences within a
sequence file
– Station globals share data between all sequence files within
the TestStand environment
• RunState Properties describe the state of execution
• The Expression Browser is a tool for building
expressions and can also be used to define variables
and parameters
Summary
In this lesson, you learned how to share data within the TestStand environment. Each method for
sharing data serves a particular purpose. You may want to think about which situations would
require the use of parameters, locals, sequence file globals, or station globals. For example, as you
begin deployment onto the production floor, what information on the test station is needed across
shifts? If you have a DLL, should all the data manipulation be internalized or shared using
sequence locals?
As you access and modify variables, you may also want to make use of the RunState properties for
information such as the UUT serial number, the UUT loop index, and the next step index. Using
multiple variables and properties in your expression can create complex statements. TestStand
eases this task by allowing you to create arbitrarily complex expressions through the Expression
Browser. It also improves programming efficiency by allowing you to define variables and
parameters from within the Expression Browser.
Now that you have learned the basics of the TestStand sequence editor, the next lesson will discuss
how test programs from external development environments interact with TestStand.

Lesson 4 TestStand Parameters, Variables, and Expressions Exercises
Exercise 4-1 Using Local Variables

Objective: To add a local variable to a sequence to share data between steps.
Local variables share data between steps in the same sequence. This type
of variable has the smallest scope, but is used most often. This lesson
demonstrates how to use local variables to change the frequency of the alarm
configured in a previous exercise.
1. In the Sequence Editor, open the sequence file,
C:\Exercises\TestStand I\Ex 4-1 Local Variables.seq.
This file is the same as the solution for exercise 3-1. The solutions for
the exercises are in the C:\Solutions\TestStand I directory. In
this exercise you will add a local variable to the sequence.
Click on the Locals tab and right-click in the right pane of the window.
Select Insert Local»Number, as shown.
2. Name the local variable Frequency. This variable sets the audible
alarm tone when the ROM Test fails.

3. Click on the Main tab. You must change the module called during the
ROM Test step at this point. Right-click on the ROM Test and
select Specify Module. Click on the Browse button to select the VI,
C:\Exercises\TestStand I\VIs\ROM Test - Local
Variable.vi. Remember to select a relative path when TestStand
prompts for how the path should be stored. Select the Show VI front
panel when called and Sequence Context ActiveX Pointer options.
The screen should appear as shown below.
Note Failing to select the Show VI Front Panel When Called option may lead to an
infinite loop running in the VI.
Note If you are not familiar with National Instruments LabVIEW programming
environment, skip to step 4.
Click the Edit VI button on this screen to edit the VI. Observe that the
front panel has a frequency control for entering the frequency value.
Go to the block diagram and observe that the frequency value is passed
to TestStand using the TestStand Automation VIs. The main VI to notice
in this diagram is TestStand - Set Property Value(number).vi,
because it passes the numeric value into TestStand. These VIs and their
functions are covered in greater detail later in the course. Close the VI.

4. Edit the StartBeep step to set the tone using the Frequency local
variable.
Right-click on the StartBeep step and select Specify Module. In the
Parameters section, delete the constant value of 1000 in the Value
Expression control. Press the Browse button and choose
Locals.Frequency. Click Insert and then OK. The Edit DLL Call
dialog box should now have Locals.Frequency set as the value for
the parameter Tone. Select OK to return to the sequence display
window.
5. Save the sequence file Ex 4-1 Local Variables.seq. Select

Execute»Test UUTs and try varying the frequency for several different
tests. Remember that the ROM Test must be set to fail for the alarm to
sound. The alarm will sound with a tone proportional to the frequency.
End of Exercise 4-1

Exercise 4-2 Examine the Uses and Differences between

Locals, File Globals, and Station Globals
Objective: To create local variables, file global variables, and station global variables and
understand the difference in their scope.
It is important to understand the differences between the three different
types of variables in TestStand. A good rule of thumb to follow is that local
variables are for sharing data between steps in the same sequence, as
demonstrated in the previous exercise; file global variables are for sharing
data between a step in one sequence and a step in another sequence in the
same sequence file; and station global variables are for sharing data between
steps in two sequences in different sequence files. This exercise
demonstrates how to create each type of variable and emphasizes the
differences between them.
Part A: Local Variables

1. In the Sequence Editor, select File»New Sequence File to open a new
sequence file.
2. A local variable is for sharing information between different steps in a
single sequence. Click on the Locals tab to view the local variable
window. Right-click on the right pane and select Insert Local»Number
as shown below.
This creates a numeric local variable. Name the local variable LocalA.

3. Select the menu option View»Browse Sequence Context to view the

variables and properties in the TestStand environment relative to the
current sequence. This launches the variable browser.
Remember that this is different from the expression browser because it
is missing the functions and operators found in the expression browser.
In any location that can accept an expression, there is a browse button
that launches the expression browser. The expression browser displays
the hierarchy of properties and variables for the sequence context from
which it is invoked. This browser will be increasingly useful later in the
course as more advanced topics are discussed.
Click on the + box to expand the list of local variables and notice that
the LocalA variable created in the previous step is listed, as shown
below. Click Close to return to the sequence file and continue with the
exercise.
4. Select File»Save As to save the sequence file as

C:\Exercises\TestStand I\Ex 4-2 All Variables1.seq.

5. Select File»New Sequence File to create a new sequence file and create
another local variable by repeating steps 1 through 4 above. Name this
local variable LocalB and the sequence file Ex 4-2 All
Variables2.seq. You should see the panel shown below.
Select the menu option View»Browse Sequence Context, and notice

that only the local variable created in this sequence is visible. This is
because the variable LocalA, created in the first sequence, is not
accessible. The scope of local variables is limited to a single sequence;
they can be accessed only from within the sequence in which they were
created. Click Close to exit the dialog.
6. Click on the View ring (as shown below) and select All Sequences to
see all the sequences in this sequence file.
Notice that there is only one sequence, named MainSequence, in this

sequence file.

7. To create another sequence, right-click in an empty space within the All

Sequences view and select Insert Sequence from the popup menu.
Name this sequence TestSequence. The final result should appear as
shown below.
8. Click on the View ring and select TestSequence to view the contents of
this sequence.
9. Select the menu option View»Browse Sequence Context. Notice that
LocalB is not available for use in this sequence, as shown. This is
because LocalB was defined in the MainSequence and not in the
TestSequence.
Note Although the two sequences are in the same sequence file, the local variables are
not shared between them.

Click Close to exit the dialog. Leave this sequence file open for the next
part of this exercise.
End of Part A
Part B: Sequence File Globals

A file global variable is for passing data between different sequences in the
same sequence file.
1. Use the View Selector to select Sequence File Globals. Right-click in
the right pane of the File Globals window and select Insert
Global»Number. Name this variable TestFileGlobalA. Save the
sequence file by selecting File»Save.
2. Click on the View Selector and select TestSequence to view the
contents of this sequence.
3. Select the View»Browse Sequence Context. Notice that the
TestFileGlobalA variable is available for use in this sequence, as
shown.
4. Click Close to return to the Sequence Editor. Use the View Selector to
select the MainSequence. Select View»Browse Sequence Context
and notice that the TestFileGlobalA variable is available for use in
this sequence also.
Therefore, the data in the file global you created in MainSequence is
available for use in all other sequences in the Ex 4-2 All
Variables2.seq sequence file. In this way, you can use sequence file

globals to pass data between the different sequences in the same

sequence file. This should help to distinguish the difference between
local variables and file global variables in TestStand. The last part of this
exercise describes station global variables.
End of Part B
Part C: Station Globals

Station globals are for sharing data between different sequence files. In this
part of the exercise, you will create a station global variable and examine its
scope.
1. Create a station global and examine its scope.
Click on the globe icon beside the Adapter Ring. This opens the Station
Global palette. Right-click on the right pane and select Insert
Global»Number as shown below. Name this station global variable
StationGlobal1.
2. Select Window»Ex 4-2 All Variables2.seq. Next, select View»Browse

Sequence Context…. Click the + sign beside Station Globals and
notice that StationGlobal1 is available for use. Click Close when
finished to return to the sequence file.
3. Select File»Save to save Ex 4-2 All Variables2.seq and then
close it by selecting File»Close.
4. Open Ex 4-2 All Variables1.seq if it is not already open and
select View»Browse Sequence Context. Click the + sign beside
Station Globals and notice that StationGlobal1 is available for use.
In fact, any sequence executed on this test station can use station globals.
In addition, station globals are persistent; that is, they keep their value in
a.ini file from one TestStand session to the next. Click the + sign

beside the station global called TS and notice that this container holds a
value called LastUserName. This variable is the name of the last user
that logged into TestStand and it is being stored as a station global
variable. LastUserName is stored in a station global variable because
when the Sequence Editor is launched, the user name from the previous
session is displayed in the Login dialog box.
The last user

to log in
is stored in a
station global
variable
5. Click Close to return to the sequence file when finished.

6. Select File»Close to close the sequence file to continue with the next
lesson.
End of Part C
End of Exercise 4-2

Exercise 4-3 Using Expressions to Change Step Properties

Objective: To modify the limit properties of a Numeric Limit step.
This exercise demonstrates how to modify properties of steps

programmatically. The property loader step type (which is covered in a later
exercise) is designed to load limits and properties from files and databases.
However, for illustrative purposes in this exercise, the limits are changed
manually using TestStand expressions.
Part A
1. Open and run Ex 4-3 Using Expressions to Change Step
Properties.seq. Notice that the Video Test always fails. This step
fails because the returned Measurement is outside the specified limits
of 15 and 19. Observe the report as shown below.
The measurement and limits are merely properties of each step.

Different types of steps have different properties. For example, Numeric
Limit steps such as the Video Test have measurement, high limit, and
low limit properties. As the sequence executes, the value of some of
these properties changes depending on what is passed back from code
modules.
2. Return to the sequence file window and right-click on the Video Test
step. Select Edit Limits from the menu. Observe the dialog box as
shown below, but do not change the limit settings. This is the dialog box

used to set the desired comparison type and the input limits used in the
comparison.
Click OK to close the Edit Numeric Limit Test dialog box.

3. Double-click on the Video Test step and select the Expressions tab.
The Expressions tab allows you to modify expressions before (Pre) and
after (Post) the step executes. This dialog box is shown below.

4. Place your cursor in the Pre Expression control. Click the Browse
button for the Pre Expression control (the top button). This opens the
expression browser, as shown below.
5. Click the + sign beside Step and notice that all Video Test step
properties are displayed. As shown below, you can use the expression
Step.Limits.Low to access the low limit of the Video Test step.
Click the + sign beside Limits to display the Low and High limit
properties as shown below. After selecting the Low property, click the
Insert button.

Place the cursor after Step.Limits.Low and enter = 2, to set the low
limit to a value of 2. Next you will specify the value for the high limit.
A comma is needed to separate multiple expressions, so be sure to
include it in the expression box after the first expression.

6. Click High and the Insert button again. Place your cursor after
Step.Limits.High and enter = 12 to set the high limits, as shown
below. Click OK to close the Expression Browser.

7. This expression is inserted in the Pre Expression box of the Step

Properties dialog box. Verify that it appears as shown below.
Click OK to return to the sequence file window. Run this sequence

using Single Pass again and notice that the Video Test step passes this
time because the limits are now set to 2 and 12.
End of Part A
Part B: Modifying Step Properties from Another Step

This section demonstrates how to change a step’s properties from another
step by modifying the Video Test step limits.
1. Double-click on the Video Test step and click on the Expressions tab.
Delete the entry Step.Limits.Low = 2, Step.Limits.High =
12 from the Pre Expression that was created in Part A.
2. Click OK to return to the sequence file. Run this sequence to ensure that
it fails as it did before.

3. Right-click on the RAM Test step and insert a new Statement step.
Statement steps are useful for manipulating expressions. Name this step
Modify Video Limits, as shown below.
4. Right-click on the Modify Video Limits step and select Edit

Expression from the menu. Click on the Browse button in the Edit
Statement Step dialog box that appears. Browse for
RunState.Sequence.Main [“Video Test”].Limits.Low and
click the Insert button. Place your cursor after
RunState.Sequence.Main[“Video Test”]. Limits.Low and
enter = 2, to set the low limit, as shown below.
Note Be sure to place the comma at the end of the input.

5. Go to RunState.Sequence.Main[“Video Test”].
Limits.High and click on Insert again. Place your cursor at the end
of that line and enter = 12. Click Check Syntax to make sure there are
no syntax errors and then click OK to return to the Edit Statement Step
dialog box and ensure that it appears as shown below.

Click OK to return to the Sequence File. Run the sequence file using
Single Pass to make sure that it works correctly. Close the sequence file
when finished with the exercise.
End of Part B
End of Exercise 4-3

Exercise 4-4 Passing Parameters

Objective: To use expressions and parameters in subsequence execution.
This exercise demonstrates two important ideas: how to use parameters for
passing information between calling sequences and subsequences, and how
to develop a sequence that executes subsequences according to user inputs
during run time. The sequence created involves steps that prompt an
operator for a CPU type and the number of CPUs to test. The CPU type is
then used during the sequence execution to execute one of two different
subsequences, and the number of CPUs is passed to the subsequence as a
parameter to set the number of times the test must be repeated.
Part A: Adding Steps to the Sequence

1. Navigate to C:\Exercises\TestStand I and open Ex 4-4
Passing Parameters.seq .
2. Before continuing with the exercise, click the Parameters tab. Use the
View Ring to select the AMDProcessor and INTELProcessor
sequences. Notice that the AMDProcessor sequence has two
parameters, and the INTELProcessor sequence has three parameters.
This exercise describes how to share data with these subsequences using
parameters and how TestStand uses default values if no data is specified
for a given parameter.
3. Right-click on the Powerup Test step and select Insert Step»Message
Popup from the context menu.
4. Rename the new step Select CPU Type.
5. Right-click on the new step and select Edit Message Settings from the
context menu.
6. Change the following control values on the Configure Message Box
Step dialog box:
Title Expression "Select CPU"
Message Expression "Please select the CPU Type for

the UUT."
Button 1 "INTEL CPU"
Button 2 "AMD CPU"
Cancel Button None

The Configure Message Box Setup dialog box should resemble the
following screen.
7. Click OK to close the Configure Message Box Step dialog box.

8. Right-click on the Select CPU Type step and select Properties from
the context menu.
9. Click the Expressions tab.

10. Click on the Browse button in the Post Expression. In the

Variables/Properties tab, right-click on Locals and select Insert String
as shown. Name the new variable CPUType.
11. Enter the remainder of the expression in the Post Expression control by
either using the Expression Browser or typing in directly:
Locals.CPUType = ((Step.Result.ButtonHit == 2)?
"AMD": "INTEL")

This expression assigns the string value "AMD" or "INTEL" to the local
variable, depending on which button the user clicks.
12. Click OK to close the properties dialog box.

13. Right-click on Select CPU Type step and select the Insert
Step»Message Popup command from the context menu.
14. Rename the new step Specify Number of CPUs.
15. Right-click on the new step and select the Edit Message Settings
command from the context menu.
16. Change the following control values on the Configure Message Box
Step dialog box as shown below:
Title Expression "Number of CPUs"
Message Expression "Please select the number of CPUs

installed for the UUT."
Button 1 "1"
Button 2 "2"
Button 3 "3"

Button 4 "4"
Cancel Button None
17. Click OK to close the Configure Message Box Step dialog box.
18. Right-click on the Specify Number of CPUs step and select the
Insert Step»Sequence Call command in the context menu.
19. Rename the step CPU Test.

20. Right-click on the new CPU Test step and select Specify Module from
the context menu.
21. Enable the Specify Expressions for Pathname and Sequence option.
This option allows an expression to determine the name of the sequence
file to be called. By default, TestStand expects the name and path of the
sequence file to be typed in, but by enabling this option, TestStand
evaluates an expression to determine the path and filename for the
sequence to be called at this step.
Also, enable the Use Current File option. This option specifies the
current sequence file as the location for the subsequence call to look.
Because both subsequences that can be called are in the same sequence
file as “MainSequence,” you should select this option. The only thing
that needs to be selected is the name of the Sequence to be called within
the sequence file.
22. Enter the following value for the Sequence Expression control:
Sequence Expression Locals.CPUType + "Processor"

23. Select the prototype for the sequence call by clicking the Load
Prototype button.
This option allows TestStand to look at the sequence file to be called and
determine whether any parameters must be passed into the sequence.
If there are parameters, using this option allows TestStand to determine

the number of parameters and their names. Exercise 3-3 demonstrated

how to create the parameter manually to pass into the subsequence call,
and this exercise uses the prototype to save time and prevent typing
mistakes.
24. Click the Browse button in the Load Sequence Prototype dialog box.
25. Navigate to C:\Exercises\TestStand I and open Ex 4-4
Passing Parameters.
26. Click OK to close the Select Sequence File dialog box.
27. Select the AMDProcessor sequence from the Load Sequence Prototype
dialog box for the Sequence Ring. Click OK to close this dialog box.
Notice that TestStand populates the Parameters section with the
parameter list for the sequence. This sequence requires two parameters
named CPUsInstalled and CPUFail. Now the location of the values
to be passed as parameters must be constructed.
28. Click on the CPUsInstalled parameter.
29. Select the Enter Expression option.
30. Enter the following expression into its string control or click Browse
and use the expression browser to create the expression:
RunState.Sequence.Main["Specify Number of CPUs"]
.Result.ButtonHit

31. Click on the CPUFail parameter.

32. Select the Enter Expression option.
33. Enter the following expression into its string control or click Browse
and use the expression browser to create the expression:
Locals.CPUFail

34. Click OK to close the dialog box. The value to be passed to the
subsequence has been assigned. The sequence can now decide which
subsequence to call and what values to pass to the subsequence as
parameters. Notice that because the value is passed using a parameter,
there is no need to create a file global or station global variable.
35. The finished sequence file should resemble the following screen.
Select File»Save to save the Ex 4-4 Passing Parameters.seq
sequence file.

End of Part A
Part B: Running a Sequence

Complete the following steps to run the sequence created in Part A.
1. Place a breakpoint on the CPU Test step by clicking to the left of the step
icon or by right-clicking on the step and selecting Toggle Breakpoint
from the context menu.
2. Select Execute»Single Pass.
3. Click Done in the Test Simulator prompt.
4. Click the INTEL CPU button in the Select CPU prompt.
5. Click the 2 button in the Number of CPUs prompt.
6. After the execution pauses at the breakpoint on the CPU Test step,
single-step into the subsequence by selecting Debug»Step Into. Notice
that the Call Stack pane lists INTELProcessor sequence at the bottom
of the sequence call stack, as shown below. The Call Stack shows the
sequences that have been called, with the most recently executed
sequence at the bottom.

7. Click on the Context tab and notice the values of the two parameters for
the sequence, as shown below.
The value of the CPUsInstalled parameter is equal to the value on the

button you clicked in the Specify Number of CPUs prompt. Notice that
MainSequence in the INTELProcessor.seq sequence file also
requires a ModelName parameter. The sequence call step that was
created did not specify this parameter, so the engine initializes the
parameter value to its default value.
8. Complete the execution by selecting Debug»Resume.
9. When execution completes, review the report to confirm that the correct
sequence file was called, but do not close the execution window.
10. Restart the execution by selecting Execute»Restart.

11. Click Done in the Test Simulator prompt.

12. Click the AMD CPU button in the Select CPU prompt.
13. Click the 3 button in the Number of CPUs prompt.
14. When the execution pauses at the breakpoint on the CPU Test step,
step into the subsequence by selecting Debug»Step Into.
Notice that the Call Stack pane lists AMDProcessor sequence at the
bottom of the call stack.
15. Complete the execution by selecting Debug»Resume, and review the
report.
16. Run the example a few more times and select other options. Each time,
notice that the parameter values are passed to the dynamically called
sequence file. Close the execution window and the sequence file window
when finished.
End of Part B
End of Exercise 4-4

Exercise 4-5 Dynamically Selecting Which Sequence to Run

Objective: To create a test that dynamically selects which sequence to run.
You will learn how to dynamically select a sequence file to run. Open the
sequence file C:\Exercises\TestStand I\Ex 4-5 Dynamically
Selecting Which Sequence to Run.seq. The MainSequence
contains three steps: Generic Processor, Intel Processor, and AMD
Processor. In this exercise your goals are to:
1. Add a step that asks the user to select the type of processor to test.
2. Make the necessary changes to ensure that the selected processor is
tested.
Hints:
Use a Message Popup step to ask the user which type of processor to test.
The Message Popup step stores the selected button in:
RunState.Sequence.Main[Name of the Message Popup
step].Result.ButtonHit.
As shown below, use the Preconditions expression of each step to

determine which step will execute.

Save and close the sequence.
End of Exercise 4-5

Notes

Notes

Lesson 5
Creating Test Modules
in External Environments
Lesson 5: Creating Test Modules in

External Environments
In this lesson, you will learn how:

• Data is passed between TestStand and external test
modules
• To create test modules in LabVIEW and
LabWindows/CVI
• To debug an external LabVIEW or LabWindows/CVI
code module from TestStand
• To modify code templates
Introduction
In this lesson, you will learn how to create test modules in external environments for use in
TestStand, and how data is transferred from TestStand to other environments. You will also
examine the LabVIEW and LabWindows/CVI test development environments, learn how to pass
data to TestStand from these environments, and debug these code modules directly from TestStand.

Lesson 5 Creating Test Modules in External Environments
Creating Tests in External Environments

• You can create tests in:
– LabVIEW
– LabWindows/CVI
– Any environment capable of creating a DLL,
EXE, ActiveX Automation server, or subroutine
• Each type of test uses a different adapter
which acts as an interface between
TestStand and another environment to:
– Execute test modules
– Step into test modules
– Generate code modules using templates
Creating Tests in External Environments

TestStand is a flexible testing environment that can call tests written in a wide variety of languages.
TestStand can call any test for which it has an adapter. An adapter is an interface that allows the
TestStand Engine to communicate with a specific programming language or file format. Currently,
TestStand has adapters for LabVIEW, LabWindows/CVI, Windows Dynamic Linked Libraries
(DLLs), ActiveX Automation servers and HTBasic subroutines. Additionally, you can call
Windows executable (.exe) files using a built-in step type. The following sections discuss how
you can create tests in LabVIEW and LabWindows/CVI.

Data Transfer in TestStand

There are three ways to pass data from a test
module to TestStand
Method 1—Passing parameters directly using
predefined structures
TestStand Data Space
Engine
Test
Module
Test
Error Data
• LabVIEW Adapter Data
• LabWindows/CVI Adapter

There are three ways to pass data between an external test module and TestStand:
• Pass parameters directly using predefined structures using LabVIEW and C/CVI Standard
Prototype Adapters
• Pass an arbitrary number of parameters using DLL Flexible Prototype Adapter, ActiveX
Automation Prototype Adapter, and Sequence Adapter
• Use ActiveX Automation API
Method 1—Passing Parameters Directly Using Predefined Structures

This method uses structures, which appear as either clusters in LabVIEW or structures in
text-based languages such as LabWindows/CVI. The most common structures are Test Data and
Test Error.
From the test module, data is passed into these structures. TestStand uses this information to
perform operations such as error handling or result collection. This is the same method used in
prior versions of the Test Executive Toolkits, making it possible for TestStand to call tests written
for either LabVIEW or LabWindows/CVI Test Executives with no modification. If you want to
pass additional parameters, you must use the ActiveX Automation API.
The next few slides discuss Method 1, followed by a quick discussion of Method 2, and concluding
with a discussion of Method 3.

Using Clusters to Pass Data from LabVIEW
Use LabVIEW type definitions

• Input buffer
• Invoke info
• Sequence
context
• Test data
Using Clusters to Pass Data from LabVIEW

The basic method for passing data is the same method used in previous versions of the Test
Executive Toolkits. TestStand automatically installs a set of type definitions in the LabVIEW
controls palette. These type definitions pass data between TestStand and the test VI. TestStand
automatically looks for these data structures (called clusters in LabVIEW) in the VI connector pane
when a step’s module is defined. Thus, passing data into or out of one of the type definitions makes
it available to the TestStand Engine.
The TestStand type definitions are explained below:
Input Buffer
Type: String Control
Purpose: To pass data into a VI. Data can be flattened into a string and then unflattened within
LabVIEW for compatibility with LabVIEW data types.

LabVIEW Type Definitions (Continued)
Invoke Info
Type: Cluster of Five Controls
• UUT Number: Integer
• Loop Number: Integer
• UUT Info: String
• Test Name: String
• Sequence Path: Path
Purpose: To provide basic information about the sequence and UUT to the test module.
Test Data
Type: Cluster of Four Indicators
• Pass/Fail Flag: Boolean
• Numeric Measurement: Double
• String Measurement: String
• Report Text: String
Purpose: To pass data from the test to the TestStand Engine. TestStand also automatically reads
data from a standard LabVIEW error cluster.

Using Structures to Pass Data from

LabWindows/CVI
Data is passed from LabWindows/CVI to
TestStand using a structure for Test Data and
Test Error
Test Data Test Error
Result Flag
Measurement Location
InBuffer Code
OutBuffer Message
ModPath
ModFile
SeqContextCVI
Additional Data
Using Structures to Pass Data from LabWindows/CVI

This method uses TestStand-defined structures to pass data between the TestStand Engine and
LabWindows/CVI.
The TestData structure contains the following parameters:

• Result—Pass/Fail Flag
• Measurement—Numeric datatype of type double used for numeric tests
• InBuffer—String passed in from TestStand (for compatibility)
• OutBuffer—String passed out by test function to TestStand (appears in the report)
• ModPath—Test module path
• ModFile—Test module filename
• SeqContextCVI—LabWindows/CVI Automation handle to the current context for the current
sequence

LabWindows/CVI Test Structures

(Continued)
The TestError structure contains the following parameters:

• Flag—Pass/Fail flag
• Code—Integer error code
• Message—Error message string
Bear in mind that the above structure is for reporting errors with the test system itself, not for test
failures related to the UUT.
In the following exercises, you will create a test in either LabVIEW or LabWindows/CVI using
structures to pass results to TestStand, and you will learn how to debug and step into the test directly
from TestStand.


Method 2—Passing parameters directly without
using structures
TestStand Data Space

Engine Data 1
Data 2
Test Module
Data Space
• Flexible DLL Adapter Data 1
• ActiveX Automation Adapter Data 2
• Sequence Adapter
Method 2—Passing Parameters Directly Without Using Structures

Method 2 also passes information into TestStand using parameters. Unlike the LabVIEW and
C/CVI Standard Prototype adapters, the DLL Flexible Prototype Adapter, ActiveX Automation
Prototype Adapter, and Sequence Adapter do not rely on structures to pass these parameters.
These three adapters can specify an arbitrary number of parameters that should be passed from the
code module back into TestStand. Although parameters are still being used to pass the data between
code modules and TestStand, this ability to specify an arbitrary number of parameters sets
Method 2 apart from the process described in Method 1.

Exercise 5-1A, 5-1B, or 5-1C

5-1A Objective: To create a pass/fail
test in LabVIEW and pass the test results to a
TestStand step using structures
5-1B Objective: To create a pass/fail test in
LabWindows/CVI and pass the test results to a
5-1C Objective: To create a pass/fail test in a DLL and
pass the result to a TestStand step using the DLL
Flexible Prototype Adapter


5-2A Objective: To create a numeric test in LabVIEW
and pass the test results to a TestStand step using
structures
5-2B Objective: To create a numeric test in
LabWindows/CVI and pass the test results to a
52-C Objective: To create a numeric test in a DLL called
with the DLL Flexible Prototype Adapter


5-3A Objective: To debug a LabVIEW test
5-3B Objective: To debug a LabWindows/CVI test
5-3C Objective: To debug a DLL test that is called with

the DLL Flexible Prototype Adapter


Method 3—Using the ActiveX Automation API to
access properties and methods
•Property: An attribute of the object that can be set
•Method: An action on the object that can be invoked
Test Module
TestStand ActiveX Object
TestStand Step
Properties
Engine Test
TestStand Program
Variables
•Any programming language that supports ActiveX
Method 3—Using the ActiveX Automation API to Access Properties and Methods
Another method to pass data between a test module and TestStand is to use ActiveX Automation.
ActiveX Automation is a standard method for passing data between Windows applications.
It allows one application to pass data to or control another application by changing its properties
and calling its methods. An ActiveX application can be thought of as an object used within another
environment.
A property is an attribute of the object that you can set or change.
A method is a function of the object that can be invoked.
Using ActiveX, an object of the sequence context can reside in the test module. When executing
sequences, TestStand maintains a sequence context that contains references to all global variables,
local variables, and step properties in active sequences. The contents of the sequence context
change depending on the currently executing sequence and step.
If you pass a sequence context object reference to the code module, you can use the TestStand
ActiveX API to access the variables and properties in the sequence context. By setting properties
and invoking methods, you can pass data between the test module and the TestStand sequence, and
set or change various TestStand attributes from within the test module itself.

What is ActiveX Automation?

• Microsoft technology for inter-application
communication
• Evolution of Object Linking and Embedding
(OLE) and part of Component Object Model
(COM) strategy
• Allows one application to control or pass data
to another application
What is ActiveX Automation?

ActiveX is a set of Microsoft technologies widely used for interapplication communication.
ActiveX gives you the freedom to share data between applications or control one application from
another, programmatically. It provides a standard interface and framework for communicating
between different applications. Rather than developing a particular functionality within an
application, you use ActiveX to leverage that functionality from another application.
In TestStand, the ActiveX API uses the Sequence Context object reference to pass the following
data:
• Type: ActiveX Automation reference handle.
• Purpose: You can wire this reference into a Set Property or Invoke Node to access TestStand
properties and methods pertaining to the sequence being executed (this topic is addressed in
greater detail later).

Summary of ActiveX Automation

• ActiveX servers export a set of properties
(variables) and methods (functions)
• ActiveX clients can access the properties and
methods from any server
ActiveX
Client
ActiveX
Client
Properties,
Methods
ActiveX
Server
Summary of ActiveX Automation

ActiveX applications can be either an ActiveX server or an ActiveX client. ActiveX servers are
applications that export an Application Programming Interface (API) or a set of properties and
methods to other applications. Think of properties as variables—their values can be read or set.
Methods are like functions—they perform a certain action when invoked. ActiveX clients are
programs capable of getting/setting properties and invoking methods of a server. Hence, ActiveX
clients can control the behavior and update the variables of the ActiveX server.

TestStand and ActiveX Automation

• The TestStand Engine Operator
Sequence Editor Interface
itself is an ActiveX
server (ActiveX Clients)
• The Sequence Editor
and operator interfaces TestStand Engine
are ActiveX clients (ActiveX Server)
• In addition, test
modules can also be
ActiveX clients (to
LV CVI VB
access properties and Test Test Test
methods of the engine)
(ActiveX Clients)
TestStand and ActiveX Automation

The TestStand Engine is an ActiveX server, which exports an ActiveX Application Programming
Interface (API). The Sequence Editor and operator interfaces can create, edit, execute, and debug
sequences.
In addition, test modules can also access the TestStand Engine ActiveX API to get/set the values
of TestStand variables or to invoke certain methods.
An example of a TestStand property is the value of a local or global variable. These values are
maintained by the TestStand Engine, but can be accessed by an Operator Interface, Sequence
Editor, or code module. Some examples of TestStand methods are (DisplayLoginDialog) and
(UnloadAllModules), which ActiveX clients can call the TestStand Engine to execute.

ActiveX Automation in LabVIEW

• TestStand installs a palette
of ActiveX VIs
• These VIs access common
TestStand properties
• For all other properties and
methods (used for creating
advanced applications or a
custom user interface), use
the LabVIEW property and
invoke nodes
ActiveX Automation in LabVIEW

TestStand installs a palette of VIs for accessing common TestStand properties, including getting or
setting the value of any TestStand numeric, string, Boolean, or array. All other TestStand properties
and methods are accessible using the LabVIEW Invoke Node and Property Node, in the
Communication»ActiveX subpalette. You can find additional information on the LabVIEW
ActiveX capability in the G Programming Reference Manual.
Note To use TestStand 2.0 VIs with LabVIEW, you must have LabVIEW 5.1 or later.

An Example of ActiveX Automation in LabVIEW
An Example of ActiveX Automation in LabVIEW

This slide is an example of using ActiveX Automation within LabVIEW to get and set the value of
TestStand variables. The ActiveX Automation handle, Sequence Context, is a refnum passed to the
VI from TestStand. It gives the VI a reference to the TestStand sequence that called it. The first
subVI, Get Property Value, gets the value of a TestStand local variable, in this case a Boolean
variable named Instrument State. The second subVI, Set Property Value, sets the value of a
subproperty of the step that called this code module. The subproperty in this case is a numeric value
named Numeric.

ActiveX Automation in LabWindows/CVI

TestStand API instrument driver
• TestStand provides a LabWindows/CVI instrument
driver to access TestStand properties and methods
• The instrument driver is a LabWindows/CVI function
panel
• TestStand properties and methods are set by calling
the appropriate functions from within
LabWindows/CVI
ActiveX Automation in LabWindows/CVI

The instrument driver is a set of function panels and modules containing functions for accessing
all TestStand properties and methods. Remember that when you are in the LabWindows/CVI
environment, you may need functions from the LabWindows/CVI ActiveX Automation library to
convert data types returned from the TestStand instrument driver.
It is also important to remember that by using ActiveX Automation, you have access to not only
the data relevant to the specific code contained within a test, but also to many of the TestStand
environment attributes and functions, thereby allowing changes to sequence information during
run-time.

An Example of ActiveX Automation in LabWindows/CVI
An Example ActiveX Automation in In LabWindows/CVI

This slide shows an example of a LabWindows/CVI function panel for the
PropertySetValNumber function. It takes in a LabWindows/CVI sequence context (passed by
the TestStand step that calls the module), a Lookup String, and a New Numeric Value. This
example sets the value of the local variable Num1 to 5.0.
In the next set of exercises, you will use ActiveX to pass data within either LabVIEW or
LabWindows/CVI.


5-4A Objective: To use ActiveX in LabVIEW test
modules to pass data to TestStand
5-4B Objective: To use ActiveX in LabWindows/CVI test
modules to pass data to TestStand
5-4C Objective: To use the ActiveX API to pass data
from DLLs called with the DLL Flexible Prototype
Adapter to TestStand

Exercise 5-5A or 5-5B

5-5A Objective: To write a simple Numeric Limit Test
that uses the LabVIEW Standard Prototype Adapter
5-5B Objective: To write a simple Numeric Limit Test

that uses the C/CVI Standard Prototype Adapter

Exercise 5-6A or 5-6B

5-6A Objective: To use the TestStand API to pass data
between TestStand and LabVIEW
5-6B Objective: To use the TestStand API to pass data

between TestStand and LabWindows/CVI

Exercise 5-7
5-7 Objective: To pass data between TestStand and
your test module using the DLL Flexible Prototype
Adapter

Using TestStand Code Templates

• TestStand allows test developers to create
code in an external environment from within
the Sequence Editor
• Each adapter and step type has an
associated code template:
– Use the code template to create default
test code
– Use TestStand’s Create Code feature to eliminate
redundant programming
Using TestStand Code Templates

Another powerful feature of TestStand is the ability to create tests in LabVIEW or
LabWindows/CVI from within the TestStand Sequence Editor. Selecting the Create Code option
in the Specify Module dialog box creates code using a default code template for the respective
programming environment. TestStand even allows you to customize this template to include any
necessary code for each test of a certain type, or you might associate a number of templates with
each step type. If you define more than one template for a step type, TestStand prompts you to
choose one from a list when you select Create Code. This feature allows you to develop your test
sequences in an efficient and consistent way.

Code Templates
• Code templates are
configured through
the step type
properties found in
the Type Palette
• Code template code
is stored in the
TestStand\Code
Templates directory
Code Templates
Code templates are created and configured from the Code Templates tab of the step type
properties dialog box in the TestStand Type Palette. The lesson on TestStand types later in this
course discusses customizing step types and the Type Palette in detail. The actual code for each
template is in the TestStand\Code Templates directory.

Lesson 5 Summary: Creating Test

Modules in External Environments
• There are three ways to pass data between
the TestStand Engine and test modules:
– Using predefined structures
– Passing arbitrary number of parameters
– Using the ActiveX Automation API exported by the
TestStand Engine
• TestStand eliminates redundant programming
by allowing users to specify default code
based on code templates
Summary
In the previous lesson, you learned how to share data between sequence steps (locals), multiple
sequences (sequence globals), and sequence files (station globals). In this lesson, you learned how
to share data between TestStand and test modules developed in another programming environment.
You can use structures, as used in National Instruments Test Executive Toolkits, you can use an
arbitrary number of parameters, or you can leverage the ActiveX capabilities of the engine (server)
and development environments such as LabVIEW, LabWindows/CVI, or Visual Basic (clients).
The first two options are dependent on which Adapter you chose to call the code module. The last
option depends upon how you write the code module itself.
TestStand also includes a method to reduce redundant programming. Using code templates, test
module developers can duplicate common components used throughout their test modules.
Note If you are using either LabWindows/CVI or LabVIEW, you can use National
Instruments IVI driver technology to perform test software development without
requiring instrumentation hardware. This instrument driver technology provides features
such as state caching, simulation, and an attribute model for convenient test development.
For more information about IVI, refer to Appendix A.

Lesson 5 Creating Test Modules in External Environments Exercises
Exercise 5-1A Creating Pass/Fail Tests in LabVIEW

Objective: To create a pass/fail test in LabVIEW and pass the results to a TestStand step.
It is important to understand the different types of tests you can create in

TestStand. Previous lessons have shown how to link specific code modules
to each step and create steps that call different types of code modules. This
exercise shows how to create one particular type of test called a Pass/Fail
test. You will create a VI that simulates the Keyboard Diagnostic test. The
VI displays a message popup when it executes.
This exercise also demonstrates another of TestStand’s powerful and

unique abilities. Previous exercises have shown that TestStand can use
code modules written in a variety of languages. However, this exercise
shows that TestStand can create some of the code for these code modules
using templates. Currently, TestStand can create code in LabVIEW and
LabWindows/CVI. This code contains only the minimum code required for
TestStand to interact successfully with the code module. The generated
code modules serve as starting points for users to add their specific code
when generating their customized test modules.
Part A: Creating the LabVIEW Test

1. Select File»Open from the Sequence Editor and open
C:Exercises\TestStand I\Ex 5-1A Creating PassFail
Tests with LabVIEW.seq. This sequence is similar to the one used
in previous exercises, except that it is missing the Keyboard
Diagnostics step. The rest of this exercise describes how to create this
step.
2. Be sure the LabVIEW Standard Prototype Adapter is selected in the
Adapter Selector Ring, as shown below.
In the sequence window, right-click below the existing steps and select
Insert Step»Tests»Pass/Fail Test. This inserts a Pass/Fail step for the
LabVIEW Adapter at the bottom of the sequence. Name the test
Keyboard Diagnostics.
3. Right-click on the step and select Specify Module. This brings up the
LabVIEW Step Module Information dialog box. For the VI Pathname,
click the Browse button, type in the VI name Ex 5-1A Keyboard

Diagnostics.vi, and select the C:\Exercises\TestStand I

\VIs directory. Notice that the search returns File not found. This is
because the VI for this module is not yet created. The resulting screen
should appear as shown.
4. Check Show VI Front Panel When Called. Click the Create VI…
button. When prompted for the pathname, be sure that the
C:\Exercises\TestStand I\VIs\ directory is selected and then
click OK to confirm that the VI should be created in the VIs
subdirectory.

A useful method to store the paths to code resources is relative to the

sequence file. Relative paths are preferred so that if the files are ever
moved, the code modules can still be found as long as they are all moved
together. For example, this situation happens frequently when the test
sequence is moved from the development machine to the testing
machine, where drive names and directory structures could be
completely different.
At this point, LabVIEW is launched and a VI created using the code
template for the Pass/Fail step type. The VI is named Ex 5-1A
Keyboard Diagnostics.vi.
Ex 5-1A Keyboard Diagnostics.vi outputs a standard error cluster
containing runtime error information.
The Test Data cluster returns information about the test status itself.
If the test module passes or fails, this information is returned in the
Boolean element of the Test Data cluster. The Test Data cluster
contains a Boolean value, a numeric value, and a string value. One of
these three values is used to check the results of this test, depending on
what step type is used to call this code module. In this case, the Pass/Fail
step type was chosen so that the Boolean value is checked. The block
diagram on the following page shows how to wire the Boolean value into
this cluster. The last control in this cluster is the Report Text. A string
can be passed out of this control for information to be displayed in the
report. This information can be helpful in the report to help the operator
determine why a test passed or failed.
5. These controls are also wired to the connector pane when using the
Create VI option. Test Data is wired to the upper terminal and error out
is wired to the lower terminal, as shown.

6. Build the block diagram as shown.

The One button Dialog VI is in the Functions»Time and Dialog
subpalette. Create a string constant and type in the message as displayed.
TestStand - Create Test Data Cluster.vi should already be in the
diagram; if not, it is in the Functions»User Libraries»TestStand
subpalette.

7. Save the VI as Ex 5-1A KeyBoard Diagnostics.vi.
End of Part A
Part B: Configuring the Step Properties

1. Now that you have created the step and added the code, all that remains
is to add the proper precondition to this step. The Keyboard Diagnostics
step should execute only if the Keyboard step fails and the Powerup and
CPU test have passed. Double-click on the Keyboard Diagnostics step
to open the Keyboard Diagnostics Pass Fail Test Properties dialog box.
Click the Preconditions button. Set the preconditions as shown below.
a. Click Powerup Test in the Insert Step Status section.
b. Click Insert Step Pass.
c. Click CPU Test.
d. Click Insert Step Pass again.
e. When prompted to insert AllOf or AnyOf, choose AllOf.
f. Click Keyboard Test.
g. Click Insert Step Fail.

h. Click OK to complete setting the precondition for this new step.

2. Execute the sequence by selecting Execute»Test UUTs or clicking the
Test UUTs button in the toolbar. When you select the Keyboard Test to
Fail, a dialog box appears. Click OK to continue with the execution.
3. When finished with the exercise, save the sequence file and close the
sequence file window.
End of Part B
Part C: Using LabVIEW DLL

You have just finished configuring a Pass/Fail step that uses a VI as the code
module. LabVIEW provides the added capability of building a VI into a
dynamic link library (DLL). In Part C, you will make use of this capability
and use TestStand’s DLL Flexible Prototype Adapter to call that DLL.
Recall that previously in this exercise you were using the LabVIEW
Standard Prototype Adapter to call VIs from TestStand.
1. You will use the VI that you have created earlier in this exercise and
build it into a DLL. Open a new VI in LabVIEW. Select Tools»Build
Application or Shared Library (DLL)… to open the Build
Application or Shared Library (DLL) - New script dialog box.

2. On the Target tab within the New script dialog box, specify the name to
give to the DLL and its location.
a. Change the Build target to Shared Library (DLL).
b. Change Target file name to Ex 5-1A Keyboard Diag.dll.
c. Rename Destination directory to C:\Exercises\Teststand I
\VIs. When you build the DLL, it will be placed in this directory.
Note that when you change directories, the Support file directory
field is automatically updated to C:Exercises\Teststand I
\VIs\data.
d. Leave other options set to default. Note that under Build Options,
the default selection is to create Single target file containing
all VIs.
3. The resulting New script dialog box should resemble the following
image.

4. Select the Source Files tab in the New script dialog box. Here, you need
to specify the name of the VI that is to be used to build the DLL. Click
on Add Exported VI to bring up the file selection dialog window.
Browse to C:\Exercises\Teststand I\VIs directory and select
Ex 5-1A Keyboard Diagnostics.vi. Note that as soon as you
make the selection by clicking Open from the file dialog window,
LabVIEW brings up the Define VI Prototype dialog box.
5. In the Function Name text field, enter KeyboardDiagnostics. This is
the name that will be given to the function that will contain the code for
Ex 5-1A Keyboard Diagnostics.vi in the DLL.
6. Note that the default calling convention is set to C Calling
Conventions. The VI does not have any input parameters but it does
have output values. To specify the error out and TestData outputs, click
the “+” button next to the Parameters listbox. Select error out from the
VI Output selector for the first output parameter. Click the “+” button
again to add the TestData output parameter. The Define VI Prototype
dialog should now appear as shown.

7. Select OK to complete defining the function prototype. This takes you

back to the the Source Files tab in the New script dialog box.
8. You are now ready to build the DLL. Select Build. This shows the
progress bar and when complete it will indicate Build finished! Three
files are created: Ex 5-1A Keyboard Diag.dll, Ex 5-1A
Keyboard Diag.h, and Ex 5-1A Keyboard Diag.lib.
Note If this is the second time you are creating a DLL in the same location, you will
receive a message indicating that the previously created DLLs and its supporting files
will be overwritten. At this point you can either continue and overwrite existing files or
cancel the build operation.
9. Launch the TestStand Sequence Editor. Select File»Open to open the

following sequence file: C:\Exercises\Teststand I\Ex 5-1A
Creating PassFail Tests with LabVIEW (Part C).seq. This
sequence file already contains the Keyboard Diagnostics Pass/Fail step
using the DLL Flexible Prototype Adapter.
You are now going to configure the Keyboard Diagnostics step so that it
calls the DLL function that we have just built using LabVIEW.
10. Right-click on the Keyboard Diagnostics step and select Specify
Module… to display the Edit DLL Call dialog box.
a. For DLL Pathname, browse and select
C:\Exercises\Teststand I\VIs\Ex 5-1A Keyboard
Diag.dll.
b. For Function Name, select KeyboardDiagnostics from the pull
down list.

c. Select C(cdec1) for the Calling Convention.

d. Add the error out parameter by selecting the New button. Type
Error Out for the parameter name, Specify Locals.Error for
the Value Expression. Choose C Struct for the Category. Select
CustomError for the Struct Type. The dialog should appear as
follows.
e. Add the TestData parameter by selecting the New button. Type in

testData for the parameter name. Specify Locals.TestData for
the Value Expression. Choose C Struct for the Category. Select
TestData for the Struct Type. The dialog box should appear as
follows.

Note When using the C Struct category you must have the corresponding data structure
defined within the TestStand environment and have the Allow Objects of This Type to
be Passed as Structs data type property enabled. This was already taken care of for this
exercise. For more information regarding C Structs as parameters, please see the
TestStand User Manual.
11. Select OK. Execute the sequence by selecting Execute»Test UUTs.

When you select the Keyboard Test to Fail, a dialog box should appear.
Select OK to continue with the execution.
12. When finished with the exercise, save the sequence file and close the
End of Part C

Exercise 5-1B Creating Pass/Fail Tests with LabWindows/CVI

Objective: To create a pass/fail test in LabWindows/CVI and pass the results to a
TestStand step.

TestStand. Previous lessons have shown how to link specific code modules
to each step and create steps that call different types of code modules. This
exercise shows how to create one particular type of test called a pass/fail
test. You will create a function that simulates the Keyboard Diagnostic test.
The function displays a message popup when it executes.
This exercise also demonstrates another of TestStand’s powerful and unique

abilities. Previous exercises have shown that TestStand can use code
modules written in a variety of languages. However, this exercise shows that
TestStand can create some of the code for these code modules using
templates. Currently, TestStand can create code in LabVIEW and
LabWindows/CVI. This code contains only the minimum code required for
TestStand to interact successfully with the code module. The generated code
modules serve as starting points for users to add their specific code when
generating their customized test modules.
Part A: Creating the LabWindows/CVI Test Module

1. Launch the Sequence Editor. Select File»Open and select the sequence
file C:Exercises\TestStand I\Ex 5-1B Creating PassFail
Tests with CVI.seq. This sequence is the same as one that has been
used in previous exercises, except that it is missing the Keyboard
Diagnostics step. In the rest of this exercise, you will create this step.
2. Add a new step to the bottom of Main Sequence.
Make sure the C/CVI Standard Prototype Adapter is selected in the
Adapter Selection Ring.

Right-click below the steps of the sequence and select Insert

Step»Tests»Pass/Fail Test. This inserts a Pass/Fail test for the
LabWindows/CVI Standard Prototype Adapter with the default name
Pass/Fail Test at the bottom of the sequence.
3. Name the step Keyboard Diagnostics. Right-click on the step

and select Specify Module. This brings up the LabWindows/CVI Step
Module Information dialog box, as shown below. Notice that you can
call code module types compiled into DLLs, static libraries, or object
files. In addition, you can specify *.c files that use a special
LabWindows/CVI project file to compile the code dynamically for
use by TestStand. Set the Module Type ring to Object File (*.obj).
For the Module Pathname, type in CVI Project Files\Keyboard
Diagnostics.obj. For the Function Name, type in
KeyboardDiagnostics. Make sure that Standard Prototype is
selected. Notice that the search returns File not Found. This is because
the code for this module is not created yet. The resulting screen should
appear as shown below.
4. Click on the Source Code tab. For the Pathname of Source File
Containing Function, type in CVI Project Files\Keyboard
Diagnostics.c. For the Pathname of CVI Project File to Open,
type in CVI Project Files\Keyboard Diagnostics.prj.
Notice that the source code file and project file do not yet exist. This
exercise will show how to create these files. Click on Create Code.

When prompted, click OK to confirm that the project file should be

created in the C:\Exercises\TestStand I\CVI Project Files
subdirectory. Make sure this subdirectory is selected; if not, select this
directory before clicking OK.

5. Save the source code file in the \CVI Project Files\ directory
where the Keyboard Diagnostics.prj is located.
This launches LabWindows/CVI and creates a source file (.c) named

Keyboard Diagnostics.c. Inside this source file is the template for
the function that must be created, called KeyboardDiagnostics.
6. Make a simulation for the keyboard diagnostic.

For this exercise, create a test with a Message Popup that displays the
message “This is the Keyboard Diagnostic Test” when this test runs. You
created most of this code earlier by clicking on the Create Code button.

After the line int error = 0; add the KeyboardDiagnostic test using
the MessagePopup function panel and the parameters shown below:
MessagePopup ("Message Popup", "This is the keyboard
diagnostic test");
After the line Error:, type in the error information as shown below:
testError->errorFlag=FALSE;
testData->result = PASS;
The C/CVI test functions use two pointers to structures to pass data
between TestStand and the test functions. In the KeyboardDiagnostics
test, testError->errorFlag is set, which indicates whether a
run-time error occurred. The other structure, testData->result,
indicates whether the Unit Under Test passed or failed the test. The
resulting screen should appear as shown below.
Save the source file. The name Keyboard Diagnostics.c should

already be selected.
7. The source code file should have been added to the project file
automatically. If not, add Keyboard Diagnostics.c to the project by
selecting File»Add File to Project from the Keyboard
Diagnostics.c window.

8. Create an object file from Keyboard Diagnostics.c by selecting

Options»Create Object File from the Keyboard Diagnostics.c
window. Click OK to create the object file for the Current Compatibility
Mode.
9. Save and close the source and project file and exit LabWindows/CVI.
End of Part A

1. In the TestStand Sequence Editor, click OK to exit the Edit C/CVI
Module Call dialog box.
2. Remember that the Keyboard Diagnostics step should execute only
if the Keyboard Test step fails and the Powerup Test and CPU
Test steps have passed. Double-click on the Keyboard
Diagnostics step to open the Keyboard Diagnostics PassFailTest
Properties dialog box. Click the Preconditions button. Set the
preconditions as shown below.
c. Click CPU Test.
e. When prompted to insert AllOf or AnyOf, choose Insert AllOf.


3. Click OK to exit the Preconditions dialog box. Then, click OK to exit

the Properties window.
4. Save the sequence as C:\Exercises\TestStand I\Ex 5-1B

Creating PassFail Tests in CVI.seq. Execute the sequence by
selecting Execute»Test UUTs or by pressing the Test UUTs button in
the toolbar. Notice that when the Keyboard Test is selected to fail, a
message popup is displayed. Click OK to continue with the execution.
End of Part B
Part C: Create a DLL Code Module for the Keyboard Diagnostic Test
1. National Instruments recommends using DLL files rather than object
files for test modules. Using LabWindows/CVI, open
C:\Exercises\TestStand I\CVI Project Files\Keyboard
Diagnostics.prj if you closed it before.
2. From the LabWindows/CVI project window, ensure that the project
target is set for Dynamic Link Library under the Build»Target Type
menu.

3. Ensure that the DLL to be built is configured as a release version of the

DLL by selecting Build»Configuration»Release.
4. Confirm the DLL target settings by selecting Build»Target Settings.
Make certain the settings match those in the figure below.
5. Verify which functions LabWindows/CVI exports by clicking the

Change button in the Exports area. Be sure to select Symbols Marked
for Export, as shown.
6. The KeyboardDiagnostics function is marked for export with the

dllexport definition. Click OK to close the DLL Export Options
window. To close the Target Settings window, click OK again.
7. Create a DLL by selecting Build»Create Release Dynamic Link
Library.
8. In the Sequence Editor, right-click on the Keyboard Diagnostics

step and select Specify Module. Change the Module Type ring to

Dynamic Link Library (*.dll). Notice that the extension is changed

automatically, and TestStand also finds the newly created Keyboard
Diagnostics.dll.
9. Click OK to leave the Edit C/CVI Module Call dialog box. Execute the
sequence to verify that it behaves the same as when using an object file.
10. Note that if you try to rebuild the DLL while an application such as the
Sequence Editor is using it, you will get a “file access permission
denied” error. In the Sequence Editor, select File»Unload All Modules
to unload the DLL, allowing you to rebuild it if necessary.
11. When finished with the exercise, save and close the sequence file.
Save all files and quit LabWindows/CVI.
End of Part C

Exercise 5-1C Creating Pass/Fail Tests for the DLL Flexible

Prototype Adapter
Objective: To create a pass/fail test in a DLL and pass the result to a TestStand step using the
DLL Flexible Prototype Adapter.

TestStand. Previous lessons have shown you how to link specific code
modules to each step and create steps that call different types of code
modules. This exercise shows you how to create one particular type of test
called a pass/fail test. You will create a function that simulates the Keyboard
Diagnostic test. The function displays a message popup when it executes.
This exercise also demonstrates another of TestStand’s powerful and unique

abilities. Previous exercises have shown that TestStand can use code
modules written in a variety of languages. This exercise shows that
TestStand can create some of the code for these code modules using
templates. Currently, TestStand can create code in LabVIEW and
LabWindows/CVI. The code that TestStand creates contains only the
minimum code required for TestStand to interact successfully with the code
module. The generated code modules serve as starting points for users to
add their specific code to when they create their customized test modules.
Part A: Creating the Test Module

file C:\Exercises\TestStand I\Ex 5-1C Creating PassFail
Tests with DLL Adapter.seq. This sequence is the same as one
that has been used in previous exercises, except that it is missing the
Keyboard Diagnostics step. In the rest of this exercise, you will
create this step.
2. Select the DLL Flexible Prototype Adapter and insert a new step at the
bottom of the MainSequence.
Right-click below the steps of the sequence and select Insert

Step»Tests»Pass/Fail Test as shown below. This inserts a Pass/Fail
Test that uses the DLL Flexible Prototype Adapter with the
default name Pass/Fail Test at the bottom of the sequence.
3. Name the step Keyboard Diagnostics. Right-click the step and

select Specify Module. This displays the Edit DLL Call dialog box, as
shown below. For DLL Pathname, type in CVI Project Files\Ex
5-1C Keyboard Diagnostics.dll. For the Function Name, type
in KeyboardDiagnostics. Notice that the search for DLL Pathname
returns File not found. This is because the code for this module is not
created yet. The resulting screen should appear as shown.

4. Click the Source Code tab. For the Pathname of Source File
Containing Function, type in CVI Project Files\Ex 5-1C
Keyboard Diagnostics.c. Notice that the source code file does not
yet exist. To create the source code file, click Create Code. The
following dialog box appears.

Click OK to confirm that the source file should be created in the

C:\Exercises\TestStand I\CVI Project Files\
subdirectory. If this directory is not selected, navigate to this directory
before clicking OK.
You may be prompted to set the path reference. A useful method to store
the paths to code resources is relative to the sequence file, so select the
option Use a relative path for the file you selected.
Relative paths are preferred so that if the files are ever moved, the code
modules can still be found as long as the files are moved together. For
example, this situation happens frequently when the test sequence is
moved from the development machine to the testing machine, where
drive names and directory structures could be completely different.
5. TestStand will prompt you to choose a code template. Select
TestStand pass/fail template and press OK. A code template
is a source file that contains skeleton code. The skeleton code serves as
a starting point for the development of code modules for steps that use
the step type.
This launches LabWindows/CVI and creates a source file (.c) named

Ex 5-1C Keyboard Diagnostics.c. The source file contains the
Keyboard Diagnostics function that you created.
If you get a dialog box asking you to open the created file in Notepad,
click No.
6. Open LabWindows/CVI if it is not already open. Select File»Open»
Project and open the project file C:\Exercises\TestStand I\CVI
Project Files\Ex 5-1C Keyboard Diagnostics.prj.
If prompted, click Yes to unload the current project and OK to transfer
the project options.
7. In the Ex 5-1C Keyboard Diagnostics.prj window, you should
see that Ex 5-1C Keyboard Diagnostics.c is already included in
the project. If it displays File not found, highlight Ex 5-1C Keyboard
Diagnostics.c and select, Edit»Remove File. Then select

Edit»Add Files to Project»Source and add the source file

C:\Exercises\TestStand I\CVI Project Files\Ex 5-1C
Keyboard Diagnostics.c. Click the OK button to add this file to
the project.
8. In the LabWindows/CVI Project window, double-click Ex 5-1C
Keyboard Diagnostics.c to open the source code window as shown
below.
9. Make a simulation for the keyboard diagnostic.

For this exercise, create a test with a Message Popup that displays the
message “This is the Keyboard Diagnostic Test” when this
test runs. You created most of this code earlier by clicking on the Create
Code button.
After the line int error = 0; use the MessagePopup function panel
to insert the following code:
MessagePopup ("Message Popup", "This is the keyboard
diagnostic test");
*result = PASS;
After the line Error: type in the error information as shown below:
*errorOccurred = FALSE;

The DLL test function uses pointers to pass data between TestStand
and the test function. In the KeyboardDiagnostics test,
*errorOccurred is set, which indicates whether a run-time error
occurred. The other pointer, *result, indicates whether the Unit
Under Test passed or failed the test. The resulting screen should appear
as shown below.
10. Save the source code file then close it.
11. In the project window, ensure that the project target is set for Dynamic
Link Library under the Build»Target Type menu.
12. Ensure that the DLL to be built is configured as a release version of the
DLL by selecting Build»Configuration»Release.



for Export, as shown below.
15. The KeyboardDiagnostics function is marked for export with the

dllexport definition. Click OK to close the DLL Export Options
window. To close the Target Settings window, click OK again.
16. Create a DLL by selecting Build»Create Release Dynamic Link
Library.

End of Part A

1. Return to the sequence editor. Notice that in all of the pathname dialogs,
the modules are now found in the proper directories, because they have
been created. Click OK to exit the Edit DLL Module Call dialog box.
2. The Keyboard Diagnostics step should execute only if the
Keyboard Test step fails and the Powerup Test and CPU Test
steps have passed. Double-click on the Keyboard Diagnostics
step. Click the Preconditions button. Set the preconditions as shown
below.
c. Click CPU Test.


3. Click OK to exit the Preconditions dialog box. Click OK again to exit

the Step Properties dialog box.
4. Save the sequence as C:\Exercises\TestStand I\Ex 5-1C
Creating PassFail Tests with DLL Adapter.seq. Execute
the sequence by selecting Execute»Test UUTs or by pressing the Test
UUTs button in the toolbar. Notice that when the Keyboard Test is
selected to fail, a message popup is displayed. Click OK to continue.
Click Stop to end the execution.
End of Part B
End of Exercise 5-1C

Exercise 5-2A Creating Numeric Limit Tests with LabVIEW

Objective: To create a code module for a numeric limit test that simulates a video
diagnostic test.
This exercise shows how to create another type of test in TestStand called a
numeric limit test. Additionally, it demonstrates one way to add
information to the test report. The code module passes numeric data and a
Report Text string back to TestStand. TestStand compares the numeric data
to predefined limits and determines whether the test passed or failed. The
Report Text string is displayed in the report.
Part A: Creating the LabVIEW Test

1. Launch the Sequence Editor. Select File»Open from the Sequence
Editor and navigate to C:Exercises\TestStand I\. Open Ex 5-2A
Creating Numeric Limits Tests with LabVIEW.seq. This
sequence file is the same as ones used in previous exercises, except it is
missing the Video Diagnostics step. The rest of this lesson describes the
procedure to create this step.
2. Make sure the LabVIEW Standard Prototype Adapter is selected in
the Adapter Selector Ring.
3. Right-click on the RAM Diagnostics step and select Insert

Step»Tests»Numeric Limit Test. This inserts a Numeric Limit Test
for the LabVIEW Standard Prototype Adapter between the RAM
Diagnostics step and the Keyboard Diagnostics step. Name this step
Video Diagnostics.
4. This exercise describes how to create a LabVIEW test that returns a
random numeric value and a Report Text string. The default limits of 0
for minimum and 10 for maximum are used to evaluate the pass/fail
conditions based on the numeric measurement returned from the test. To

view the limits, right-click on the step and select the Edit Limits option.
Click OK to return to the sequence file.
5. Right-click on the new Video Diagnostics step and select Specify

Module. Type in VIs\VideoDiagnostics.vi. The screen should
appear as follows.

6. You must create the code for this VI, so click on Create VI. When
prompted for the directory to save in, select C:\Exercises\
TestStand I\VIs (if not already selected) and click OK to continue.
Then select a relative path when TestStand asks how to store the path,
just as in Exercise 5-1A. VideoDiagnostics.vi already contains the
TestData and Error Out clusters. These clusters contain information that
TestStand passes to the step properties, so you can now build the block
diagram for this module.

Open the block diagram and build the diagram as shown.
The False case of the case structure appears as shown below.
7. This simulated test generates a random number between 0 and 30 by

multiplying the output of the random number generator (which produces
a number between 0 and 1) by 30. The random number is then passed
into the Numeric Measurement terminal of the TestData Cluster VI. In
TestStand, this value is compared to 10; if it is greater than 10, a string
is sent to the Report Text terminal in the Test Data Cluster VI.
8. Save the VI in C:\Exercises\TestStand I\Vis as
VideoDiagnostics.vi.
9. Close the VI to return to the Sequence Editor and click OK to exit the
Specify Module dialog box.
End of Part A

1. The Video Diagnostics step should now appear in the sequence between
the RAM Diagnostics step and the Keyboard Diagnostics step.
2. The Video Diagnostics step should execute only if the Video step fails
and the Powerup Test and CPU Test have passed. Double-click on the

Video Diagnostics step to open the Video Diagnostics

NumericLimitTest Properties dialog box. Click the Preconditions
button. Set the preconditions as shown below.
c. Click CPU Test.
e. When prompted to insert AllOf or AnyOf, choose AllOf.
f. Click Video Test.
3. Save the sequence in the C:\Exercises\TestStand I directory as

Ex 5-2A Creating Numeric Limit Tests with
LabVIEW.seq. Execute the sequence by selecting Execute»Single
Pass. Select the video test to fail.

4. When the report is generated, scroll down the report and observe that the
video test is reported as having failed (as you have selected). Continue
scrolling down and note the status of the Video Diagnostics step. Notice
the measurement value returned— it should fall between 0 and 30.
Observe the Report Text string returned from the code module if the
value is greater than 10.
End of Part B
Part C: Using LabVIEW DLL (Optional)

You have just finished configuring a Pass/Fail step that uses a VI as the code
module. LabVIEW provides the added capability of building a VI into a
dynamic link library (DLL). In Part C, you will make use of this capability
and use TestStand’s DLL Flexible Prototype Adapter to call that DLL.
Recall that previously in this exercise you were using the LabVIEW
Standard Prototype Adapter to call VIs from TestStand.
1. You will use the VI that you have created earlier in this exercise and
build it into a DLL. Open a new VI in LabVIEW. Select Tools»Build
Application or Shared Library (DLL) to open the ‘Build Application
or Shared Library (DLL) - New script’ window.
2. On the Target tab within the New script dialog box, specify the name to
give to the DLL and its location.
a. Change the Build target to Shared Library (DLL).
b. Change Target file name to Ex 5-2A Video Diag.dll.

c. Rename Destination directory to C:\Exercises\Teststand I

\VIs. When you build the DLL, it will be placed in this directory.
Note that when you change the directory, the Support file directory
field is automatically updated to C:\Exercises\Teststand I
\VIs\data.
d. Leave other options set to default. Note that under Build Options,
the default selection is to create Single target file containing
all VIs.
3. The resulting New script dialog box should resemble the following
image.
4. Select the Source Files tab in the New script dialog box. Here, you need
to specify the name of the VI that is to be used to build the DLL. Select
Add Exported VI to bring up the file selection dialog window. Browse
to C:\Exercises\Teststand I\VIs directory and select
VideoDiagnostics.vi. Note that as soon as you make the selection by
clicking Open from the file dialog window, LabVIEW brings up Define
VI Prototype dialog box.
5. In the Function Name text field, enter VideoDiagnostics. This is the
name that will be given to the function that will contain the code for
Video Diagnostics.vi in the DLL.
6. Note that the default calling convention is set to C Calling
Conventions. The VI does not have any input parameters but it does
have output values. To specify the error out and TestData outputs, click
the “+” button next to the Parameters listbox. Select error out from the
VI Output selector for the first output parameter. Click the “+” button

again to add the TestData output parameter. The Define VI Prototype

dialog should now appear as shown.
7. Select OK to complete defining the function prototype. This takes you

back to the Source Files tab in the New script dialog box.
8. You are now ready to build the DLL. Select Build. This shows the
progress bar and when complete it will indicate Build finished! Three
files are created: Ex 5-2A Video Diag.dll, Ex 5-2A Video
Diag.h, and Ex 5-2A Video Diag.lib.
Note If this is the second time you are creating a DLL in the same location, you will
receive a message indicating that the previously created DLLs and its supporting files
will be overwritten. At this point you can either continue and overwrite existing files or
cancel the build operation.
9. Launch TestStand Sequence Editor. Select File»Open to open the

following sequence file: C:\Exercises\Teststand I\ Ex 5-2A
Creating Numeric Limits Tests with LabVIEW (Part
C).seq. This sequence file already contains the Video Diagnostics
Numeric Limit Test step using the DLL Flexible Prototype Adapter.
You are now going to configure the Video Diagnostics step so that is calls
the DLL function that we have just built using LabVIEW.
10. Right-click on the Video Diagnostics step and select Specify
Module to display the Edit DLL Call dialog box.
a. For DLL Pathname, click on browse button to select
C:\Exercises\Teststand I\VIs\Ex 5-2A Video
Diag.dll.

b. For Function Name, select VideoDiagnostics from the pull down

list.
c. Select C(cdecl) for the Calling Convention.
d. Add the error out parameter by selecting the New button. Type Error
Out for the parameter name, Specify Locals.Error for the Value
Expression. Choose C Struct for the Category. Select
CustomError for the Struct Type. The dialog should appear as
follows.

Note When using the C Struct category you must have the corresponding data structure
defined within the TestStand environment and have the Allow Objects of This Type to
be Passed as Structs data type property enabled. This was already taken care of for this
exercise. For more information regarding C Structs as parameters, please see the
TestStand User Manual.
e. Select OK. Execute the sequence by selecting Execute»Test UUTs.

When the report is generated, scroll down the report and observe that
the video test is reported to have failed (as you have selected).
Continue scrolling down and note the status of the Video
Diagnostics step. Notice the measurement value returned—it should
fall between 0 and 30. Observe the Report Text string returned from
the code module if the value is greater than 10.
f. When finished with the exercise, save the sequence file and close the

End of Part C

Exercise 5-2B Creating Numeric Limit Tests with

LabWindows/CVI
Objective: To create a code module for a numeric limit test that simulates a video
diagnostic test.
numeric limit test. Additionally, it demonstrates one way to add information
to the Test Report. The code module passes numeric data and a Report Text
string back to TestStand. TestStand compares the numeric data to predefined
limits and determines whether the test passed or failed. The Report Text
string is displayed in the report.
Part A: Creating the LabWindows/CVI Test

file C:Exercises\TestStand I\Ex 5-2B Creating Numeric
Limit Tests with CVI.seq. This sequence file is the same as those
used in previous exercises, except it is missing the Video
Diagnostics step. The rest of this lesson describes the procedure to
create this step.
2. Make sure the C/CVI Standard Prototype Adapter is selected in the
3. Right-click on the RAM Diagnostics step and select Insert

Step»Tests»Numeric Limit Test. This inserts a Numeric Limit Test
using the C/CVI Standard Prototype Adapter between the RAM
Diagnostics step and the Keyboard Diagnostics step. Name this
step Video Diagnostics.
4. In the following steps you will create a DLL test module that returns a
random numeric measurement and a Report Text string. Use the default
limits of 0 for minimum and 10 for maximum to evaluate the pass/fail
conditions based on the numeric measurement returned from the test. To
view the limits, right-click on the test and select the Edit Limits option.
Click OK to return to the sequence file.

5. Right-click on the new Video Diagnostics step and select Specify

Module. Fill in the Edit C/CVI Module Call dialog box as shown below.
6. You will do the same for the Pathname of CVI Project File to Open text
box located on the Source Code tab. For the pathname of the project file
enter CVI Project Files\Video Diagnostics.prj. Repeat this
process for the Source Code file. Click OK to return to the C/CVI Edit
Module dialog box, which should now appear as shown below.

Click on Create Code. When prompted, click OK to confirm that the

project file should be created in the C:\Exercises\TestStand
I\CVI Project Files subdirectory. Make sure this subdirectory is
selected; if not, select this directory before clicking OK. This step is the
same as in Exercise 5-1B, so the dialog boxes should be familiar.
7. This launches LabWindows/CVI and creates a.c source file named
Video Diagnostics.c. Inside this source file is the template for the
function that must be created, called VideoDiagnostics.
8. The comments are placeholders for developers to insert their code.

Modify this function to generate a random number and pass it to the
measurement parameter via the testData structure. Also, use
replaceStringFuncPtr to provide a string to the outBuffer
string. Make sure your code appears exactly as shown.

Save the source file as Video Diagnostics.c.
9. Ensure that the project target is set for Dynamic Link Library under the
Build»Target menu.
10. Ensure that the DLL to be built is configured to be a debug version of
the DLL by selecting Build»Configuration»Debug.
11. Confirm the DLL target setting by selecting Build»Target Settings.


for Export, as shown below.
13. The VideoDiagnostics function is marked for export with the

dllexport definition. Click OK. Then, click OK again to close the
Target Settings window.
14. Create a DLL by selecting Build»Create Debuggable Dynamic Link
Library.

End of Part A

1. Return to the Sequence Editor. Notice that in all of the pathname
dialogs, the modules are now found in the proper directories, because
they have been created. Click OK to exit the Edit C/CVI Module Call
dialog box.
2. The Video Diagnostics step should execute only if the Video
Test step fails and the Powerup Test and CPU Test steps have
passed. Double-click on the Video Diagnostics step. Click the
Preconditions button. Set the preconditions as shown below.
c. Click CPU Test.


4. Save the sequence as C:\Exercises\TestStand I\Ex 5-2B

Creating Numeric Limit Tests Using CVI.seq. Execute the
sequence by selecting Execute»Single Pass. Select the video test to fail.
5. When the report is generated, observe the Video Diagnostics step report.
Notice the measurement value returned—it should fall between the
values of 5 and 15 as the code above specifies. Observe the outBuffer
string returned from the code module. It should contain the string
message inserted into the LabWindows/CVI code in Part A.
End of Part B

Exercise 5-2C Creating Numeric Limit Tests for the DLL

Flexible Prototype Adapter
Objective: To create a code module for a numeric limit test that simulates a Video
Diagnostic test.
numeric limit test. Additionally, it demonstrates one way to add information
to the test report. The code module passes numeric data and a report text
string back to TestStand. TestStand compares the numeric data to predefined
limits and determines whether the test passed or failed. The report text string
is displayed in the report.
Part A: Creating the DLL Flexible Prototype Adapter Test Module

1. Launch the sequence editor. Select File»Open and select the sequence
file C:\Exercises\TestStand I\Ex 5-2C Creating Numeric
Limit Tests with the DLL Adapter.seq. This sequence file is
the same as that used in previous exercises, except that it is missing the
Video Diagnostics step. The rest of this lesson describes the
procedure to create this step.
2. Make sure the DLL Flexible Prototype Adapter is selected in the
3. Right-click the RAM Diagnostics step and select Insert
Step»Tests»Numeric Limit Test. This inserts a Numeric Limit Test for
the DLL Flexible Prototype Adapter between the RAM Diagnostics
step and the Keyboard Diagnostics step. Rename this step to
Video Diagnostics.
4. To view the limits, right-click the step and select the Edit Limits option.
Click OK to return to the sequence file. Use the default limits of 0 for
minimum and 10 for maximum to evaluate the pass/fail conditions based
on the numeric measurement returned from the test.
5. Right-click the new Video Diagnostics step and select Specify
Module. Under the Module tab enter the control values as shown in the
dialog box.
Note The file, Ex 5-2C Video Diagnostics.dll does not yet exist. You will be
creating it later in this exercise.

6. In the Edit DLL Call dialog box, click the Source Code tab. Click the
Create Code button. Navigate to the C:\Exercises\TestStand
I\CVI Project Files\ directory and enter the filename Ex 5-2C
Video Diagnostics.c as shown.

TestStand may then ask how to store the path to this code resource.
The preferred method to store paths to code resources is relative to the

sequence file, so select the last option, as shown above. Relative paths
are preferred so that if the files are ever moved, the code modules can
still be found as long as they are all moved together. For example, this
situation happens frequently when the test sequence is moved from the
development machine to the test machine, where the drive names and
directory structures could be completely different.
7. Next, you will be prompted for the code template that you would like to
use. Select, TestStand numeric limit template as shown
below. Click OK to create the source code.
Note Upon clicking on OK above, you may get a message saying that you don’t have
an application associated with files of this type and asks if you want to launch Notepad
to view the file. Click No.
8. Notice that the fields in the Source Code tab of the Edit DLL Call dialog
box are now filled in. In the Edit DLL Call dialog box, click the Module
tab. Notice that the parameters in the ring are now filled in.

9. Before you can implement your test, you need to add another parameter
to the function. You will pass a string parameter that will be displayed
in the report. The new parameter will be created after measurement.
Under the Module tab, in the Parameter ring, select Measurement.
Click the New button to insert a new parameter.
10. Rename the arg3 parameter to reportText. Select String for the
Category. For the Pass ring, select C String Buffer. Use C String
when you do not intend to modify the string and C String Buffer
when you intend to modify the string. For the Value Expression, click the
Browse button and insert, Step.Result.ReportText.

Notice that the Function Prototype and Function Call fields at the
bottom of the window are updated as you fill in the fields. The Module
tab should now appear as shown below.
11. The skeleton code previously created with the template in step 7 must
be modified to reflect the new parameter. Click the Source Code tab
and then on the Verify Prototype button. When the Prototype Conflict
dialog box appears, click Use the Prototype from the Module Tab and
click OK. This displays a dialog box to replace the step code.

12. Click the Replace button to replace the existing function prototype with
the new prototype. Click OK and then OK again in the Edit DLL Call
dialog box.
13. Launch LabWindows/CVI and select File»Open»Project. Open the
project file C:\Exercises\TestStand I\CVI Project
Files\Ex 5-2C Video Diagnostics.prj. If prompted, click Yes
to unload the current project and OK to transfer the project options.

14. In the Ex 5-2C Video Diagnostics.prj window, you should see

that Ex 5-2C Video Diagnostics.c is already included in the
project. If it displays File Not Found, select, Edit»Add Files to
Project»Source (*.c). Then double-click Ex 5-2C Video
Diagnostics.c, which you just created. Click the OK button to add
this to the project.
15. In the LabWindows/CVI Project window, double-click Ex 5-2C
Video Diagnostics.c to open the source code window as shown
below.
This code was created from a template file.

16. If the source code window was already open, you will be prompted to
Update the Window from Disk. After selecting Update Window
from Disk, you are prompted to save a copy of the existing contents.
Select No.
17. For this exercise, create a DLL test module that returns a random
numeric value and a report text string. Replace the source code with the
following:
Note The code shown is for illustration only, be sure to use proper syntax in your code.

void __declspec(dllexport) __stdcall VideoDiagnostics(

CAObjHandle seqContextCVI, double *measurement, char
reportText[1024], short *errorOccurred, long
*errorCode, char errorMsg[1024])
{
int error = 0;
ErrMsg errMsg = {'\0'};
ERRORINFO errorInfo;
*measurement = Random(0,20); /* Random value from 0 to
20. Since the step limits are 0 and 10, it gives almost
50% of chance for either pass or fail */
strcpy(reportText, "no adapter present");
Error:
// FREE RESOURCES
// If an error occurred, set the error flag to
// cause a run-time error in TestStand.
if (error < 0)
{
*errorOccurred = TRUE;
// *errorCode = error;
// strcpy(errorMsg, errMsg);
}
return;
}
18. Save the source file.
19. In LABWINDOWS/CVI, select the project window by selecting
Window»Project.
20. Ensure that the project target is set for Dynamic Link Library under the
Build»Target Type menu.
21. Ensure that the DLL to be built is configured to be a debug version of
the DLL by selecting Build»Configuration»Debug.


23. Ensure the Ex 5-2C Video Diagnostics.dll will be built in

C:\Exercises\TestStand I\CVI Project Files.
24. VideoDiagnostics.fp was already created for this exercise. You

will use this function panel file to create a type library. A type library
is a component of a DLL that can be used by TestStand to look up the
function prototype when a function call is specified.
25. Click the Type Library button. Click the Add type library
resource to DLL checkbox. Select the function panel file
C:\Exercises\TestStand I\CVI Project
Files\VideoDiagnostics.fp.
26. Click OK to return to the Target Settings dialog box. Click OK to close
the Target Settings window.
27. Finally, create the Ex 5-2C Video Diagnostics.dll by selecting
Build»Create Debuggable Dynamic Link Library.

28. Return to the sequence editor. In the Edit DLL Call dialog box, click the
Browse button for the DLL Pathname control and select the Ex 5-2C
Video Diagnostics.dll that you just created. When asked how you
resolve the path to this code module, select Use a Relative Path
and click OK. Click OK to close the Edit DLL Call dialog box.
End of Part A
Part B: Configuring the step properties

1. Return to the sequence editor. Notice that in all of the pathname dialogs,
the modules are now found in the proper directories, because they have
been created. Click OK to exit the Edit DLL Module Call dialog box.
2. The Video Diagnostics step executes only if the Video Test step
fails and the Powerup Test and the CPU Test steps have passed.
Double-click the Video Diagnostics step. Click the Preconditions
button. Set the preconditions as shown below.
c. Click CPU Test.


4. Save the sequence as C:\Exercises\TestStand I\Ex 5-2C
Creating Numeric Limit Tests With DLL Adapter.seq.
Execute the sequence by selecting Execute»Single Pass. Select the
Video Test to fail.
5. When the report is generated, observe the Video Diagnostics step
result in the report. Notice the measurement value returned—it should
fall between the values of 0 and 20. Observe the outBuffer string
returned from the code module. It should contain the string “no
adapter present.”

6. When finished, save and close the sequence file.
End of Part B

Exercise 5-3A Debugging Tests Using LabVIEW

Objective: To debug code modules compiled with LabVIEW.
While debugging a TestStand sequence, the sequence developer can step
into specific code modules and use the debugging tools that are part of that
development environment. TestStand can step directly into LabVIEW and
LabWindows/CVI code modules. This exercise demonstrates how to step
into a LabVIEW code module and use LabVIEW debugging tools to step
through the LabVIEW code.
1. In the Sequence Editor, select File»Open and select the sequence file
C:\Exercises\TestStand I\Ex 5-3A Debugging Tests
Using LabVIEW.seq. Notice that this sequence is the solution created
for Exercise 5-2A. Remember that a copy of the solution for each
exercise is in the C:\Solutions\TestStand I directory.
2. Place a breakpoint at the Video Diagnostics step by clicking to the
left of the step. A STOP icon appears as shown below.

3. Execute the sequence, check the video test to fail, and the execution
pauses at the breakpoint. Use the watch window, as described in
Exercise 2-2, to watch the result for this step. The value to watch is
RunState.Sequence.Main["Video Diagnostics"].Result.Numeric,
and the hierarchy for selecting it in the Context window is shown below.
4. Click on the Step Into button in the toolbar, which steps into the
LabVIEW code module.

5. From the Video Diagnostics VI front panel, select Windows»Show

Diagram. Select Windows»Show Tools Palette. In the Tools palette,
click on the Breakpoint tool (the stop sign).

6. With the Breakpoint tool, click on any wire to set a breakpoint. Run the
VI by clicking the Run button. You can use the LabVIEW debugging
tools to debug the code. Click the Pause/Continue button to finish
execution.
7. Click the Return to Caller button to return execution to TestStand. The
value in the watch window should now contain the random number
generated in the test. This value changes only when the LabVIEW code
has finished executing and the return values from the Test Data cluster
have been passed back into TestStand.
8. In TestStand, click the Resume button to finish the execution.
Note It is also possible to debug a LabVIEW DLL. However, because you can only
debug a LabVIEW DLL from within the same process, you must debug the LabVIEW
DLL using the LabVIEW Operator Interface and not the Sequence Editor. To debug a VI
that was compiled into a function in a LabVIEW DLL, you can perform the following
steps:
a. Within LabVIEW, open the VI that was used to build the function
you wish to debug in the LabVIEW DLL.
b. Place a breakpoint within this VI.

c. Within LabVIEW, open and run the top level VI for your LabVIEW
Operator Interface.
d. Within your LabVIEW Operator Interface, select the test sequence
that is calling the function in the LabVIEW DLL that you wish to
debug.
e. Execute the test sequence from within the LabVIEW Operator
Interface.
f. The execution will automatically stop for debugging at the
breakpoint that you placed within the VI in step a, above.

Exercise 5-3B Debugging Tests Using LabWindows/CVI

Objective: To debug code modules compiled with LabWindows/CVI.
While debugging a TestStand sequence, the sequence developer can step
into specific code modules and use the debugging tools that are part of that
development environment. TestStand can step directly into LabVIEW and
LabWindows/CVI code modules. This exercise shows how to step into a
LabWindows/CVI code module and use LabWindows/CVI debugging tools
to step through the code.
C:\Exercises\TestStand I\Ex 5-3B Debugging Tests with
CVI.seq. Notice that this sequence is the solution to Exercise 5-2B.
Remember that the solutions for each exercise can be found in the
C:\Solutions\TestStand I directory.
2. First, you will enable the C/CVI Standard Prototype Adapter to execute
steps in an external instance of LabWindows/CVI. TestStand must
execute the LabWindows/CVI code externally, within the
LabWindows/CVI IDE, to allow debugging of the LabWindows/CVI
test code. When you finish debugging test code, you can set TestStand
to run the code in process if it is compiled as an object file or DLL, for
optimum performance.
Select Configure»Adapters. In the Adapter Configuration dialog box
that appears, ensure that the C/CVI Standard Prototype Adapter is
selected. Click the Configure button.
In the C/CVI Standard Adapter Configuration dialog box, click the
Execute Steps in an External Instance of CVI radio button as shown
below.

Execute Steps in an External Instance of CVI tells TestStand to

launch LabWindows/CVI and load all support files into it when
LabWindows/CVI steps are called. This option allows the TestStand
debugger to step into the step code when the Step Into option is selected
for a LabWindows/CVI step with a specified C source code file.
Execute Steps In-Process tells TestStand not to launch an external
LabWindows/CVI process. This means you cannot step into a
LabWindows/CVI step even if the C source code file is specified. Most
of the time, the second option will be chosen, so that an external instance
of LabWindows/CVI is not launched during execution of the sequence.
However, during the debugging of a sequence it is often advantageous
to step directly into the code module to verify that parameters and other
environment settings are being configured properly.
3. Click OK to close the C/CVI Standard Adapter Configuration display.
Click OK to unload all modules. Click Done in the Adapter
Configuration dialog box.

4. Place a breakpoint at the Video Diagnostics step by clicking along

the edge as shown below. Run the sequence, check the video test to fail,
and the execution pauses at the breakpoint.
5. Step into the code module by clicking on the Step Into button in the
toolbar.

6. This launches the LabWindows/CVI debugging window, where you can

use the LabWindows/CVI stepping tools, watch window, and variable
window to debug the code.
7. When finished with the LabWindows/CVI debugging window, press the

Go button to finish executing this function and return execution to
TestStand.
8. Finally, reset the adapter configuration option to run LabWindows/CVI
Tests In Process. Select Configure»Adapters.... In the Adapter
Configuration dialog box, select C/CVI Standard Prototype Adapter,
and click on Configure.... Click on Execute Steps In Process and click
OK. Click OK to unload all modules. Click Done in the Adapter
Configuration dialog box.
To stop the LabWindows/CVI project tscvirun.prj, which is used
for debugging, press <Ctrl-F12> to terminate execution. Finally, close
the LabWindows/CVI IDE. When finished with the exercise, save and
close the sequence file.

Exercise 5-3C Debugging Tests that use the DLL Flexible

Prototype Adapter
Objective: To debug code modules that use the DLL Flexible Prototype Adapter.
Exercise 5-3B shows how to step into code modules called with the C/CVI
Standard Prototype Adapter. In contrast, you cannot step into code
modules that are called with the DLL Flexible Prototype Adapter.
However, this exercise demonstrates how to debug your test code from your
C development environment.
C:\Exercises\TestStand I\Ex 5-3C Debugging Tests
with DLL Adapter.seq. Notice that this sequence is the solution to
Exercise 5-2C except that the Video Diagnostics step calls Ex
5-3C Video Diagnostics.dll. Remember that the solutions for
each exercise can be found in the C:\Solutions\TestStand I
directory.
2. Exit the sequence editor.
3. In LabWindows/CVI, select File»Open»Project. Open the project file
Video Diagnostics.prj.
4. Open the source file by double-clicking on Ex 5-3C Video
Diagnostics.c listed in the project window. Place a breakpoint
on line 11 which has the following statement:
*measurement = 10 + (rand()%11);

This is shown in the following figure:
Note Place a breakpoint by clicking on the Line Icons column or by pressing F9 while
your cursor is on that particular line.
5. Select the project window by selecting Window»Project.

6. In the project window, select Run»Select External Process. Click the
Browse button and select C:\TestStand\bin\SeqEdit.exe.
7. Click OK to return to the LabWindows/CVI Project window. Select

Run»Run SeqEdit.exe to launch the sequence editor from
LabWindows/CVI. If prompted to save changes, select Yes.

8. In the Sequence Editor, open the sequence file C:\Exercises\

TestStand I\Ex 5-3C Debugging Tests with DLL
Adapter.seq. Run the sequence, check the Video Test to fail, and
you will see that execution will stop at the breakpoint you set in the
source code when the Video Diagnostics step executes.
9. In the LabWindows/CVI debugging window, you can use the

LabWindows/CVI stepping tools, watch window, and variable window
to debug the code.
10. When finished with the LabWindows/CVI debugging window, press the
Go button to finish this function and return execution to TestStand.
Using this technique, you can debug your test code, which is compiled
into a DLL. This technique also applies to steps that call the C/CVI
Standard Prototype Adapter.
11. Finally, close Ex 5-3C Debugging Tests with DLL
Adapter.seq and exit the sequence editor.
End Of Exercise 5-3C

Exercise 5-4A Using the ActiveX API in Code Modules

with LabVIEW
Objective: To pass numeric data and a Report Text string from a code module to TestStand using
the ActiveX API.
This exercise produces the same results as Exercise 5-2A, but it uses the
ActiveX Application Programming Interface (API) to pass result data to
TestStand. Although in this step you will pass the step’s result data, the
ActiveX method for passing data is very useful because it enables you to get
or set any TestStand property or variable, including local or global variables.
Part A: Passing the Sequence Context ActiveX Object Handle

1. In the Sequence Editor, select File»Open and open the sequence file
C:Exercises\TestStand I\Ex 5-4A Using the ActiveX API
with LabVIEW.seq.
For this exercise, a LabVIEW test will be created that returns a random
numeric measurement value and a report text string. Use the default
limits of 0 for minimum and 10 for maximum to evaluate the pass/fail
status based on the numeric measurement returned from the test. To
view the limits for this numeric limit test step, right-click on the test step
and select Edit Limits.
Module. Click on the Browse button, navigate to the
C:\Exercises\TestStand I\VIs directory, and type in
VideoDiagnosticsActiveX.vi for the VI name. Check the
Sequence Context ActiveX Pointer box as shown below. This instructs
TestStand to pass the sequence context handle to the code module to
allow ActiveX API functions to access step and sequence properties or
variables. Click on Create VI to have TestStand create a new VI that can
be called as a step from TestStand.

When prompted for the directory to save in, select C:\Exercises\

TestStand I\VIs (if not already selected) and click OK to continue.
Select a relative path when TestStand asks how to store the path, just as
in the first exercise.
3. A VI is created with the name VideoDiagnosticsActiveX.vi, which

contains the TestData and Error Out clusters. In addition, the VI has a
Sequence Context control on the front panel. This is an ActiveX
Automation Refnum.

Optional Reading (You May Skip to Part B Below)

If you need to add the Sequence Context refnum to the front panel
manually, right-click and select the Sequence Context control from the
TestStand subpalette as shown below.

You may also need to connect the Sequence Context refnum to the VI
connector pane. Right-click in the icon area of the VI and select Show
Connector. (See the arrow below.)
With the Wiring tool, click on the upper-left terminal of the connector. In the
figure above, this is the blacked-out terminal. With the same Wiring tool,
click on the Sequence Context refnum to associate the front panel object
with the terminal in the connector.
End of Part A

Part B: Creating the Code in the Diagram

1. Build the diagram as shown in the figure below.
Typically, ActiveX calls pass data into and out of TestStand that cannot be
passed using the TestStand Data Cluster. However, to demonstrate passing
some simple information, in this exercise, the values passed are the same
values that could be passed using the TestStand Data Cluster. In this
exercise, you pass a random number to the Step.Result.Numeric property
of the step that calls this code module. You also pass a string to the
Step.Result.ReportText property of the same step.
You will use two ActiveX VIs to set these step properties:
• Set Property Value (Number).vi sets the numeric value of the
SequenceContext property the Lookup String control specifies.
• Set Property Value (String).vi sets the string value of the
SequenceContext property the Lookup String control specifies.

The TestStand ActiveX API functions are in the TestStand subpalette as

shown.
In this exercise, a random number is passed into the New Value terminal of
Set Property Value (Number).vi, which passes that value to the property
specified by the Lookup String.
The random number is also compared to 10; if it is greater than 10, a text
message is passed to the New Value terminal of Set Property Value
(String).vi. In the false case of the case structure, pass an empty string.
2. Save the VI as C:\Exercises\TestStand I\
VIs\VideoDiagnosticsActiveX.vi.
3. Return to the Sequence Editor.
End of Part B

Part C: Configuring the Step Properties

Notice that the VI is now found. Click OK to leave the Edit LabVIEW VI
Call dialog box. The Video Diagnostic step should appear between the
RAM Diagnostics step and the Keyboard Diagnostics step.
2. Save the sequence as C:\Exercises\TestStand I\Ex 5-4A

Using the ActiveX API with LabVIEW.seq. Execute the
sequence by selecting Execute»Single Pass. Select the video test to fail.
3. Use the watch window as described in Exercise 5-2A to watch the
TestStand expressions: RunState.Sequence.Main["Video
Diagnostics"].Result.Numeric and RunState.Sequence.
Main["Video Diagnostics"].Result.ReportText. When the LabVIEW
code finishes executing and the code module has returned its values to
TestStand, the values in the watch window should display the results for
this test.

4. When the report is generated, scroll down the report and observe the
status of the Video Diagnostics step. Notice the measurement value
returned—it should fall between 0 and 30. Observe the Report Text
string returned from the code module if the value is greater than 10.

Exercise 5-4B Using the ActiveX API in Code Modules

with LabWindows/CVI
Objective: To pass numeric data and a string from a code module to TestStand using ActiveX.
This exercise produces the same results as Exercise 5-2B, but it uses the
ActiveX Application Programming Interface (API) to pass result data to
TestStand. Although in this step you will pass the step’s result data, the
ActiveX method for passing data is very useful because you can use it to get
or set any TestStand data, including local or global variables.
1. In the Sequence Editor, open Ex 5-4B Using the ActiveX API
with CVI.seq. The rest of this lesson describes how to create the code
module to be used by this step using ActiveX calls.
Module. Fill in the resulting dialog boxes as shown below. After you
complete the dialog boxes, the Video Diagnostics step calls the
VideoDiagnostics function created in Exercise 5-2B. Remember that the
solutions for all exercises are in the C:\Solutions\TestStand I\
CVI Project Files directory. Copy all the Video Diagnostic files to
the C:\Exercises\TestStand I\CVI Project Files directory
before continuing if Exercise 5-2B was not completed.

Warning This exercise modifies the behavior of the code for the Video Diagnostics step.
These changes may affect Exercise 5-2B, so be sure to complete that exercise before
completing this one. You can always recreate Exercise 5-2B by repeating it.
3. Right-click on the Video Diagnostics step and select Edit Code
from the menu. This launches LabWindows/CVI and opens the Video
Diagnostics project and source code containing the
VideoDiagnostics function. These files are in the
C:\Exercises\TestStand I\CVI Project Files\ directory.
In Video Diagnostics.c, you will replace the following code with the
ActiveX API equivalent.
testData->measurement = measurement;
if(!testData->replaceStringFuncPtr(&testData->outBuffer,
"Unstable VSS readings at video controller"))
{
error = TS_Err_OutOfMemory;
goto Error;
}
4. Delete the above code and place your cursor below the following line:
measurement = 5 + (rand()%11);
5. Under the Instrument menu, you should find the TestStand API 2.0
instrument driver. If you do not, load TSAPICVI.fp from the
<TestStand path>\API\CVI\ directory by selecting
Instrument»Load.
6. In the TestStand API instrument driver, go to the Property
Object»Values tree and select Set Numeric Value.

Fill in the boxes as shown below. Notice that the function call is filled
in at the bottom of the Function Panel window as you type in the boxes.
Use the function call information to see how to fill in the boxes, because
the screen limitations do not allow all text to be displayed.

7. Right-click in the Function Panel window to see the help for this
function. You can right-click on each control to get help on each
parameter.
8. Some of the parameters used include:
Object Handle: This is a handle to the Sequence Context object in
TestStand and is passed through the tTestData struct. Later in this
exercise, you will see how TestStand actually passes this handle.
Error Info: This is the returned error information. A C-macro handles
this error information and the returned status value. Notice that there are
several error status codes defined in the online help.
Lookup String: To specify the property, pass a string that defines a path
from the object on which you call the method to the specific property
you want to access. To specify the object itself, pass an empty string
(""). To specify a subproperty, pass the name of the subproperty. To
specify a subproperty of a subproperty, pass a string containing both
names separated by a period (.). Later in this exercise, you will see how
to browse for this parameter.
Options: Refer to the online help for a list of available options.
New Numeric Value: The value to set to the property specified by the
Lookup String. You will use “measurement” for this exercise.
9. Close the help window. From the function panel window, select
Code»Set Target File. Be sure the Target File is set to the Video
Diagnostics.c file.
10. Select Code»Insert Function Call to insert this function where your
cursor last was in the Video Diagnostics.c file.
11. Now, you will insert the TS_PropertySetValString() function call
into the source file. Select this function from the same tree, Property
Object»Values, in the TestStand API instrument driver and select Set
String Value. Fill in the parameters as shown below and insert this
function call in the Video Diagnostics.c file.

12. Return to the Video Diagnostics.c file and be sure that you filled
in the function calls as shown.
TS_PropertySetValNumber (testData->seqContextCVI,
&errorInfo, "Step.Result.Numeric",
0, measurement);
TS_PropertySetValString (testData->seqContextCVI,
&errorInfo,
"Step.Result.ReportText", 0,
"Unstable VSS readings at video
controller");
13. Return to TestStand and click OK to close the Edit C/CVI Module Call
dialog box.
14. Switch to the Sequence Editor and right-click on the Video
Diagnostics step in the sequence file. Select Browse Sequence
Context from the context menu. In this tree, select
Step.Result.Numeric as shown below. This is the same Lookup
String passed into the TS_PropertySetValNumber function call.
Notice that you could have copied this variable/property with the Copy
Property Path button and pasted it into the function call.

Notice also that any property or variable could be referenced with

similar Lookup Strings.
15. Finally, check the error status with a macro defined in tsutil.h.
tsErrChkMsgPopup() displays the error description and jumps to
Error: with the error variable set.
16. Enter the macro as shown in bold and underlined below. Make sure that
the code appears exactly as shown.
#include "stdtst.h"
#include "tsutil.h"
void __declspec(dllexport) TX__TEST VideoDiagnostics(tTestData *testData,

tTestError *testError)
{
int error = 0;
ErrMsg errMsg;
double measurement;
measurement = 5 + (rand()%11); /* value from 5 to 15 */

tsErrChkMsgPopup (TS_PropertySetValNumber (testData->seqContextCVI,
&errorInfo,
"Step.Result.Numeric",

0, measurement));
if (measurement >10) {
tsErrChkMsgPopup (TS_PropertySetValString (testData->seqContextCVI,
&errorInfo,
"Step.Result.ReportText",
0, "Unstable VSS readings at video controller"));
}
Error:
// If an error occurred, set the error flag to cause a run-time
if (error < 0) {
testError->errorFlag = TRUE;
// OPTIONALLY SET THE ERROR CODE AND STRING

testError->errorCode = error;
}
return;
}
The final screen should resemble the following.
17. Save Video Diagnostics.c.
18. Ensure that the project target is set for Dynamic Link Library under
Build»Target Type.
19. Ensure that the DLL to be built is configured to be a debuggable version

of the DLL by selecting Build»Configuration»Debug.
20. Create the DLL by selecting Build»Create Debuggable Dynamic Link

Library. If LabWindows/CVI says access is denied to overwrite the

DLL, you need to select File»Unload All Modules in the Sequence

Editor so that the DLL can be overwritten.
21. Return to the Sequence Editor and right-click on the Video Diagnostics
step, selecting Specify Module. Be sure the Pass Sequence Context
checkbox is checked as shown below. This checkbox instructs
TestStand to pass the ActiveX handle to the Sequence Context object
in the tTestData structure of the function being called.
22. Notice that in all pathname dialogs, the modules are now in the proper
directories. Click OK to exit the C/CVI Edit Module dialog box.
c. Click CPU Test.

24. Save and run Ex 5-4B Using the ActiveX API with CVI.seq
to verify that it works correctly. When this sequence is run, make sure
that the video test is selected to fail. In the test report, verify that the
correct data is returned.

Exercise 5-4C Using the ActiveX API in Flexible DLL Code

Modules
Objective: To return numeric data and a string from a code module to TestStand using the
TestStand ActiveX API.
This exercise produces the same results as Exercise 5-2C, but it uses the
TestStand ActiveX Application Programming Interface (API) to return
result data to TestStand. Although in this step, you will pass the result data
for the step, the ActiveX method for passing data is very useful because you
can use it to get or set any TestStand data, including local or global variables.
1. In the sequence editor, open Ex 5-4C Using the ActiveX API
with the DLL Adapter.seq. The rest of this lesson describes how
to create the code module.
2. Right-click the Video Diagnostics step and select Specify Module.
Fill in the resulting dialog boxes as shown below. After you complete the
dialog boxes, the Video Diagnostics step calls the
VideoDiagnostics_API function. Remember that the solutions for
all exercises can be found in the C:\Solutions\TestStand I\CVI
Project Files\ directory.


3. Click OK to close the Edit DLL Call dialog box.

4. In LabWindows/CVI open the project file
Video Diagnostics.prj project in the directory. Open the
VideoD_API.c source code file, which contains the
VideoDiagnostics_API function. You will now add the necessary
code to communicate with TestStand using the API.
5. Place your cursor on line 12 (if line numbers are not visible, go to
View»Line Numbers).
6. Under the Instrument menu, you should find the TestStand API 2.0
instrument driver. If you do not, load TSAPICVI.fp from the
C:\TestStand\API\CVI\ directory by selecting Instrument»Load.
7. In the TestStand API instrument driver, go to the Property

Object»Values tree and select Set Numeric Value.

8. Fill in the boxes as shown below. Notice that the function call is filled
in at the bottom of the Function Panel window as you type into the
boxes. Use the function call information to see how to fill in the boxes.
Parameter Value
Object Handle seqContextCVI
Error Info &errorInfo
Lookup String "Step.Result.Numeric"
Options 0
New String Value 10 + (rand()%11)

9. Right-click in the function panel window to see the help for this
function. You can right-click each control to get help on each parameter.
10. Some of the parameters include:
• Object Handle—This is a handle to the Sequence Context
object in TestStand. Later in this exercise, we will see how TestStand
actually passes this handle.
• Error Info—This is the returned error information. A C-macro
handles this error information and the returned status value. Notice
that there are several error status codes defined in the online help.
• Lookup String—To specify the property, pass a string that defines
a path from the object on which you call the method to the specific
property you want to access. To specify the object itself, pass an
empty string (""). To specify a subproperty, pass the name of the
subproperty. To specify a subproperty of a subproperty, pass a string
containing both names separated by a period(.). Later in this
exercise, we will see how to browse for this parameter.
• Options—Refer to the online help for a list of available options.
• New Numeric Value—The value to set to the property specified by
the Lookup String. You will use a random number for this exercise.
11. Close the help window if open. From the function panel window, select
Code»Set Target File. Be sure the target file is set to the
VideoD_API.c file.
12. Select Code»Insert Function Call to insert this function where your
cursor was in the VideoD_API.c file.
13. Now, you will insert the TS_PropertySetValString() function call
into the source file. Select this function from the same tree: Property
Object»Values, in the TestStand API instrument driver. Fill in the
parameters as shown below and insert this function call in the
VideoD_API.c file.
Parameter Value
Object Handle seqContextCVI
Error Info &errorInfo
Lookup String "Step.Result.ReportText"
Options 0
New String Value "Unstable VSS readings at video controller"

14. Return to the VideoD_API.c file and be sure that you filled in the
function calls as shown.
TS_PropertySetValNumber (seqContextCVI, &errorInfo,

"Step.Result.Numeric", 0, 10 + (rand()%11));
TS_PropertySetValString (seqContextCVI, &errorInfo,
"Step.Result.ReportText", 0,"Unstable VSS readings at
video controller");
15. Switch to the TestStand Sequence editor and click OK to close the Edit
DLL Call dialog box. Click OK to close the Video Diagnostics
Properties dialog box.
16. Right-click the Video Diagnostics step in the sequence file. Select
Browse Sequence Context from the context menu. In this tree, select
Step.Result.Numeric as shown below. This is the same Lookup
String that we passed in to the TS_PropertySetValNumber function
call. Notice that we could have copied this variable/property with the
Copy Property Path button and pasted it into our function call. Close
this dialog box when finished looking at it.

Note All properties and variables could be referenced with similar lookup strings.
17. Return to LabWindows/CVI. Finally, check the error status with a macro
that is defined in tsutil.h. tsErrChkMsgPopup() displays the
error description and jumps to the label Error:. Enter the macro as
shown in bold below. Make sure that the code appears exactly as shown
below.
#include "stdtst.h"
#include "tsutil.h"
void __declspec(dllexport) __stdcall
VideoDiagnostics_API(CAObjHandle
seqContextCVI, short *errorOccurred, long *errorCode, char
errorMsg[1024])
{
int error = 0;
ErrMsg errMsg = {'\0'};

tsErrChkMsgPopup(TS_PropertySetValNumber,(seqContextCVI,
&errorInfo, "Step.Result.Numeric", 0, 10 +(rand()%11)));
tsErrChkMsgPopup(TS_PropertySetValString (seqCotextCVI,
&errorInfo, "Step.Result.ReportText", 0, "Unstable VSS
readings at video controller"));
Error:
// FREE RESOURCES
// If an error occurred, set the error flag to
// cause a run-time
// error in TestStand.
if (error < 0)
{
*errorOccurred = TRUE;
*errorCode = error;
strcpy(errorMsg, errMsg);
}
return;
}
18. Save VideoD_API.c.
19. VideoD_API.fp was already created for you. We will use this function
panel file to create a type library. A type library is a component of a DLL
that can be used by TestStand to look up the function prototype when a
function call is specified. The type library exposes the functions and
arguments to the user of the DLL. This allows the user to view from
TestStand the parameters of a function in a DLL.
Note For more information on type libraries for LabWindows/CVI please refer to the
LabWindows/CVI User Manual. For information on how to create type libraries in VC++
please refer to the knowledge base document Creating a Type Library Using Visual C++
in our web site at ni.com
20. From the project file, ensure that the target is set for Dynamic Link
Library under Build»Target Type. Ensure that the DLL to be built is
configured to be a release version of the DLL by selecting
Build»Configuration»Release.

Click Type Library and check the box next to Add Type Library
Resource to DLL. Click the Browse button and choose the file
VideoD_API.fp. The window should resemble the one shown below.
22. Click OK to close the Type Library Window. Click OK to close the
Target Settings window.
23. Create the DLL by selecting Build»Create Release Dynamic Link
Library from the menu. You should get a message notifying that the
files were successfully created.
24. Return to TestStand’s Sequence Editor and right-click the Video

Diagnostics step, then select Specify Module. From the function
ring select VideoDiagnostics_API. Select No if you get the
following window:

Notice that now you can browse the parameters of

VideoDiagnostics_API function. This is due to the DLL’s type
library.
25. Click OK to close the Edit DLL Call dialog box.

Test step fails and the Powerup Test and the CPU Test steps have
passed. Double-click the Video Diagnostics step. Click the
Preconditions button. Set the preconditions as shown below:

c. Click CPU Test.

27. Save and run Ex 5-4C Using the ActiveX API with the DLL
Adapter.seq to verify that it works correctly. When this sequence is
run, make sure that the Video Test is selected to fail. In the test report,
verify that the correct data is returned.

Exercise 5-5A Creating a Simple Test Using the LabVIEW

Standard Prototype Adapter
Objective: To write a simple Numeric Limit Test that uses the LabVIEW Standard Prototype
Adapter.
Write a test function that generates and plots a sine wave. Measure the
estimated AC content of the sine wave and return this value as the numeric
measurement to TestStand. This AC value will be compared with user
defined limits within TestStand. For this step use the following limits:
• 0 <= Measurement <= 3.
• Name your step SineACEstimator.
• Name your test VI SineACEstimator.vi.
Hints:
Use a Numeric Limit Test step type that uses the LabVIEW Standard
Prototype Adapter.
Create a SubVI that generates and plots a sine wave. This SubVI should
have 4 inputs and one output as described below:
Parameter Data Type Object Type
Samples I32 Numeric Control (Input)
Amplitude DBL Numeric Control (Input)
Cycles DBL Numeric Control (Input)
Plot Title String String Control (Input)
Sine Wave DBL Waveform Graph (Output)
Note Use constants in the top level VI as inputs to the above SubVI parameters in
LabVIEW. In Exercise 5-6A you will get the parameter values from variables defined in
TestStand through the TestStand ActiveX API.
VIs to use:
Sine Pattern.vi, which can be found in:
Analyze»Signal Processing»Signal Generation
AC & DC Estimator.vi, which can be found in:

Analyze»Signal Processing»Time Domain

For Sine Pattern.vi use the following parameters:

Parameter Value
Number of Elements 1024
Amplitude 1.0
Number of cycles 4
Phase 0
Use an attribute node to assign the plot title.
Save the sequence as Ex 5-5A Simple LabVIEW Numeric Limit

Test.seq.

Exercise 5-5B Creating A Simple Test Using The C/CVI

Standard Prototype Adapter
Objective: To write a simple Numeric Limit Test that uses the C/CVI Standard Prototype
Adapter.
Write a test function that generates and plots a sine wave. Measure the
estimated AC content of the sine wave and return this value as the numeric
measurement to TestStand. This AC value will be compared with
user-defined limits within TestStand. For this step, use the following limits:
• 0 <= Measurement <= 3
• Name your step SineACEstimator.
• Name your test function SineACEstimator.
• Save the source code as CVI Test Functions.c.
• Save the project file as CVI Test Functions.prj.
Hints:
Use a Numeric Limit Test step type that uses the C/CVI Standard
Prototype Adapter.
Functions to use: SinePattern, YGraphPopup, ACDCEstimator
For SinePattern use the following parameters:

Parameter Value
Number of Elements 1024
Amplitude 1.0
Phase 0.0
Number of cycles 4
Sine Pattern sine (Declare this in CVI.)
Save the sequence as Ex 5-5B Simple CVI Numeric Limit

Test.seq.

Exercise 5-6A Passing Parameters from TestStand to LabVIEW

using The TestStand API
Objective: To learn how to use the TestStand API to pass data between TestStand and LabVIEW.
This exercise will focus on passing data from TestStand to LabVIEW using
the TestStand API. Within the Sequence Editor, open the sequence file
C:\Exercises\TestStand I\Ex 5-5A Simple LabVIEW Numeric
Limit Test.seq. Save this sequence file as Ex 5-6A Simple LabVIEW
Numeric Limit Test API.seq. Create the following local variables in
TestStand:
Name Type Default Values
NSamples Number 2048
NCycles Number 5
Amplitude Number 5
PlotTitle String “Sine Wave API”
This sequence file should contain the step SineACEstimator, which you
created in the previous exercise. Add another Numeric Limit Test step
that uses the LabVIEW Standard Prototype Adapter and name it
SineACEstimator_API. Create a new VI and name it
SineACEstimator_API.vi. This VI will be a modification of the
SineACEstimator.vi that you created in the previous exercise. Use the
TestStand API to pass the local variables above to your test VI instead of
using constants as in Exercise 5-5A.
Hints:
Make sure you check the Sequence Context ActiveX Pointer checkbox as
shown below:

VIs to use:
TestStand - Get Property Value (Number).vi
TestStand - Get Property Value (String).vi
Both functions are available in the TestStand palette.
Save the VI.
Save the sequence file.

Exercise 5-6B Passing Parameters from TestStand to

LabWindows/CVI using The TestStand API
Objective: To learn how to use the TestStand API to pass data between TestStand and CVI.
This exercise will focus on passing data from TestStand to

LabWindows/CVI using the TestStand API. Within the Sequence Editor,
open the sequence file C:\Exercises\TestStand I\Ex 5-5B Simple
CVI Numeric Limit Test.seq. Save this sequence file as Ex 5-6B
Simple CVI Numeric Limit Test API.seq. Create the following
local variables in TestStand:
Name Type Default Values
NCycles Number 4
Amplitude Number 1
PlotTitle String “Sine Wave”
This sequence file should contain the step SineACEstimator, which you
created in the previous exercise. Add another Numeric Limit Test step
that uses the C/CVI Standard Prototype Adapter and name it
SineACEstimator_API. In the source code, CVI Test Functions.c,
create a new function and name it SineACEstimator_API. This function
will be a modification of the SineACEstimator function that you created
in the previous exercise. Use the TestStand API to pass the above local
variables to your test function.
Hints:
Make sure you check the Pass Sequence Context checkbox as shown.

Functions to use:
TS_PropertyGetValNumber, TS_PropertyGetValString.
Save the source code as CVI Test Functions.c.
Save the sequence file.

Exercise 5-7 Passing Data Between TestStand and a Test

Module Using the DLL Flexible Prototype Adapter
Objective: Learn how to pass data between TestStand and your test module using the DLL
Flexible Prototype Adapter.
When using the DLL Flexible Prototype Adapter, data can be passed
directly as parameters or as C structures (containers in TestStand). In this
exercise you will add a step that fills the information of a Graph container
so it can be displayed on the screen.
Using the Sequence Editor, open C:/Exercises/TestStand I/Ex 5-7

Passing Data Using DLL Flexible Prototype Adapter.seq.
Insert an Action step that uses the DLL Flexible Prototype Adapter after
the step named Set Amplitude. Name the new step, Calculate Graph. In
LabWindows/CVI, open the project Ex 5-7 Passing Data Using DLL
Flexible Prototype Adapter.prj. Add a function that receives a
pointer to a Graph structure (to store the graph information) and a pointer to
a double (to hold the RMS value of the calculated wave). Add the
appropriate code to generate a sine wave with the given amplitude and
number of cycles. Return the sine wave data to the data field in the structure.
Also, calculate the RMS value of the generated waveform.
In the Sequence Editor, when specifying the code module, make sure to pass
the graph information (stored in Locals.Graph) by reference as a C Struct.
Also, pass the RMS variable (Locals.RMSValue) by reference as a double.
Tip To calculate the sine wave, use the Sine Pattern function located under the
Library»Advanced Analysis»Signal Generation menu in CVI.
To calculate the RMS value, use the RMS function located under the Library»Advanced
Analysis»Statistics»Basic menu in CVI.
The rest of the sequence will display the graph and the RMS value. Modify
the statements before the Calculate Graph step to alter the parameters
for the sine wave generation.
Notes An alternative option to alter the parameters for the sine wave generation would
be to use the Pre Expression of the succeeding step. This method behaves similarly,
but avoids the overhead of adding extra Statement steps.
In order to pass data as a C structure, a custom data type with the same elements of the
structure must be created. In the Struct Passing tab of the properties dialog for your data
type, set the Allow Objects of This Type to be Passed as Structs option. Use the
remaining controls on the tab to specify how TestStand formats that data type in memory
when you pass it as a structure parameter. In this exercise, this custom data type and all

of its settings have already been set for you. For more information on TestStand types,
please refer to the TestStand User Manual.
End of Exercise 5-7

Notes

Lesson 6
User Management
Lesson 6: User Management

• Add users to the user manager
• Customize user privileges
Introduction
In a test environment, several people often interact with the test executive software for a variety of
purposes. For example, you may have an operator who runs tests, and an engineer who creates the
tests. This lesson introduces user management in TestStand. You will learn how to use the
TestStand user manager to add users and learn how to customize their privileges.

Lesson 6 User Management
TestStand User Manager

The User Manager includes predefined
user profiles
The TestStand User Manager

TestStand’s user management tool is called the User Manager. To enter the user management
window, click on the User Manager button in the Sequence Editor toolbar or select View»User
Manager. The User Manager has two tabs: User List and Profiles.
To create a new user, click on the User List tab, right-click in the right pane of the user management
window, and select Insert User. Enter user information such as the user name and password in the
dialog box that appears. The new user’s initial privileges are determined by the user profile you
select. This information is updated in the users.ini file in the <TestStand path>\cfg
directory. TestStand maintains a user list to evaluate the user privileges during login.
TestStand has several predefined user profiles. Profiles are default privilege settings. Only users
who have the configure.editUsers privilege, such as administrators, can edit the existing profiles
or create new profiles with specific privilege settings. A profile defines a set of values for the
properties in the User data type. When you create a new user, you initialize the property values for
the new user from a profile. When you edit a profile, it does not affect the privileges of existing
users.

Default User Profiles

Privilege Configure
Operate Debug Develop
Profile Users
Operator YES NO NO NO
Technician YES YES NO NO
Developer YES YES YES NO
Administrator YES YES YES YES
Default User Profiles

The following predefined user profiles are included with TestStand: Operator, Technician,
Developer, and Administrator. The high-level privilege groups associated with each profile are
shown in the table above. The different profiles are examined in greater detail in Exercise 6-1.

Exercise 6-1
Objective: To set user login access and

privileges in the user manager and create a
new profile

Windows System User

TestStand can log the
Windows system user
in automatically
Set this option under

the User Manager tab
of Configure»Station
Options
Windows System Users

You can configure TestStand to automatically login the current Windows system user. This option
is configured under the User Manager tab of Configure»Station Options. If this option is
selected, TestStand checks to see if there is a user configured with the same login name as the
current Windows system user. If there is, this user is logged into the Sequence Editor automatically.
If not, the login dialog is displayed.
Note You must have the user configured in the TestStand User Manager for
TestStand-specific data and privileges to be associated with the user.

Lesson 6 Summary:
User Management
• Create multiple users with different capabilities
• Create a variety of profiles using different
combinations of privileges
• Limit modification of information in the User
Manager to users with the configure.editUsers
privilege
• Configure TestStand to automatically login the
Windows system user
Summary
A test/production environment involves a wide variety of users. For each type of user, TestStand
allows you to provide access-level privileges. You can manage users through the User Manager.
The Users.ini file, in the TestStand\Cfg directory, contains the user list. This is the same
directory in which the file StationGlobals.ini maintains persistent information about station
global variables.
Note Rather than copy the contents of the \Cfg directory to reproduce a test station,
choose Run Engine Installation Wizard under the Tools menu. This wizard prompts
you for the files you want to duplicate from the engine throughout all test stations.

Lesson 6 User Management Exercises
Exercise 6-1 Setting User Login Access and Privileges

Objective: To become familiar with the user manager for adding and configuring users and
profiles and their access privileges.
In TestStand, each user has a set of associated privileges. Privileges restrict
the functionality available to each user in both the Sequence Editor and
operator interface. This exercise introduces the user manager, which is used
to add new users and profiles and set user privileges.
Part A: Creating a New User and Using the User Manager

1. Select File»Login to ensure that the current user is logged in as
Administrator. This menu allows users to log in at any time. Click OK
to continue.
2. Click on the User Manager button in the toolbar or select View»User
Manager. This brings up the User Manager window, as shown below.

3. To insert a new user, right-click in the right pane and choose Insert
User. The following dialog box appears.
4. Type in the user name and password as shown above. The password
selected above is “Joe,” but you can use any password. For now, leave
the user profile as Operator. The user profile assigns a set of default
privileges. The built-in user profiles are Administrator, Developer,
Operator, and Technician. Click the OK button and notice that Joe’s
name appears below the administrator in the user manager. The
following screen should appear.
To create your own user account, repeat steps 3 and 4 and enter the
relevant information.

5. To check the privilege levels for each user, click the + sign next to the
specific user on the left pane to see the different privileges for this user.
The screen below shows the privilege values for the user “Joe.” Notice
that Joe has different privilege values than the Administrator user. Click
the + sign next to “Administrator” to view its privileges.
6. You can set all privileges individually. To configure the privileges,

either double-click on the privilege in the right window or right-click on
the value in the left window and choose Properties. When a value for a
user is changed, the change affects only that specific user.
Note On the tree branches, notice a node labeled Value appears at each level. If this
node is set to True, all subproperties of that branch are considered to be set to True
regardless of their individual setting. When this node is set to False, the individual
subproperty values are in effect. This behavior allows you to grant groups of privileges
by setting a single value to True in the containing privilege.

7. Log in again in the Sequence Editor by selecting File»Login at any time.

Notice that in the pull-down ring control for the Login Name, both
administrator and the user name created in this exercise appear as users.
Before finishing the exercise, be sure to log in as administrator so that
any changes made during this exercise do not affect future exercises.
Note You can always tell who the current user logged on is by looking in the sequence
window. At the bottom there is a display area that lists the current user logged in.
End of Part A
Part B: Creating a New Profile

Part A introduced the concept of a user profile. TestStand allows for the
creation of both a new user and a new profile. As explained in Part A,
TestStand has four default profiles; however, it might be desirable to create
new Profiles. Part B demonstrates how to construct a new profile and
explains how creating a profile and creating a user are different.
1. Part A discussed only the User List tab in the user manager. Click on the
Profiles tab to examine this list. The Profiles tab contains the list of all
currently defined profiles. As mentioned in Part A, TestStand has four
default profiles. Click the + sign next to the Operator and then click the
+ sign next to Privileges to examine the privileges that operators have
by default. The following screen should appear.

2. Do the same for the rest of the Profiles. These are all individually
configurable. To change the privileges, either double-click on the
privilege in the right window or right-click on the key in the left window
and choose Properties.
When you change a profile property, the change affects all new users
who are created using that profile. The change does not affect any users
who have already been created using that profile. Create a profile when
you need to create more than one user with the same privileges. In this
case, it is easier to create a profile with the privileges already configured
and then create each user with that profile. In this exercise, you will
create a new profile called LeadDeveloper and then create a user with
this profile.
3. To insert a new profile, be sure that Profiles is highlighted in the left
pane and right-click in the right pane and choose Insert Profile. This
creates a new profile. Name the profile LeadDeveloper. The screen
should resemble the following diagram. Close the privileges for the
Operator Profile and open the privileges for the LeadDeveloper profile
just created. Notice that by default, a new profile is created with the
same privileges as the administrator profile.

4. One difference between administrators and operators is that operators do

not have full Configure options. The LeadDeveloper will have a few
more of these options, but still not quite as many as the Administrator.
5. In order to remove some of the Administrator privileges from the

LeadDeveloper profile, you first need to set the Privileges»GrantAll
property to False.
6. Click the + sign next to Configure. In the left pane, right-click on
Configure»Properties and change the value to False so that you can
configure the subproperties individually. Click OK to return to the user
manager. The LeadDeveloper should be able to do everything except
edit the users. This means that only the EditUsers property needs to be
changed. In the right pane, double-click on EditUsers and change the
value to False. Click OK to return to the user manager. The resulting
screen should resemble the following image.

7. Click the User List tab again to create a new user. With User List
selected in the left pane, right-click in the right pane and select Insert
User. Fill in the information and notice that the new profile
LeadDeveloper is now available as a Profile to use for this new user.
8. Examine the properties for this new user and notice that the only
property not set to True is the EditUser property. Explore the other
properties and profiles to become familiar with them.

9. Feel free to log on as “Jane” as created in this exercise and test some of
the settings that were modified to verify that the user settings were
correctly modified.
10. When you finish examining the user list and profiles, close the user
manager window by clicking the X at the top right corner of the window.
Be sure to log in as administrator before continuing to the next lesson.
Note You can also change the definition of the user type to create new privilege
properties. Refer to the User Management chapter in the TestStand User Manual for
more information.
End of Part B
End of Exercise 6-1

Notes

Notes

Lesson 7
Lesson 7: Result Collection and

Report Generation
• What, When, and Where of result collection

• Generating reports from collected results
• Report generation features in TestStand
Introduction
In this lesson, you will learn how TestStand collects the test results and how TestStand generates
reports from these results. In particular you will learn which results are collected, when they are
collected, and where the collected results are stored in TestStand. You will also learn how ASCII
text and HTML reports are generated and what formatting options are available in TestStand to
customize reports.

Lesson 7 Result Collection and Report Generation
When and Where Results are Stored

• Results of each test step are stored in the
Locals.ResultList after step executes
• Locals.ResultList is an initially empty array
of containers
When and Where Results are Stored

TestStand automatically collects the results of each step. Each sequence has a ResultList local
variable that is an initially empty array of containers. TestStand appends a new container property
to the end of the ResultList array before a step executes. This container property is called the step
result. After the step executes, TestStand automatically copies the contents of the Result
subproperty for the step (i.e. “Step.Result”) into the appropriate step result container of the
ResultList array.
You can control the result collection option for each step on the Run Options tab in the Step
Properties dialog box. You can control result collection for an entire sequence by going to the
Edit»Sequence Properties dialog. You can enable/disable result recording for all sequences on a
station level from the Execution tab in the Configure»Station Options dialog.

What Results are Stored

Sequence
Step 0 Step.Result
Locals.ResultList (array) Step.TS
Step.*
Step Result [0]
(container) Step 1 Step.Result
Step.TS
Step Result [1] Step.*
(container)
Step n-1 Step.Result

Step.TS
Step Result [n-1] Step.*
(container)
* Indicates other items may be present depending on step type
What Results are Stored

In TestStand, each step type can have a different set of subproperties under its Step.Result
property. Therefore, the Step Result varies according to the step type. TestStand can append
step results that contain Result properties from different step types to the same ResultList
array. When TestStand copies the Result property for a step to its Step Result container, it also
adds information such as the name of the step and its position in the sequence.
In addition to copying step type dependent step properties, TestStand adds a set of standard
properties to each step result. TestStand adds standard result properties to the Step Result as
subproperties of the TS property. These standard result properties include the Start Time, Total
Time, Module Time, Index, Step Name, Step Group, ID, Interactive Execution Number, and
Step Type.

View of Actual Results

• ResultList property indicates that six steps
have stored their results
[0] contains results of step index 0,
[1] contains results of step index 1, …
View of Actual Results

This is an actual view of a Locals.ResultList variable that contains some collected step results. As
mentioned before, each container in the ResultList array stores the results for its respective step in
the sequence. In other words, Locals.ResultList[0] contains the step results for the first step in the
sequence and so on. Notice that within each ResultList container you see several elements such as
the Error container, the TS container, and the Status of the step. You can expand each one of these
containers to reveal more result information for the step.
The above screenshot was obtained by placing a breakpoint on a step in the sequence, executing
the sequence by selecting Single Pass from the execute menu, selecting the Context tab from the
execution display, and expanding the Locals.ResultList container.

Subsequence Results
• Locals.ResultList[x].TS.SequenceCall
• The ResultList of the subsequence is shown below as
a property within the results of a SequenceCall step
Subsequence Results
If a step calls a subsequence or generates a call to a callback sequence, TestStand creates a special
Step Result subproperty to store the result of the sequence. The subproperty name will vary
depending on the type of step that called the subsequence or generated a call to a callback sequence,
for example TS.SequenceCall for a Sequence Call step type or TS.PostAction for a Post
Action callback.
TestStand adds the following properties to the above subproperty for each subsequence called:
• SequenceFile—Absolute path of the sequence file that contains the subsequence.
• Sequence—Name of the subsequence that the step called.
• Status—Status of the subsequence that the step called.
• ResultList—Value of Locals.ResultList for the subsequence that the step called. This
property contains the results for the steps in the subsequence.
The ResultList of the subsequence is passed back up to the calling sequence. Therefore, the
ResultList of your top level test sequence is conveniently passed back to the process model
sequence (i.e. Test UUTs or Single Pass) that called the MainSequence of your test sequence.
The importance of this is explained in the following slides.

Formatting Results into a Report
Process Model Report Header

(Reportgen_xxx.seq)
Test UUTs/Single Pass
Report Body
Test Report Callback
Test Report (ModelSupport.dll)
ResultList[0] Sequence
Report Footer
(Reportgen_xxx.seq)
Formatting Results into a Report

The TestReport sequence is a model callback that the execution entry point sequences (i.e. Test
UUTs/SinglePass) call to generate the contents of the test report for each UUT. The default process
model defines a test report for a UUT consisting of a header, an entry for each step result, and a
footer.
TestStand has two options available for creating the report body, the DLL option and the sequence
option. If the DLL option is selected, the TestReport sequence calls a single function in
modelsupport.dll to build the entire report body before returning. The LabWindows/CVI
project and source code for this DLL is available in the
TestStand\Components\NI\Models\TestStandModel directory. The DLL option is
selected by default, allowing TestStand to generate reports faster. However, when using the DLL
option, the ModifyReportEntry callback is not executed.
If the sequence option is selected under the Configure»Report Options tab, the TestReport
sequence calls the AddReportBody sequence in either reportgen_txt.seq or
reportgen_html.seq to build the report body. The sequence report generator uses a series of
sequences that recursively process the contents of the ResultList parameter.

Report Configuration Options

Available options include:
– Report format (ASCII text or HTML)
– Option to include certain result elements
– Insert arrays as tables or graphs in report
– Result Filtering (ex, only report steps that fail)
– Numeric formatting
– Report color schemes (HTML only)
– Report file pathname(s)
– Ability to create separate reports for each UUT
Report Configuration Options

There are many report attributes that can be configured in TestStand to fit most report formatting
needs. These attributes can be configured in the Report Options dialog box. The Report Options
dialog box is opened by selecting Configure»Report Options as shown on the next slide.

Report Options Dialog Box:

Contents Tab
Report Options Dialog Box: Contents Tab

You can launch the Report Options dialog box by selecting Configure»Report Options. There are
two tabs in the Report Options dialog box: Contents and Report File Pathname. From within the
Contents tab you can configure report properties such as which result elements are included in the
report, the report format (ASCII or HTML), report color options, whether to include all test results
or just results that fail, whether you wish to insert array(s) of data into the report as a table or graph,
and the formatting of numeric data. There is also the option of which method to use to generate
the report body; the sequence method or the DLL method. By default, reports are generated by the
DLL method since it is the faster method. Unless your report body is rather large you will probably
not notice a difference in the amount of time it takes for the sequence option or DLL option to
generate the report body.

Report Options Dialog Box:

Report File Pathname tab
Report Options Dialog Box: Report File Pathname Tab

From within the Report File Pathname tab you can configure report properties pertaining to the
file pathname that TestStand uses to save the report to disk. There are two options in respect to
the report file pathname that is used: Generate Report File Path and Specify Fixed Report
File Path.
If the Generate Report File Path option is selected, TestStand will concatenate the report file
pathname to use at run-time based on the available options selected. Some of these options involve
whether to include the sequence file name, time, date, or UUT serial number in the pathname. You
can also select a base report name to be used in every report file pathname that is generated, as well
as specify whether to force each file name to be unique. Some of the options will vary depending
on which process model is being used.
If the Specify Fixed Report File Path is chosen then you enter a fixed report file pathname that
TestStand will always use when saving report files to disk.

Inserting Message in Report
Inserting Message in Report

Each default step type has a ReportText subproperty. This subproperty can be found under the
Step.Result.ReportText lookup string. Any string that is written to the
Step.Result.ReportText will automatically be included in the TestStand report. An example
of this is shown above where the message “Insert Report Text Message Here” is a string that was
written to the Step.Result.ReportText property for the Statement step shown, i.e.
Step.Result.ReportText = “Insert Report Text Message Here”.
There are several ways you can specify the ReportText message string. One method is to set the
string value from within an expresion box inside the step that you want to associate with ReportText
in the report.
Another method is to set the value of the message string directly in your code module. The C/CVI
and LabVIEW module adapters allow code modules to set this property by modifying the
corresponding member of the test data structure or cluster. Refer to Chapter 12, Module Adapters,
of the TestStand User Manual for more information on the property assignments that the module
adapters automatically perform to and from step properties.

Configuring the Report Viewer

TestStand allows external report viewers such
as Word, Netscape, or Internet Explorer
Using an External Report Viewer from TestStand

You may prefer to view the test report in an external program, such as Microsoft Word, Netscape,
or Internet Explorer. You can configure this option by selecting Configure»External Viewers to
specify the application that TestStand launches to display the report.
You can then use the external application to view reports by selecting the View»Launch Report
Viewer command when an Execution window is active.

Exercise 7-1
Objective: To demonstrate the options for
configuring report generation in TestStand

Lesson 7 Summary
• Results are stored in Locals.ResultList

• Each step has its own results container
• Subsequence results are passed up to
calling sequence
• ResultList parameter sent to TestReport
sequence in process model
• TestReport sequence formats results into a
report
• There are many report formatting options
available
Summary
In this lesson, you learned how the result collection and report generation is handled in TestStand.
In particular, you learned that results from each step are collected and placed into their respective
Locals.ResultList container as soon as the step has finished executing. You also learned that the
contents of each step result container in the ResultList will contain the Step.Result and Step.TS
properties of the step. Other step properties may also be placed in the step result container of the
ResultList but vary from step type to step type. We then discussed how the subsequence results are
passed back up to the calling sequence and how this is what eventually enables all of the results
from your test sequence to be returned to the process model (original calling sequence). Once the
results are returned to the process model upon completion of your test sequences they are sent to
the TestReport sequence. The TestReport sequence formats all of the results into a report. The
format of the report that the TestReport sequence generates can be configured by using the many
options available in the Report Options dialog box obtained by selecting Configure»Report
Options.

Lesson 7 Result Collection and Report Generation Exercises
Exercise 7-1 Customizing Report Generation

Objective: To demonstrate the built-in options for customizing report generation in TestStand.
By default, TestStand is configured to generate reports after the execution of

a test sequence. The report format is determined by the user defined Report
Options, which may vary depending on the process model that is being used.
This exercise demonstrates some of the report generation options available
in TestStand.
Part A: Report Options for the Sequential Process Model

The process model defines how the report will be generated. Thus the report
options will change depending on the process model used, reflecting the
functionality of each process model. In this part of the exercise you will
examine the report options available when using the Sequential Process
Model.
1. In the Sequence Editor, select Configure»Report Options from the
menu. You will see the following dialog box.

2. You can use this dialog box to select the types of information to add in
the test report; including the measured values, test limits, execution
times and array data of each step. The array data can be formatted as a
table or as a graph. There is also an option for appending information to
an existing file.
Note In order to record array data into the report, the array must exist within the
Locals.ResultList container and the appropriate flags must be set. These features
are covered in further detail in the TestStand II course.
The Report Format selector allows you to select either an ASCII text file
or HTML format.
The Result Filtering Expression allows you to select the type of

information from the sequence execution to include in the report. You can
choose to include information from all tests or just from the tests that either
passed or failed. You can even enter your own filtering expression to fit your
needs. For example, if you want to include in the report only the steps that
Failed and the ones that were Skipped you can type in the following
expression:
Result.Status = = "Failed" || Result.Status = = “Skipped"
The Default Numeric Format field allows you to select the format of all
numeric data in your report. You can customize this format by clicking the
Edit Format button. You should see the following dialog.

Click OK to close this dialog.

3. Click the Report File Pathname tab. You will see the following
dialog box.

This dialog box specifies the report file pathname information. You can
have the report generated as a temporary file or specify the file to be
saved to disk.
• Generate Report File Path—Select this radio button if you want
the report generator to create pathnames automatically. When you
select Generate Report File Path, you can use the controls in the
Generate Report File Path section of the tab.
• Use Temporary File—Enable this option if you want to write the
report to a temporary file. The report generator deletes the file when
you close the Execution window. Enable this option if you do not
want to save your test report after you close the Execution window.
The default setting for the Directory is the Client Sequence File
Directory, which means the report is saved in the same location as the
sequence file. Click on the selector ring to see the other options for
saving the file to a specific location. Below the Base Name option are
several options for including the Sequence name as a prefix in the
filename, adding the time and date to the filename and forcing a unique
filename. The Append UUT Serial Number to UUT Report File

Name option creates a new file for each UUT in contrast of creating one
file for all UUTs.
This dialog also provides a field that displays the report name, based on
the current selections. This should give you a good idea of what the final
file name will be. It also provides a graphical indicator to illustrate how
the options you select affect the names and contents of the report files.
This helps visualize if the file will contain one or more UUTs as well as
the order in which the UUTs are stored in the report.
At the bottom of the dialog box is an option to specify a fixed path for
all generated reports.
4. Click OK to close the dialog. Open the sequence file located at
C:\TestStand\Examples\Demo\C\Computer.seq. Run the
sequence using either the Test UUTs or Single Pass entry points and
analyze the report.
5. Launch the Report Settings dialog box by selecting Configure»Report
Options from the menu and select different options for creating
different types of reports. View the reports to see the effects of the
changes implemented.
End of Part A
Part B: Report Options for the Parallel Process Model

The Parallel Process model can generate a report for all tested UUTs, an
individual reports for each UUT as well as a report for each test socket.
1. In order to illustrate the report options available with the Parallel Process
Model, you must first enable the Parallel Process Model to be the default
process model within the TestStand environment. To do this, select
Configure»Station Options. Click on the Model tab. From the Station
Model ring, select the ParallelModel.seq. Click OK to close this
dialog.
2. Next, examine the various report options available with this process
model. Select Configure»Report Options from the menu. The
Contents tab is exactly the same as the one in Sequential Process
Model. Click the Report File Pathname tab. You will see the following
dialog box.

This dialog allows the options for creating one report for all the parallel
UUTs, one report per test socket or an individual report for each UUT.
Many of the options for the Parallel Process Model are similar to those
included with the Sequential Process Model. The main differences are:
• Append UUT Serial Number to UUT Report File Name -
checking this option forces the creation of a separate report file per
each executed UUT.
• Append Test Socket Index to UUT Report File Name – checking
this option forces the creation of a separate report file per test socket.
• If both options are checked, separate report files are created for each
UUT. The name of the file will contain the test socket number
• If no option is checked, one report file for all UUTs will be created.
The Report Options dialog box provides a graphical indicator to
illustrate how the options you select affect the names and contents of the
report files.

3. Click OK to close the dialog. Again, run the demo test sequence,
C:\TestStand\Examples\Demo\C\Computer.seq using either
Test UUTs or Single Pass entry points and analyze the report(s).
4. Launch the Report Settings dialog box and select different options for
creating different types of reports. View the reports to see the effects of
the changes implemented.
End of Part B
Part C: Report Options for the Batch Process Model

The Batch Process model can generate a report for all tested UUTs, an
individual reports for each UUT, reports for each test socket and reports for
a given batch.
1. Select Configure»Station Options. Click on the Model tab. From the
Station Model ring, select the BatchModel.seq. Click OK to close this
dialog.
2. Select Configure»Report Options from the menu. The Contents tab is
exactly the same as the one in the Sequential Process Model and the
Parallel Process Model. Click the Report File Pathname tab. You will
see the following dialog box.

When you use the Batch process model, the Report File Pathname tab
on the Report Options dialog box contains additional controls that
designate the files into which TestStand stores batch reports. In
combination with the controls for UUT reports, you can use the batch
controls to specify that all batch and UUT reports reside in the same file,
that all reports reside in individual files, or you can specify other
intermediate configurations. The Report Options dialog box provides a
graphical indicator to illustrate how the options you select affect the
names and contents of the report files.
3. Click OK to close the dialog. Again, run the demo test sequence,
C:\TestStand\Examples\Demo\C\Computer.seq using either
Test UUTs or Single Pass entry points and analyze the report(s).
4. Launch the Report Settings dialog box and select different options for
creating different types of reports. View the reports to see the effects of
the changes implemented.
End of Part C

Note For future exercises, make sure you configure TestStand back to its default process
model setting, the Sequential Process Model. To change the default model, click on the
Configure»Station Options menu and select the Model tab. Select the
SequentialModel.seq file from the Station Model ring. Click OK to close the
dialog.
End of Exercise 7-1

Notes

Notes

Lesson 8
Database Interaction
Lesson 8: Database Interaction

• Logging test results to a database
• Configuring the database logger
• Using the database step types
Introduction
Similar to generating reports, TestStand can log UUT results and step results to a database. This
lesson discusses the database interaction features in TestStand. You will learn how to log results to
a database and how to configure the Database Logger. You will also learn how to use the database
step types to interact with the databases.

Lesson 8 Database Interaction
Database Concepts
The table below shows an example of the following
database concepts:
• Database
• Tables
• Records (rows)
• Fields (columns)

!"
# $%
&' #
&' !"
Database Concepts
In order to better understand how TestStand interacts with databases you must first become familiar
with key database concepts. The database, table, record, and field concepts are illustrated using the
image shown above.
• Database—An organized collection of data. You can store data in and retrieve data from a
database. The data is usually stored in a table as defined below.
• Table—Most modern Database Management Systems (DBMS), also called database servers,
store data in table form. There can be multiple tables in a database. Each table in a database
must have a unique name.
• Record—Analogous to a row in a matrix. The term, record, is often interchanged with the term,
row, since they are similar in meaning.
• Field—Similar to a column in a matrix. Each field in a database table must have a unique name.
In the example above shows results from a test sequence. The fields (columns) are UUT_NUM,
STEP_NAME, RESULT, and MEAS. Each record or row represents a different unit under test
(UUT). Some entries in the MEAS field hold a NULL value. This empty field value is also referred
to as an SQL Null value.

Structured Query Language (SQL)

• SQL is a widely supported standard for
database access
• Useful SQL commands:
– CREATE TABLE
– SELECT
– INSERT
– UPDATE
– DELETE
Structured Query Language (SQL)

SQL commands are supported by most major Database Management Systems (DBMS). You can
use SQL commands to manipulate the rows and columns in database tables. TestStand uses SQL
commands exclusively in communicating with databases. They are used to create the required
default tables, and to log UUT results and step results to a database table. They are used in all five
built-in TestStand database steps.
• CREATE TABLE—Creates a new table specifying the name and data type for each column.
• SELECT—Retrieves all rows in a table that match specific conditions.
• INSERT—Adds a new record to the table. You can then assign values for the columns.
• UPDATE—Changes values in specific columns for all rows that match specific conditions.
• DELETE—Deletes all rows that match specific conditions.
For additional explanation of SQL commands, operators, and functions, see the SQL section of the
TestStand User Manual. This version of SQL is included in the ODBC standard and applies to all
ODBC-compliant databases.

Database Interface Technologies

• ActiveX Data
Objects (ADO)
• Object - Linking
and Embedding
Database
(OLE DB)
• Open Database
Connectivity
(ODBC)
• Data Link -
Specific connection information
for accessing the data source
Database Interface Technologies

Microsoft has integrated several database interface technologies into the Windows operating
system. TestStand uses ActiveX Data Objects (ADO), as its main database client technology.
Microsoft built ADO on top of an object-linking and embedding database (OLE DB). Applications
that use ADO, such as TestStand, use the OLE DB interfaces indirectly. The OLE DB layer
interfaces to databases directly through a specific OLE DB Provider for the DBMS, or through a
generic open database connectivity (ODBC) Provider which interfaces to a specific ODBC driver
for the DBMS. The figure above shows some of the high-level relationships between TestStand and
components of the Windows database technologies.
Before you can access data from within TestStand, you must provide a data link which contains
information about the database interface. This could include the provider, the server on which the
data resides, the database or file that contains the data, the user ID, and permissions to request when
connecting to the data source. This will be discussed later in more detail.

Database and Database Drivers

• DBMS supported by default:
– Microsoft Access
– Microsoft SQL Server
– Oracle
• Support for other DBMS can be added by
installing drivers to communicate with your
DBMS
– ODBC driver»Data source name (DSN)
– Specific OLE-DB Provider
Database and Database Drivers

By default, TestStand supports Microsoft Access, Microsoft SQL Server, and Oracle. If you decide
to use another DBMS, see Adding Support for Other Database Management Systems in the
Database Component Manual. Although by default TestStand supports the above DBMS, the
drivers for these systems are not installed by TestStand, nor can they be distributed to target
machines by TestStand. You may need to consult the individual DBMS references to install the
necessary drivers before TestStand can communicate with the DBMS.
You must decide whether to use an ODBC driver or a specific OLE-DB Provider for your DBMS.
Refer to the TestStand\Doc\readme.txt for suggested versions of client DBMS software.
When using the Microsoft OLE DB provider for ODBC Drivers to connect to an ODBC data
source, you must first configure a data source name (DSN) within the ODBC Administrator
available through the Window Control Panel. This is covered in Exercise 8-1. The DSN specifies
which ODBC driver to use, the database file (.mdb), and the optional user ID and password.
If you are using a specific OLE-DB Provider for your DBMS then you can link directly to the
corresponding database from within TestStand.

Configuring Database Options

Configure»Database Options»Logging Options
Configuring Database Options: Logging Options

Once you have created your database and, if necessary, your data source name (DSN), select
Configure»Database Options to configure the database options. TestStand executes the
Configure Database Options configuration entry point (purple icon) in the process model.
The Logging Options tab in the Edit Database Logging Options dialog box allows you to choose
whether the test results are logged to a database. As previously explained in the section on
configuring report options (Configure»Report Options), you can also specify what default step
data is logged to the database. This includes adding filtering expressions to add inclusion criteria
for database logging.


Configure»Database Options»Data Link
Configuring Database Options: Data Link

Use the Data Link tab in the Edit Database Logging Options dialog box to select which DBMS
you wish to use and provide the required database connection information.
With the Connection String Expression control you can directly specify the connection string
expression that TestStand uses to open a data source in which to log results. It can be a literal value
enclosed in quotations, or it can be an expression that is evaluated at run-time. You can use the
Browse button to create the expression. You can also use the Build button to construct the
connection string using the Data Link Properties dialog box. Refer to the Data Link Properties
Dialog Box section in the Database Component Manual for more information.
An example connection string is shown above. This string can be stored in a Microsoft Data Link
(.udl) file. You can use this file later by selecting the Find File button to point to the file. If you
are using a Microsoft Data Link (.udl) file for the connection information, the Connection String
Expression will contain the file path and name of the file, for example, "FILE
NAME=C:\\Program Files\\Common Files\\System\\OLE DB\\Data
Links\\Access.UDL"


Configure»Database Options»Schemas
Configuring Database Options: Schemas

Select the schema you wish to use in the Schemas tab in the Edit Database Logging Options dialog
box. A schema consists of a list of statements that indicate to TestStand which tables the results
should be logged to. The Statements tab, which is discussed next, contains the statements
corresponding to the selected schema. You can add and remove schemas from this tab as well as
indicate whether the schemas can be modified.


Configure»Database Options»Statements
Configuring Database Options: Statements

Define the statements associated with the previously selected schema in the Statements tab in the
Edit Database Logging Options dialog box. Statements define the type of results they operate on
and the conditions that must be true before they can operate. Statements also define the database
action to perform. In addition, statements can specify the data properties to log, and the table
columns to log to. The list of statements can be found in the box on the left side of the tab. After
selecting a statement, the control settings of that statement are shown on the right side of the tab.
• Name—Edits the name of the statement
• Type—Specifies the type of statement
• Command Text—Text of a command that the statement issues against the data link
• Apply To—Specifies the class of results that the statement operates on
• Types to Log—Indicates the step type(s) that the statement pertains to
• Expected Properties—Specifies which properties the statement uses
• Precondition—Expression that must evaluate to true before TestStand applies the statement to
a particular result
• Cursor Type—Type of cursor for the record set the statement returns
• Cursor Location—Specifies where the data source maintains cursors for a connection
• Lock Type—Specifies when the data source locks a record


Configure»Database Options»Columns/Parameters
Configuring Database Options: Columns/Parameters

The Columns tab in the Edit Database Logging Options dialog box is used for Record Set
statements. From the Columns tab you specify the columns that the statement writes to in the new
record that the statement inserts. Specify the data value to write for each column.

Logging Property
• Contains information about:
• Database settings
• Process model data structures
• Results database logger processes
• Uses logging sub-properties in precondition and
value expressions that you specify for a
statement
Logging Property
When the database logger starts, it creates a temporary property named Logging in the sequence
context in which it evaluates expressions. The Logging property contains sub-properties that
provide information about database settings, process model data structures, and the results that the
logger processes. As logging progresses, the logger updates sub-properties of Logging to refer to
the step result or measurement the logger is processing. You can reference Logging sub-properties
in the precondition and value expressions that you specify for a statement. For more detail about
the Logging sub-properties, please see the TestStand User Manual.

Default Schema: Generic Recordset

• UUT_RESULTS: Overall UUT test results
• STEP_RESULTS: Overall test step results
• STEP_<Step Type>: Step type specific results
• MEAS_IVI_<Meas Type>: Measurement

specific results
Default Schema: Generic Recordset

The default schema for logging results to an Access database uses two main tables,
UUT_RESULTS and STEP_RESULTS, to store the overall results for each UUT and the overall
results for each test step. The UUT_RESULTS table contains information such as the overall
pass/fail value, the start time, and operator. The STEP_RESULTS table contains information about
the common types of step result properties such as the step name, the pass/fail status of the step,
and module time.
The default database logger in TestStand uses other tables to store the more detailed step
information that pertains to certain step types. This additional step information is stored in the
following tables:
STEP_NUMERICLIMIT MEAS_IVI_SINGLEPOINT
STEP_STRINGVALUE MEAS_IVI_WAVE
STEP_MSGPOPUP MEAS_IVI_WAVEPAIR
STEP_CALLEXE
STEP_SEQCALL
STEP_PROPERTYLOADER
The schema design described above provides efficient use of the database tables and makes it more
suited for accommodating new types of step results. It also allows the database logger to record
step results that contain a varying number of similar measurements. See the TestStand User
Manual for a list of the names, data types, and descriptions of each column in the tables mentioned
above.

Creating Default Database Tables

• SQL Script files for easily creating tables
– Creates required tables for specifed schema
– Scripts for Access, Oracle and SQL Server
(i.e. Access Create Generic Recordset Result
Tables.sql)
• Use Database Viewer

– Select SQL script (*.sql)
– Select GO button
– Tables easily created
Creating Default Database Tables

TestStand includes the Database Viewer application for viewing data in a database table, editing
table information, and executing Structured Query Language (SQL) commands. You can use the
Database Viewer to create the default result tables that the default schemas require. To use the
Database Viewer application you must setup the DBMS server and any required DBMS client
software.
TestStand comes with SQL script files for creating and deleting the default database tables that the
schemas require. These script files are located in the TestStand\Components\NI\Model\
TestStandModel\Database directory.

Database Viewer
• Designed for:
– Executing SQL commands
– Viewing data
– Editing data
• Views:
– Data Link
– Execute SQL
– Data View
Database Viewer
The Database Viewer is a useful tool for creating, editing, or viewing database tables and data.
This tool can be launched from either the VIEW button on the Data Link tab in the Edit Database
Logging Options dialog box or from the Tools»Run Database Viewer menu selection. There are
three different windows used within the viewer:
• Data Link window—Contains a tree view of existing tables. The list view displays the
contents of the currently selected node in the tree view. Context Menus can be accessed here
by right-clicking on a table in the tree view. These menus include View Data, which displays
table data in a Data View window, Add Table, Drop Table, Add Column, and Drop Column.
You can use these to view or customize your database.
• Execute SQL window—Contains an SQL Commands and an SQL History control. Enter
SQL commands directly and execute using the Go icon button. Or, load SQL script files by
clicking the Open File icon button. Use the Clear icon button to delete the contents from the
SQL Commands control.
• Data View Window—Contains a data grid control of the data returned from an SQL
command. Database Viewer automatically opens a new Data View window when you use
the View Data context menu command or when you issue an SQL command that returns a
record set.

Exercise 8-1
Objective: To log UUT test results to a

Microsoft Access Database

Summary: Database Logging in TestStand

Required steps before database logging
in TestStand can occur:
• Install drivers to communicate with your
Database Management System (DBMS)
• Create a database (and DSN when required)
• Configure the Database Logging Options
within TestStand
• Create default tables

Database Step Types

Database Step Types Database Actions
5 Built-in 5 Basic
Step Type Action

• Open Database Connect to a database
• Open SQL Statement Select data within a database table
• Data Operation Statement Perform operations on selected data
• Close SQL Statement Close references to the table
• Close Database Disconnect from the database
Database Step Types

There are typically five basic database actions that are needed when interacting with a database
from within a test sequence. TestStand has five corresponding, built-in database step types that
allow you to use these step types to write a sequence that communicates with a database. The five
steps types are Open Database, Close Database, Open SQL Statement, Close SQL Statement,
and Data Operation. A simple database interaction sequence might include the following steps:
• Connect to the database using the Open Database step
• Issue an SQL query on tables in the database using the Open SQL Statement step
• Create new records, and get and update existing records using Data Operation steps
• Close the SQL query using the Close SQL Statement step
• Close the database connection using the Close Database step

Open Database Step Type
Open Database Step Type

The Open Database step type opens a database for use in TestStand. An Open Database step returns
a database handle (number) that you can use in an Open SQL Statement step.
The Data Link dialog box is very similar to the previously discussed Data Link tab that is available
when you select Configure»Database Options. The only difference is the Database Handle
control, which is used to specify the name of a variable or property of type Number to which you
assign the returned value of the database handle.
The Open Database step type has the property Step.ConnectionString, which specifies a
string expression that contains the name of the data link to open. Step.DatabaseHandle
specifies the numeric variable or property to which the step assigns the value of the opened
database handle.

Open SQL Statement Step Type
Open SQL Statement Step Type

After you open a database, use the Open SQL Statement step type to select a set of data in the
database with which to work. Using the SQL command SELECT in the SQL Statement control
returns a statement handle to your selected data, after which you can perform multiple operations
on that data set using Data Operation step type that will be discussed next.
• Database Handle—Specifies the variable or property that contains the database handle you
obtain from an Open Database step type.
• Statement Handle—Specifies a variable or property to which the step assigns the value of the
SQL statement handle. If you leave the control blank, the step automatically releases the SQL
statement handle after executing the step.
• SQL Statement—Specifies the SQL statement that the step opens. You can specify the SQL
statement as a literal string or as an expression that TestStand evaluates at run-time. You can
use the Build button to construct an SQL SELECT statement. The Build SQL Select Statement
dialog is discussed next.
• Number of Records Selected—Specifies a variable or property of type Numeric to which the
step assigns the number of records that the SQL statement returns.
Note The Advanced tab specifies optional attributes that TestStand sets when opening
an SQL statement. In most cases, the database defines default values for each attribute.
See the TestStand User Manual for more details about the Advanced tab.

Open SQL Statement:

Build SQL Select Statement Dialog Box
Open SQL Statement: Build SQL Select Statement Dialog Box

The SQL commands you can use with the Edit Open SQL Statement are SELECT, CREATE
TABLE, DELETE, DROP TABLE and INSERT. The most common SQL command used in the
Edit Open SQL Select Statement is SELECT. You can use the Build SQL Select Statement dialog
box to construct an SQL SELECT statement expression.
• Data Link Name—After selecting a data link, TestStand automatically updates the Table and
Column ring controls in the Add/Remove Columns section.
• Add/Remove Columns—Select the tables and columns to include in the SQL select statement.
TestStand populates the Table ring control with the tables that the selected data link defines.
When you select a table in the Table control, TestStand populates the Column ring control
with a list of all columns in the table. If you want to select all columns in the SQL statement,
choose the * item in the Column control.
• You can use the Add button to insert the selected table and column into the Table and Column
list control. You can remove an item from the list control using the Remove button. You can
also reorder the items in the list control by selecting an item and clicking on the up or down
arrow icon buttons.
• Where Clause—Includes an SQL WHERE in the SQL statement. You can specify a literal
string or an expression that TestStand evaluates at run-time. This is used to search the database
for a specific entry or entries.

Data Operation Step Type
Data Operation Step Type

The Data Operation step performs operations on the handle returned by an Open SQL Statement
step. With the Data Operation step you can fetch new records, retrieve values from a record, modify
existing records, create new records, and delete records.
The controls for the Record/Operation tab are described below:

• Statement Handle—Specifies the name of the variable or property of type Number that
contains the SQL statement handle on which to operate.
• Record to Operate On—Specifies whether the step operates on the current record, fetches a
new record, or creates a new record. The ring control contains the following options:
– New—Creates a new record and operate on this new record
– Current—Operates on a record you previously fetched or created
– Next—Fetches the next record for the SQL statement
– Previous—Fetches the previous record for the SQL statement
– Index—Fetches the record with the index you specify in the Record Index control. The
Record Index control contains a literal numeric value or a numeric expression that
TestStand evaluates at run-time.

Data Operation Step Type (Continued)

• Operation—Specifies the operation the step performs on the selected record. The ring control
contains the following options:
– Fetch—No operation is performed on this record.
– Set—Sets the values of the selected record. The Column Values control contains the name
of a variable or property that lists the assignments the step performs. Refer to the Column
Values tab discussion later in this section for more information. Multiple Set commands
can be issued successively, but they must be followed by a Put command (see Put below).
– Get—Gets the values from the selected record. The Column Values control contains the
name of a variable or property that lists the assignments the step performs. Refer to the
Column Values tab discussion later in this section for more information.
– Put—Necessary for updating the selected record with any pending changes to its values
that were made with one or more Set commands.
– Delete—Deletes the selected record from the database.
– Set and Put—Equivalent to a Set followed by a Put as described in the previous options.
• Column List Source—Specifies the name of the variable or property that contains the column
values the step gets or sets. The named property must be an array of type
DatabaseColumnValue.


The Column Values tab applies only to Get, Set, and Put operations that you perform in a Data
Operation step. You can use the Column Values tab to specify the mapping between SQL columns
and TestStand variables and properties. For a Get operation, a mapping between a column and
variable or property instructs TestStand to assign the column value to the variable or property. For
a Set operation, a mapping between a column and a variable or property instructs TestStand to
assign the value of the variable or property to the column. The Column Values control on the
Action tab specifies a variable or property that stores this mapping.
• Data Link Name—Contains the name of the data link to open and query to populate the
Column Name ring control. You can use the Select Data Link button to select a predefined data
link from a list. Refer to the TestStand User Manual for more information on predefining data
links.
• SQL Statements—Specifies the SQL statement the dialog box uses to populate the Column
Name ring control. The ring control contains a list of the Edit Open SQL Statement steps in the
current sequence file. When you select an item in the ring, TestStand updates the SQL
Statement string control with the SQL statement the step uses. TestStand can populate the
Column Name control only if the selected SQL statement step uses a literal string or a valid
expression.


• Column Values—Specifies the mappings of column names to variables or properties that the
step uses. The list control contains the specified mappings. The Column Name, Values, and
Format String controls specify the settings for the currently selected mapping. Use the New,
Cut, Copy, and Paste buttons to create a new item in the list, remove items from the list, and
rearrange the items in the list. Use the Browse button to display the Expression Browser dialog
box.
When the Edit Data Operation step performs a Get operation, the Value control must contain the
name of a variable or property. When the Data Operation step performs a Put operation, the Value
control can contain a literal value or an expression that TestStand evaluates at run-time.
The Format String control specifies how to convert a string value when assigning a string
expression to a column, or when assigning the value of a column to a string variable or property.
Typically, you use this control when getting or setting data from a column that is of the date-time
or currency type. Refer to the TestStand User Manual for a list of format strings.

Close SQL Statement Step Type

Use the Close SQL Statement step to close an
SQL statement handle that you obtain from an
Open SQL Statement step.
Close SQL Statement Step Type

The Edit Close SQL Statement dialog box contains a single control, Statement Handle. This
control specifies the name of the variable or property of type Numeric that contains the statement
handle to close. After closing the statement handle, the step assigns a value of zero to the variable
or property.
The Close SQL Statement step type defines the following step property in addition to the common
custom properties.
• Step.StatementHandle—Specifies the name of the variable or property of type Number
that contains the SQL statement handle to close.
Note TestStand does not automatically close SQL statement handles. You must call a
Close SQL Statement to close your open handles when you are through with them. If you
abort an execution, you must exit the application process that loaded the TestStand engine
to guarantee that TestStand frees all database handles. Selecting Unload All Modules
does not close the handles.

Close Database Step Type

Use the Close Database step to close the
database handle that you obtain from an Open
Database step.
Close Database Step Type

The Edit Close Database dialog box contains a single control, Database Handle. This control
specifies the name of the variable or property of type Number that contains the database handle to
close. After closing the database handle, the step assigns a value of zero to the variable or property.
The Edit Close Database step type defines the following step property in addition to the common
custom properties.
• Step.DatabaseHandle—specifies the name of the variable or property of type Number that
contains the open database handle to close.
Note TestStand does not automatically close open database handles. You must call a
Close Database step to close your open handles when you are through with them. If you
abort an execution, you must exit the application process that loaded the TestStand engine
to guarantee that TestStand frees all database handles. Selecting Unload All Modules
does not close the handles.

Exercise 8-2
Objective: To create a Microsoft Access

database session using built-in TestStand
database step types

Summary: Database Step Types

There are five basics actions in a database session, and
there are five corresponding built-in database step types.
Step Type Action

•Open Database Connect to a database
•Open SQL Statement Select data within a database table
•Data Operation Statement Perform operations on selected data
•Close SQL Statement Close references to the table
•Close Database Disconnect from the database
Summary
A simple sequence of database steps might include the following steps:
• Connect to the database using the Open Database step
• Issue an SQL query on tables in the database using the Open SQL Statement step
• Create new records, and get and update existing records using Data Operation steps
• Close the SQL query using the Close SQL Statement step
• Close the database connection using the Close Database step

Lesson 8 Database Interaction Exercises
Exercise 8-1 Logging UUT Results to Database

Objective: To create a Microsoft Access database with tables, log UUT results to the tables, and
view these entries from within TestStand.
This exercise outlines how to setup a TestStand data link to a Microsoft

Access database file (*.mdb) to log results using the default sequential
process model. The exercise uses the OLE DB provider for ODBC and the
Microsoft Access ODBC driver to connect to the data source. When
accessing a database using an ODBC driver, a Data Source Name (DSN)
must be created. This can be accomplished using the Windows ODBC Data
Source Administrator.
Part A: ODBC Data Source Administrator

In this section, you become familiar with the ODBC Data Source
Administrator by creating a DSN and the corresponding database. Before
you setup a TestStand data link to an Access database you must:
• Verify that the Microsoft Access ODBC Driver is installed on your
system
• Setup an ODBC Data Source Name (DSN), and
• Create a corresponding database file
1. Open the ODBC Data Source Administrator. From the Windows
Start menu, select Settings»Control Panel and double-click on the
ODBC icon. The ODBC Data Source Administrator dialog box appears
as shown.

2. Verify that the Microsoft Access ODBC driver is installed on your

system by selecting the Drivers tab and finding the Microsoft Access
driver listed in the list of ODBC drivers as shown.

3. Create a new data source by selecting the User DSN tab and clicking on
the Add button to display the Create New Data Source dialog box.
4. Select the Microsoft Access Driver from the list and click the Finish
button. The Create New Data Source dialog box appears as shown.

5. In the ODBC Microsoft Access Setup dialog box, enter the name
TestStand Access into the Data Source Name control.
Select the Create button in the Database section of the preceding image.
6. In the New Database dialog box, navigate to
C:\Exercises\TestStand I and enter the database file name
Sequence Data.mdb as shown. Select OK to close the dialog box. You
will be informed that the database was created successfully.

7. Select OK to close the ODBC Microsoft Access Setup dialog box.

8. Select OK to close the ODBC Data Source Administrator dialog box.
Note The steps you performed in this part of the exercise are only for creating a data
source name and a database file. Once you have created these items once on your system,
you do not have to perform these steps everytime you want to log results to database in
TestStand.
End of Part A
Part B: Database Options

After you create the ODBC data source, you must configure the database
logging options in TestStand. To utilize the database logging features in
TestStand you must enable the database logging feature and configure
certain parameters. This process is described below.
1. From within the Sequence Editor, select Configure»Database Options
to display the Database Options dialog box.
2. Remove the check mark from the Disable Database Logging option on
the Logging Options tab. Once you have removed the check mark, the
remaining options on this tab will be enabled. These options can be
configured in much the same way as the report options were.

3. Select the Data Link tab. This is the tab where you create a data link for
Teststand to use to identify the data source name and database you wish
to log your results to.
4. Verify that Access is selected for the Database Management System to
use. Select Build to create the Connection String Expression. In the
Provider tab of the Data Link Properties dialog, select Microsoft
OLE DB Provider for ODBC Drivers. From the Connection tab,
select the TestStand Access data source name from the ring selector.
Select the Test Connection button to verify that the connection can be
established properly using your data source name that you specified.
Select OK to close the dialog with your changes.
5. The Connection String Expression should automatically be updated

after closing the previous window. The Data Link tab should now
resemble the following image.

6. Select the Schemas tab. Select the Generic Recordset (NI) schema
from the list of schemas.

7. Since you are using the default Generic Recordset (NI) schema you
will not need to configure the remaining two tabs. The Statements tab
is used for specifying which tables will be used in the database. The
Columns tab is used for specifying what data will be logged to each
table in the database. The default schemas already contain all of this
information. Select OK to close the Database Options dialog box.
End of Part B
Part C: Creating Database Tables

TestStand includes a separate application called the Database Viewer for
viewing data in a database, editing database table properties, and executing
SQL commands.
The Database Viewer application, DatabaseView.exe, is located in the

\TestStand\Components\NI\Tools\DatabaseView\ directory. In
this part of the exercise, you will execute SQL commands to create the
required database tables in the Sequence Data.mdb file you created.
The UUT_RESULT table contains a record for each UUT that TestStand
tests. The table includes fields for the UUT serial number, the name of the
test operator, date and time of the test, and the resulting pass/fail status of
the UUT to name a few. The STEP_RESULTS table contains the results for
the most common types of step result properties such as the step status and
error information. The remaining tables, such as STEP_MSGPOPUP, are
used to store the specific types of result information for each step type.
1. There are several ways to open the Database Viewer application. One
way is to select Tools»Run Database Viewer from the Sequence Editor
menu. The other way, which you should use for this exercise, is to select
Configure»Database Options from the menu and then select the View
button from the Data Link tab in the Edit Database Logging Options
dialog box. By using the latter method you do not have to specify the
data link information again since it is already stored in the Edit Database
Logging Options dialog.

2. This window contains a tree view of the tables that exist in the database
specified by the data link. This window is empty since you have not yet
created tables within your database. The title of the Data Link window
is a portion of your connection string (e.g. Provider=MSDASQL.1;Data
Source=TestStand Access).
3. To create the tables in your database, select File»New Execute SQL
Window from the Database Viewer menu. The Execute SQL dialog
will appear. In the following steps you will execute an SQL script to
create the database tables for you.
4. TestStand installs SQL script files for creating and deleting the default
database tables in Access, Oracle, and SQL Server databases according
to the default schemas. You can load and execute these ASCII text script
files in the Execute SQL window. Click on the open file icon located on
the Execute SQL window toolbar.

5. Load the file, Access Create Generic Recordset Result

Tables.seq, which is found in the
TestStand\Components\NI\Models\TestStandModel\
Database directory. After you select the file, the SQL Commands
control contains the set of SQL commands from the file for creating the
default result tables.
6. Execute the SQL commands by clicking on the GO icon in the toolbar.
Review the results of the SQL commands in the SQL History control of
the Execute SQL window. Close the Execute SQL window.
7. Verify that the tables were created successfully. You can do this by
selecting Window»Refresh from the Database Viewer menu. The
Data Link window should now contain a list of all the tables created in
the database as shown.

8. Close the Database Viewer application.
End of Part C
Part D: Logging and Viewing Test Results

This last part of the exercise will have you run a computer motherboard test
demo and log the results of the test to the database tables you just created.
You will then view the test results stored in the tables.
1. From the Sequence Editor, open the sequence file
C:\Exercises\TestStand I\Computer CVI.seq.
2. Execute the test sequence by selecting Execute»Test UUTs from the
menu.
You are prompted to enter a UUT serial number. Although any serial
number is valid, for the sake of conformity, enter the serial number
A001, and later use A002, A003, A004, etc.
3. After entering a serial number and clicking OK, TestStand displays the
Motherboard Test Simulator screen. You can select any of the
components to fail and then click OK. Once the UUT test completes,
TestStand displays a prompt that indicates whether the test passed or
failed. When you click OK to dismiss the prompt, notice the status text
that appears at the bottom of the execution window. TestStand notifies
you when it is generating a report, and logging UUT results to database.
If you choose to test more than one UUT during an execution of a
sequence file, the connection to the database remains open until the last
UUT test is complete.

4. Repeat the previous step a few more times using different serial
numbers.
5. Select the Stop button on the UUT Serial Number dialog box to end the
execution. TestStand will then automatically generate and display a final
report.
6. View the data that TestStand logged to the database tables. Recall there
are different ways to open the Database Viewer application. For this
step open it by selecting Tools»Run Database Viewer… from the
Sequence Editor menu bar.
Before the viewer can display the data in the database you must specify
a data link to your database. To specify a data link select File»New Data
Link. The Data Link Properties window opens and the Connection
tab is selected. Choose TestStand Access from the Use Data Source
Name ring control. Click OK to close the Data Link Properties dialog
box. The viewer displays a Data Link window that contains the tables
in the database.
7. In the Data Link window, you should see a list of tables including
UUT_RESULT and STEP_RESULT. Right-click on the
UUT_RESULT table and select ViewData from the popup menu. The
viewer displays a new Data View window that contains the tabulated
data as it would appear in Access. You should see several records, one
for each UUT you tested. Note that each UUT test has a unique ID. This
ID is used for referencing step data in the STEP_RESULT table. Using
the horizontal scroll bar you can view data corresponding to each
UUT test.

8. Do not close the Data View window, but return to the Data Link
window by selecting it from the Window menu. Remember that the title
of the Data Link window resembles Provider=MSDASQL.1;Data
Source=TestStand Access, which reflects the connection string of the
data link. Right-click on the STEP_RESULT table and select
ViewData. The viewer displays a new Data View window that contains
the test results for each step tested in the UUT test. You can also view
the specific test result data for each step by viewing the data for its
corresponding table in the database.
9. Close the Database Viewer.
End of Part D
End of Exercise 8-1

Exercise 8-2 Using Database Step Types

Objective: To use the built-in database step types to create a database session.
There are five built in step types in TestStand to programmatically interact

with databases from your test sequence: Open Database, Open SQL
Statement, Data Operation, Close SQL Statement, and Close
Database. You can use these database step types to create your own
database session.
In this exercise you will open the database to which you logged data in
Exercise 8-1. This database contains UUT results from the computer
motherboard simulation test that have passed and failed. You will
programmatically select records from the UUT_RESULT table, which
represent failed UUTs. You will then programatically obtain the serial
number for each failed UUT.
1. In the Sequence Editor, open a new sequence file and save it as
C:\Exercises\TestStand I\Ex 8-2 Using Database Step
Types.seq.
2. Select the Locals tab in the MainSequence and create the following
local variables:
Variable Name Variable Data Type

DatabaseHandle Numeric
StatementHandle Numeric
NumberOfFailUUTs Numeric
SerialNumber String
ListOfSerialNumbers String

Whenever you open a database using an Open Database step, you get a
handle to the database. Typically this handle is used in an Open SQL
Statement step to identify a set of data within a database table. An Open
SQL Statement step returns a statement handle. The variables
DatabaseHandle and StatementHandle will store the reference to
the database and SQL statement, respectively. The third variable,
NumberOfFailedUUTs, will store the number of records that are
returned for which the UUT failed. The SerialNumber variable will be
used to get store each individual serial number that is obtained. Lastly,
the ListOfSerialNumbers variable will be used to store a combined
list of all the serial numbers.
3. In the Main step group of the MainSequence, insert an Open Database
step by right-clicking and selecting Insert Step»Database»Open
Database from the popup menu. Name the step Open Database.
4. Right-click on the new step and select Edit Open Database. In the Edit
Open Database dialog box, choose Select Data Link and then select
TestStand Access from the list and click OK. This will update the
Connection String in the Edit Open Database window.
5. Select the Browse… button adjacent to the Database Handle control.
From the Expression Browser, insert the expression
Locals.DatabaseHandle and click OK. This will store the returned
value from the Open Database step to the local variable
DatabaseHandle. Your Edit Open Database dialog should resemble
the following image. Click OK to store your changes and close the
dialog.

6. Insert an Open SQL Statement database step below the previously

added step. Name the step Open SQL Statement. Edit the Edit Open
SQL Statement dialog for this step so that the Database Handle control
contains the expression Locals.DatabaseHandle. Likewise, update the
Statement Handle control to contain the expression
Locals.StatementHandle.
7. Next, build the SQL Statement for the Edit Open SQL dialog box. Click
the Build button, which provides a utility for building an SQL Select
statement. TestStand Access should be shown for the Data Link
Name control. From the Table ring control, select UUT_RESULTS.
From the Column ring control, select UUT_STATUS and then select
the Add button. For the Again, from the Column ring control, select
UUT_SERIAL_NUMBER and then select the Add button.
8. Highlight the UUT_STATUS entry you added to the list. You need to
add a where clause for this selection. Otherwise all records containing
the UUT_STATUS field will be selected. You are only interested in the
records corresponding to UUTs that failed. Therefore you should add
the following Where Clause expression: “UUT_STATUS=‘Failed’”.

9. Click OK to return you to the Edit Open SQL Statement dialog box. The
last thing you need to do is enter an expression for the Number of
Records Selected control. Enter Locals.NumberOfFailedUUTs for
this expression. Your dialog should resemble the following image.

Note The SQL statement uses SQL syntax, which is a database standard that is not
unique to TestStand. If you are not familiar with SQL commands and syntax, you may
want to read the SQL section of the TestStand User Manual.
10. Now that you have created a session to a database and obtained a
reference to some data in that database, you need to get the serial
numbers from the selected data. Insert a Data Operation database step
below the Open SQL Statement step. Name the step Data
Operation. Modify the Edit Data Operation dialog so that the
Record/Operation tab resembles the following image.

11. Next you need to modify the contents of the Column Values tab.
TestStand Access should be the specified Data Link Name. Select
the only statement in the ring control for the SQL Statement value.
From the Column Name/Number ring control, select
UUT_SERIAL_NUMBER. For the Value control, enter the expression
Locals.SerialNumber. The Column Values tab should now resemble
the following image. Click OK to store your changes and close the
dialog.

12. Double-click on the Data Operation step to display the Data

Operations Properties dialog. Select the Loop Options tab. From the
Loop Type ring control, first select Fixed Number of Loops and then
select Custom. This will first fill in the controls for the looping options
and then allow you to customize of the components. If you directly
selected the Custom option, you would have to type in all the
information directly. Modify the Loop While expression to contain the
following expression:
RunState.LoopIndex < Locals.NumberOfFailedUUTs

13. Next select the Expressions tab from the Data Operations Properties
dialog. In the Post Expression control, enter the following expression:
Locals.ListOfSerialNumbers+= Locals.SerialNumber + “, ”
Click OK to store your step property changes and close the dialog.

Note You do NOT have to perform a close SQL statement step or a close database step
immediately following the data operation step. These steps are typically placed at the
bottom of the sequence or in the Cleanup step group since they only need to be performed
once for each SQL statement or database reference that is obtained. Thus, if you
performed several data operation steps using the same database and SQL statement
obtained above, you would still only need to call the close SQL statement step and close
database step once at the end of your sequence.
14. Insert a Message Popup step below the Data Operations step. Name the
step Display UUT Serial Numbers. Modify the Configure Message
Box Step dialog so that it contains the following expressions:
Title Expression: “Serial Numbers”
Message Expression: “Serial Numbers of Failed UUTs: ” +

Locals.ListOfSerialNumbers

Click OK to store your changes and close the dialog.
15. Insert a Close SQL Statement database step. Name the step Close
SQL Statement. This step will release the reference to the SQL
statement obtained earlier. Modify the Edit Close SQL Statement
dialog so that the Statement Handle control contains the expression
Locals.StatementHandle. Click OK to close the dialog.
16. Insert a Close Database database step. Name the step Close
Database. This step will release the reference to the database obtained
earlier. Modify the Edit Close Database dialog so that the Database
Handle control contains the expression Locals.DatabaseHandle. Click
OK to close the dialog.

17. Save the sequence file Ex 8-2 Using Database Step Types.seq.
18. Since you do not need to log the results from this sequence to the
database, you should disable the database logging from within the
Database Options dialog accessed through the Configure»Database
Options menu item. You can disable database logging by placing a
check in the Disable Database Logging box.
19. Execute the sequence and notice the message popup that appears
indicating which UUT serial numbers from Exercise 8-1 failed the
computer motherboard simulation test.
End of Exercise 8-2

Notes

Notes

Lesson 9
Lesson 9: The Operator Interface

In this lesson, you will learn:
• The role of the Operator Interface in the
TestStand environment
• How to load, run, and debug sequences from
the Operator Interface
Introduction
In addition to the Sequence Editor, which has been used in most of the previous exercises, operator
interfaces are also ActiveX clients that interface with the TestStand engine through the TestStand
API. In this lesson, you will learn the role of the Operator Interface in the TestStand environment.
You will also learn how to load, run, and debug sequences from the Operator Interface. In the
exercises that follow, you will examine one of the sample operator interfaces that TestStand
provides.

Lesson 9 The Operator Interface

• Used to run TestStand on the test floor
• It is best if the Test Development Editor and
production station Operator Interface are
separate applications
• This separation is achieved in TestStand
through the:
– Sequence Editor—full control over creating/editing
sequences and customizing execution
– Operator Interface—simple user interface to be used on the
production line; can run and debug sequences; source code
is provided

For most of this course, you have seen TestStand through the eyes of a test system developer.
The Sequence Editor is the TestStand tool for building and customizing tests, but as you develop,
you can also run and debug tests. For many applications, a separate Operator Interface is more
appropriate for running tests in a production or factory environment.
An Operator Interface provides an intuitive user interface for running tests and checking results.
It also has some debugging capabilities for diagnosing problems on the production floor.

Available Operator Interfaces

• Four Operator Interfaces are included with
TestStand
– LabVIEW
– LabWindows/CVI
– Visual Basic
– Delphi
• Sequence Editor and Operator Interface are
separate applications
– Data is passed between the TestStand Engine
and the Operator Interface through ActiveX
Automation
Available Operator Interfaces

The TestStand Development software provides four sample operator interfaces, and for many
applications, one of these is likely to meet your needs with little or no modification necessary.
It is important to remember that the Sequence Editor and Operator Interface are separate
applications in the TestStand environment. Both the Sequence Editor and Operator Interface
communicate with the TestStand Engine via ActiveX Automation.
The Operator Interfaces allow you to start multiple concurrent executions, set breakpoints, and
single-step just like the Sequence Editor. Unlike the Sequence Editor, however, the Operator
Interfaces do not allow you to modify sequences, and they do not display sequence variables,
sequence parameters, step properties, or other programming variables in TestStand.
If the Operator Interface that you choose does not contain a particular functionality or appearance
that you desire, you can customize the Operator Interface to suit your needs. The TestStand
software provides source code for all four operator interfaces to make modifications possible.
Modifying the Operator Interfaces is not discussed in this course.

Operator Interface Functionality

All Operator Interfaces have identical
functionality:
• User login with configurable privileges
• Sequence file display
• Execution display
• Breakpoints and single stepping
Operator Interface Functionality

The Operator Interfaces included with TestStand have identical functionality and differ only in the
programming environment used to create them. They are all complete, functional, and robust
interfaces that can be used as is or as references or starting points for developers who want to
modify or create operator interfaces to meet their specific needs.
Each Operator Interface contains both a sequence display and an execution display. The options
available in each display depend on the login level of the user. These privileges are configured in
the User Management window of the Sequence Editor and restrict access in the Operator Interface
in a similar manner as in the Sequence Editor.

Sequence Display
Sequence Display
The Sequence Display shows the steps in a loaded sequence. Once you load a sequence file, its
name appears in the Sequence File menu ring. Selecting the appropriate sequence file, sequence,
and step group causes the steps of that particular sequence to appear in the Steps window. The
sequence description for the selected sequence appears in the Sequence Description window.
To begin executing a selected sequence, the operator presses either the Test UUT or Single Pass
button. Since the Operator Interfaces have built in user management features, the various menu
items will be made available depending on the current user’s login privileges.

Execution Display
Execution Display
Once a sequence is executing, the Execution Display window appears and the current sequence file,
sequence, and step group are displayed. Each step also appears in the Steps window and is updated
with its pass/fail/error status during the sequence execution. The Execution Display includes a
window for displaying the test report and can launch the report viewer as configured in the
Sequence Editor. Depending on the operator’s privileges, he or she can terminate execution, loop
steps, and debug sequences by single stepping and setting breakpoints.
The following exercise introduces the Operator Interface and its options for sequence execution
and debugging.

How the Operator Interface Works
UIMessages
TestStand Engine Operator Interface
Posts UIMessages Handles UIMessages

during execution to indicate during execution and
its current state performs the appropriate
action
How the Operator Interface Works

The simple case of operation is that the Operator Interface services the UIMessages generated by
the Engine and performs the tasks accordingly. This enables the Operator Interface and the Engine
to be synchronized during the sequence execution.

What is a UIMessage?
TestStand uses UIMessage objects to pass
information to the Operator Interface or
Sequence Editor about the state of the engine
and the current executions.
Examples:
TS_UIMsg_StartExecution = 10
TS_UIMsg_EndExecution = 8
TS_UIMsg_ResumeFromBreak = 17
TS_UIMsg_UserMessageBase = 10000
What is a UIMessage?
The TestStand Engine uses UIMessages to communicate the execution states and other
asynchronous information to your application.
When you write an application that runs TestStand sequence files, you do not handle the details of
executing each step. Instead, you call the TestStand Engine to begin executing the sequence file in
a new thread, and the engine notifies you asynchronously of the state of the execution. The Engine
notifies you of the execution state by sending messages such as Start, End, Break, and Trace.
You can update your application's user interface in response to these messages.
For example, TestStand posts a UIMessage with the event code, TS_UIMsg_StartExecution,
when a new execution is started. TestStand also defines a base value event code of 10000, beyond
which you can define customized UIMessages for unique purposes. You must program the
Operator Interface to respond to custom UIMessages. The Sequence Editor discards custom
UIMessages so custom UIMessages will not affect operation of the Sequence Editor.
The process of writing an Operator Interface is addressed in detail in the help document located at
Start»Programs»National Instruments TestStand»Online Help»TestStand Programmer
Help»Writing An Application.

Exercise 9-1
Objective: To learn how to run a sequence from

the Operator Interface

Lesson 9 Summary:
• The Operator Interface is a separate ActiveX
client application used on the test floor
• The main purpose of the Operator Interface is
to execute and debug sequences
• The TestStand operator interfaces are
shipped with source code in LabVIEW,
LabWindows/CVI, Visual Basic, and Delphi
• Operator Interface utilizes UIMessages
posted by the TestStand Engine to determine
the current execution state of the Engine
Summary
In this lesson, you learned about the Operator Interface component of TestStand. The Operator
Interface is an ActiveX client application separate from the sequence editor. Because it is separate
and provided in source code, you can ensure that each operator possesses the test interface you
designate.

Lesson 9 The Operator Interface Exercises
Exercise 9-1 Running Tests from the Operator Interface

Objective: To learn how to run a sequence from the operator interface. You will also use some
of the configuration and debugging options in the operator interface window.
Part A: Learning the Configuration and Debugging Options

1. Launch the LabWindows/CVI operator interface. From the Windows
taskbar, click on Start»Programs»National Instruments
TestStand»Operator Interfaces»LabWindows-CVI. The initial
window that pops up should appear as shown below. Use the following
login information and click the OK button.
User Name: administrator
Password: (the default password is an empty string)
2. After the operator interface window loads, choose File»Open Sequence

File. When a file dialog box appears, open the sequence file at
<TestStand path>\Examples\Demo\C\computer.seq.

The operator interface appears as shown below. The Steps list box
displays all steps in the currently selected sequence file. More than one
sequence file can be open at a time.
Note The following screens are all available in both the operator interfaces and in the
Sequence Editor. However, many of the screens have more options available when
accessed from the Sequence Editor than when they are accessed from the operator
interface. Regardless of where these options are accessed from, the changes made affect
all instances of TestStand, operator interfaces, and the Sequence Editor. The screens
pictured in this exercise were accessed from the operator interface.
3. Within the operator interface, you can debug test modules just as in the
Sequence Editor.
Choose Configure»Adapters. An Adapter Configuration window
similar to the one shown below should appear. Select C/CVI Standard
Prototype Adapter and click on the Configure button.

4. The figure below shows the LabWindows/CVI Standard Adapter

Configuration window. Click the Execute Steps In External Instance
of CVI radio button. Click the OK button to return to the Adapter
Configuration window. When prompted, click OK to unload all
modules from memory. Then click the Done button to return to the main
operator interface window.
5. From within the operator interface, you can also alter the TestStand
engine configuration by selecting Configure»Station Options. From
the Station Options dialog box, you can set the Execution, Time Limits,
Preferences, Model, User Manager, and Language options of the
TestStand engine. Each option is discussed below in greater detail.

Execution Options
• Enable Breakpoints—Turns the processing of breakpoints on or off.

You can also configure whether a sequence diplays the run-time error
dialog box or proceeds if a run-time error occurs.
• Enable Tracing—Turns tracing in the execution display on and off. You
can also enable or disable tracing into specific callbacks.
• Interactive Mode—Controls whether results are recorded and whether
setup and cleanup steps are run when the user interactively executes
selected steps using the Run Selected Steps and Loop Selected Steps
commands. You can also specify whether you want the preconditions to
be evaluated.

Time Limits Options
In this window, you can specify the time limit for how long a test can
take when executing, terminating, or aborting before some action should
be taken.
Normal Execution Settings
Time Limit Settings When executing, no time limit
When terminating, no time limit
When aborting, time limit of
10 seconds, prompt for action
Exiting Settings
Time Limit Settings When executing, time limit of
When terminating, time limit of
When aborting, time limit of

Preferences Options
In this window, you can set various station preferences. You can specify
whether you would like TestStand to display its hidden properties. You
can specify whether TestStand prompts you to locate files it cannot find.
You can have TestStand display a prompt before changing the system
SetForegroundWindow behavior. You can inform TestStand to
automatically increment the various sequence file versions. You can
have TestStand reload documents when opening a workspace and you
can specify whether you want TestStand to reload the last workspace
when it starts up. Lastly, you can inform TestStand to use the computer
name for the test Station ID.
Model Options
In this window, you can specify the TestStand model file. For this
exercise, the model should be <TestStand Path>\Components\
NI\Models\TestStandModels\SequentialModel.seq.

User Manager Options
In this tab, you can set the user configuration options for TestStand. For
this exercise, select the Check User Privileges box to enable the user
privilege checking. Also, check the Use Default box in the User
Manager File section. The default file should be
c:\TestStand\Cfg\Users.ini.
Note The Automatically Login Windows System User option logs in users
automatically with the network login required by the computer.
Note To protect the Users.ini file, you can place this file on a Windows NT machine
where only Administrators have write access to it.
Localization Options
In the Localization tab, you can select the language used in TestStand.

Remote Execution Options
Use the Remote Execution option to allow remote computers to run

sequences on this computer. More information about the use of remote
execution is in Chapter 12 of the TestStand User Manual.
Source Control Options
Use the Source Control options tab to specify whether you want a dialog
box to prompt you to check out a file when you edit a sequence file that
is in the current workspace and is checked into source control. You can
also have TestStand prompt you to add a file to the source control
system when you insert the file into the workspace. You can also specify
that a dialog box be displayed that lists the files you are checking out
when you check out files using the Workspace window. There is also the
option to only display selected workspace files in source code control
dialog boxes. Lastly, you can change your default source code control
provider.
Click Cancel to return to the operator interface.

6. The operator interface window includes an option for customizing the

items that appear in the Tools menu. Click on Tools»Customize.
In the Customize Tool Menu window, click the Add button to add an
option to the Tools menu.
There are four Item Types:

Command: Allows an executable (.exe) to be added to the
menu.
Sequence File: Creates a submenu that lists all sequences in a
sequence file as menu items.

Sequence: Initiates an execution on a sequence in a

sequence file.
Submenu: Adds a submenu to the current menu. Submenus
can be nested.
Click cancel twice to close the Add Tool Menu Item dialog box and the
Customize Tool Menu dialog box.
End of Part A
Part B: Execution of a Sequence in the Operator Interface

In Part A, you opened the computer.seq sequence file. The operator
interface displays the sequence display window. When sequence execution
begins, the execution display window appears.
From the sequence display, you can see the steps in the test sequence
(computer.seq for this exercise). The sequence display is comparable to
the sequence window in the Sequence Editor, although it does not allow you
to create new steps or edit existing ones. The Test UUTs button causes the
sequence to run continually, while the Single Pass button causes the
sequence to execute only once. You can also run an individual test within the
sequence by selecting (placing a check on) that step and selecting
Execute»Run Selected Steps or Execute»Loop on Selected Steps.
1. Make sure that Tracing is enabled by verifying Execute»Tracing
Enabled has a check-mark next to it. If tracing is not enabled, select
this menu item to enable it. Click the Single Pass button to run
computer.seq once. When the execution begins, the display view on
the operator interface window automatically switches to the execution
display.
With tracing enabled, the Steps box displays the status of each test as it
executes. After the sequence completes, the test report is generated.
Click the Launch Report Viewer button to launch the viewer
associated with the report file (specified in Configure»External
Viewers). In this exercise, an HTML document was generated, and the
external viewer launched is either Internet Explorer or Netscape
Navigator, depending on how the computer is configured. Examine the
report file and close the browser when finished.
2. From the operator interface window, choose File»Close Execution or
click on the X in the upper right corner to close the execution display.
3. You can debug sequences and code modules in the operator interface
also. To set a breakpoint on a particular step, select that step from the
Steps box and choose Debug»Toggle Breakpoint. The letter “B” is
placed to the left of the step to indicate that a breakpoint has been set.

4. Select the CPU step and place a breakpoint on that step.

5. Click the Single Pass button to execute the sequence once.
When execution reaches the CPU step in the execution display, it pauses.
The Debug menu contains additional tools that you can use when
paused at a breakpoint.
6. Choose Debug»Step Into from the menu. This causes execution to step
into the CPU sequence.
7. Choose Debug»Step Over to step over the Pre-Test.
Note Selecting Debug»Step Into can enable you to step into LabWindows/CVI code.
This is because in Part A of this exercise, you selected the option for the C/CVI Standard
Adapter Configuration to use an external instance of LabWindows/CVI. This means
LabWindows/CVI can launch the code directly, and you can use the LabWindows/CVI
debugging tools to step through the code. To explore this option more fully, finish this
execution and run the sequence in Single Pass mode again. This time, select Debug»Step
Into at the Pre-Test step.
8. From the Computer.c window, select Run»Finish Function.

9. Choose Debug»Step Over to proceed to the Register test.

10. Choose Debug»Resume to continue execution of the Register Test.
End of Part B
End of Exercise 9-1

Notes

Notes

Lesson 10
Additional Topics
Lesson 10: Additional Topics

• Import/Export properties
• Use the Property Loader step type
• Distribute TestStand
Introduction
This lesson discusses how to import and export variables and properties for your sequences using
the Import/Export Properties tool and the Property Loader step type. You will also learn how to
distribute your TestStand test environment once you are ready to deploy it.

Lesson 10 Additional Topics
Import/Export Properties
• Use the Import/Export Properties tool
• Launch from Tools»Import/Export Properties
• You can import/export properties to/from the
following formats:
– Files (.txt, .csv, .xls)
– Database
Import/Export Properties
For some applications, it may be more efficient to operate the same sequences using different
variable and property values (i.e. testing multiple models within the same product line) rather than
writing separate sequences for every model. You can use the Import/Export Properties tool to
import variable and property values into a sequence from a file, database, or Windows clipboard.
You can also use this tool to export variable and property values from a sequence to a file, database,
or Windows clipboard. Launch the Import/Export Properties tool by selecting
Tools»Import/Export Properties.

Import/Export Properties Dialog Box
Import/Export Properties Dialog Box

• Source/Destination—Specifies the external location from which you import, or into which
you export, the limit values in the sequence. You can specify the system clipboard or a specific
file as your source file.
• Skip Rows That Begin With—Specifies a string from which all rows will be ignored; this
feature is useful if the limits file has comment lines.
• First Row of Data Specifies Step Property for Each Column—Includes the step property
names for each column as the first row of each data block in the limits file. If you disable this
option, you must use the Specify Column to Step Property Mapping text box to specify the list
of property names by separating the property names with commas, as in the following example:
Limits.Low, Limits.High, Limits.String.
• Import—Imports limit values from a file or the system clipboard into a sequence. The source
must contain a block of limit values starting and ending with the data markers you specify.
The Import command displays the number of limit values it successfully imports, and lists any
steps or step property names it cannot find in the destination sequence.
• Export—Exports limit values from a sequence to a file or the system clipboard. If the
destination is a file that already exists and the Append to End of File option is disabled, a
dialog box prompts you to overwrite the file. If the option is enabled, TestStand appends a block
of data to the file that already exists. The Export command writes a block of limit data with the
starting and ending markers you specify to the file or clipboard.

Property Loader Step

• The Property Loader step dynamically
updates properties and variables in a
sequence at run-time
• You typically place it in the Setup step group
of a sequence
• Properties and variables can be used from
the following formats:
– Files (.txt,.csv,.xls)
– Database
The Property Loader Step

Use the Property Loader step to update the properties and variables in a sequence dynamically.
In this way, you can develop a common sequence that can test different models of a UUT, where
each model requires unique property or variable values.
You usually insert the Property Loader step in the Setup step group of a sequence, so that the
Property Loader step initializes the limit values before the steps in the Main step group execute.
The source of the values can be a tab-delimited text file (.txt), a comma-delimited text file
(.csv), an Excel file (.xls) or a database. You can use the Property Loader step together with
expressions to specify different files or database data links dynamically.

Exercise 10-1
Objective: To use a file or database to edit the

properties and variables of a sequence

Exercise 10-2
Objective: To use the Property Loader step to

dynamically import properties and variables
from a file or database

Exercise 10-3
Objective: To use the Property Loader step type

to import different values based on evaluating
expressions

Summary Importing/Exporting Values

• Use the Import/Export Properties tool to create the
files or database for the sequences
• Launch the tool using Tools»Import/Export Properties
• Use the Property Loader step to specify a file or
database to be used for a particular sequence
execution
• Change files or databases dynamically using
expressions to specify the source values to be loaded
by the Property Loader step
Importing/Exporting Values Summary

You can import or export sequence properties and variables using the TestStand Import/Export
Properties tool. You can export this information in file (.txt, .csv, and .xls) or database format.
You can also import or export property and variable values during sequence run-time using the
Property Loader step type. The Property Loader step type allows you to dynamically change the
file or database to import the values from using expressions to specify which file or database to use.

Distributing TestStand
How to distribute TestStand
• Create a TestStand Run-Time engine installation
• Distribute the Operator Interface
• Distribute sequences and code modules
UUT
UUT
Development UUT
Computer
Test Floor
Distributing TestStand
Another useful feature of TestStand is the ability to distribute it to other computers. The Sequence
Editor helps develop test sequences but is not likely to be needed by an operator who will run
sequences but not develop them. You can use the TestStand Run-Time Engine to deploy TestStand
on computers other than the development system. The process for deploying TestStand involves
three steps:
• Create a TestStand Run-Time Engine Installation
• Distribute the Operator Interface
• Distribute the Sequences and Code Modules

TestStand Run-Time Engine

• Includes a Wizard for creating a custom
TestStand engine installation
• Launches from Tools»Run Engine Installation
Wizard
• Creates following files to distribute:
– SetupTSEngine.exe (setup uncompresses engine files)
– TSEngine.cab (contains the TestStand engine files)
TestStand Run-Time Engine

You can use the TestStand Run-Time Engine to deploy TestStand on computers other than the
development system. The TestStand Sequence Editor development environment provides a useful
wizard for creating the TestStand Run-Time engine installation. The menu option Tools»Run
Engine Installation Wizard guides you through creating a TestStand engine and building an
installer. This engine includes all the required TestStand parts to run a sequence on a machine
separate from the development system. The installer wizard builds the installer including any
modifications made to TestStand such as the Process Model, tools, step types, and callback files.
The wizard creates two files on completion, SetupTSEngine.exe and TSEngine.cab. To install the
TestStand Run-Time engine on the target machine, copy these two files to the target machine and
run SetupTSEengine.exe.

Distribute the Operator Interface

• Completely separate application from the
Sequence Editor
• Build Operator Interface into an EXE on
development machine
• Distribute Operator Interface EXE to target
machine as you would any other EXE built
with your selected programming language
Distribute the Operator Interface

Once you have installed the TestStand Run-Time engine, you need to distribute your Operator
Interface to your target machine. Without the Operator Interface, the engine cannot view or run the
sequence. To distribute your operator interface, build it into an executable and copy the executable
and any necessary support files to your target machine. This procedure is exactly the same as if you
were distributing any other executable created within the same programming environment since the
Operator Interface is not written in TestStand.
Note If you are calling LabVIEW code from your test sequences and you are using a
LabVIEW Operator Interface, you should consider taking advantage of a LabVIEW
feature that allows you to build the LabVIEW ActiveX Server into the LabVIEW
Operator Interface executable. This feature can be enabled by selecting the Enable
ActiveX Server option from the App Settings tab in the LabVIEW Application
Builder. This feature is automatically enabled if you use the testexec.bld build script
when you build your LabVIEW Operator Interface executable. This script is installed in
the \TestStand\OperatorInterfaces\NI\LV\ directory when you install
TestStand. If you choose to not use the Enable ActiveX Server option, you will have to
create a LabVIEW Operator Interface executable and a LabVIEW Run-Time ActiveX
server executable.

Distribute Sequences and Code

Modules
• Copy test sequence files to target system
• Copy all code modules and supporting files to
the target system
• Ensure that the sequence files can locate
their code module files
– Absolute paths vs. Relative paths
– Search Directories
• Assemble VIs for Run-Time Distribution tool
• DLLs vs. *.c, *.obj, and *.lib when distributing
code modules
Distribute Sequences and Code Modules

Now that you have installed the TestStand Run-Time engine and have distributed the Operator
Interface, the last thing you need to do is distribute your test sequences and corresponding code
modules. You must also ensure that you distribute all support files that your code modules use.
There are many different ways to distribute your sequence files and code modules. There is no
specific method on how to do this. It depends on how you have organized your test sequence files
and code modules. Keep in mind, however, you must ensure that sequence files can locate their step
module files using the TestStand search paths list. If you distribute a sequence file that contains
absolute paths, TestStand will not find its code modules unless the target machine contains a similar
directory structure.
If you have written your code modules using LabVIEW, there is a convenient tool available that
will bundle up all of your top level VIs and their subVIs for each sequence. This tool can be
accessed from the menu Tools»Assemble Test VIs for Run-Time Distribution.
If you are writing your code modules using LabWindows/CVI, there are significant advantages to
calling your code modules as DLLs rather than *.c, *.obj, or *.lib. It is much easier to
distribute a DLL than it is to distribute an entire project and all its supporting *.c and *.obj files,
especially when you have large projects.
For information about these steps, see the TestStand User Manual.

Lesson 10 Additional Topics Exercises
Exercise 10-1 Importing and Exporting Properties

Objective: To use a text file to edit the properties of a sequence.
This exercise demonstrates the use of a TestStand tool for importing and exporting
properties of various tests in a sequence.
1. In the Sequence Editor, open a new sequence file. Save the sequence file
as C:\Exercises\TestStand I\Ex 10-1 Resistor Test.seq.
2. A new numeric limit test will be added to the sequence. Select the
<None> adapter from the adapter selector ring. The <None> adapter is
for creating a step in a TestStand sequence that does not call any external
code. Otherwise, <None> steps behave in the same way as other steps;
that is, they create data space for variables and properties based on their
step type and make comparisons with that data to determine whether the
test passes or fails. Insert a new numeric limit step by right-clicking in
the sequence window and selecting Insert Step»Tests»Numeric Limit
Test. Name the step Resistor 1 Test.
3. Because this step is using the <None> adapter it will not call any code,
thus a numeric result is not returned. Instead, you will place a value in
the result field using a post expression. Right-click on the step and select
Properties. Click the Expressions tab and click inside the Post
Expression box. Enter the following expression by typing it directly or
using the expression browser, which you can access by selecting the
Browse button:
Step.Result.Numeric = Random(0,1)
This expression defines the numeric result for this step to be a random
number between 0 and 1. Click OK to return to the sequence display
window.
4. Copy the new step by either selecting it and pressing <Ctrl-C>, or by
right-clicking on it and choosing Copy. Paste four copies of the step by
pressing <Ctrl-V> four times or right-clicking in the window and
selecting Paste. Name the steps so that they read Resistor 1 Test,
Resistor 2 Test, Resistor 3 Test, and so on.
5. Click on the Locals tab within the MainSequence. Insert a new local
variable of the string data type. Name the variable ResultString.
6. Click back on the Main step group tab within the MainSequence. Add
a string value test to the end of the sequence by right-clicking in the
sequence window and selecting Insert Step»Tests»String Value Test.
Name the new step Instrument Query. Edit the Post Expression of
the Instrument Query test to be:
Step.Result.String = Locals.ResultString
Click OK to return to the sequence display window.

7. Save the changes you have made the sequence file. The sequence should
now appear as shown below.
8. Select Tools»Import/Export Properties from the Sequence Editor

menu. This brings up the Import/Export Properties dialog box. This tool
allows you to import and export properties from the selected sequence
to the clipboard, a file, or a database. This exercise will use the tool to
export the selected properties to a file and then import the updated
properties to the test sequence.
9. From within the Source/Destination tab, select File from the Data
Location ring control. Specify the path C:\Exercises\TestStand
I\Limits.txt for the File Location. After specifying the path, “File
not found” will be shown because the file does not exist yet and will be
created automatically by this tool. Select Tab Delimited Text (.txt)
from the Format ring control. All of the other controls on this tab
should be left in their default setting. The Source/Destination tab
should resemble the following image.

The Data Location selector allows for import/exporting properties

from/to the clipboard, a file, or a database.
The Format selector determines the format of the properties being
imported or exported.
The Decimal Point selector allows you to determine how decimal points
should be handled by the tool.
Data Markers are for selecting specific locations in a file to begin and
end searching for properties to be imported.
The two final controls allow two different things to happen. First, they
allow some rows to be skipped, as the rows may contain textual
documentation instead of properties that should be imported. The
second option is that the first row of data in the text file can specify the
step properties that the values are describing. If this dialog box is not
checked, TestStand assumes that the first row of data in the import file
contains values instead of step property names.
10. Now use the Properties tab to select which properties to export. For this
exercise, you should export all of the step limit properties as well as the
Locals.ResultString property from the MainSequence. Select the
MainSequence from the Sequence ring control. Notice the list of
available properties to use with this tool. You can select which

properties you are interested in from this list. To select all of the step
limit properties, simply click on the Limits > button. To add the
Locals.ResultString property to the list of selected properties, highlight
the property in the list of available properties and then select the
> button. The Properties tab should resemble the following image.
11. Now you are ready to export the selected properties and their
corresponding values to a file. To do this, select the Export button from
the Import/Export Properties dialog. You should receive a message
popup indicating that 17 property values and 1 variable value were
exported as shown.

12. This message indicates that you have successfully exported the selected
properties to the file C:\Exercises\TestStand I\Limits.txt.
Close the message by selecting the OK button. Close the
Import/Export Properties tool by selecting the Done button.Use
Windows Explorer to browse to the directory and open the
Limits.txt file. Leave this file open for the next step.
13. TestStand has created this file where each step that contains any of the
selected properties occupies a row. In this case, all steps have associated
properties, but if there were steps that did not contain the selected
properties (a Pass/Fail step, for example), these steps would not appear
in the file. Each column of the file is used for a property field. The five
numeric tests use the Limits.High and Limits.Low columns, while the
string value test uses only the Limits.String column. The variable
properties use the sections below the steps for each scope of variable
(i.e. locals, file globals, and station globals). In this case, the only
variable exported was the ResultString local variable. Edit the text file
to reflect the values as shown and be sure to save the changes made to
the Limits.txt file.

14. Now that you have edited the selected properties, you need to import
them back into the sequence. Launch the Import/Export Properties
tool again, verify that the correct file is still specified and the correct
properties are specified. Click the Import button in the Import/Export
Properties dialog box. A dialog box should indicate that 18 limits were
found and imported from the file.
15. Close the Import/Export Properties dialog by selecting the Done

button. Examine the limits of the test steps to verify that the updated
values reflect those specified in the file. Also, verify that the local
variable ResultString contains the proper updated value.
16. Save the changes made to the sequence file

C:\Exercises\TestStand I\Ex 10-1 Resistor Test.seq.
End of Exercise 10-1

Exercise 10-2 Using the Property Loader Step Type

Objective: To use the Property Loader step type to import a properties file programmatically.
It is often more convenient to load properties automatically from a file or

database during a sequence’s execution. TestStand includes a step type that
does just that: the Property Loader step. This step type is useful for
dynamically loading properties at runtime from any point within your test
sequence. It is also convenient in that the test operator does not have to
manually import the properties, it is all done as a part of the test sequence.
1. In the Sequence Editor, open the sequence file
C:\Exercises\TestStand I\Ex 10-1 Resistor Test.seq
that you created in the last exercise. Save this sequence file as
C:\Exercises\TestStand I\Ex 10-2 Resistor Test with
Property Loader.seq.
2. Select the Setup step group tab within the MainSequence. Insert a
Property Loader step in the Setup step group by right-clicking and
selecting Insert Step»Property Loader from the popup menu. Name
the step Load Properties.
3. Right-click on the new step and select Edit Property Loader from the
popup menu. The Edit Property Loader dialog allows you to select
which properties you want to load and from what data location. Notice
the similarity in the configuration tabs between the Edit Property
Loader dialog and the Import/Export Properties dialog from the
previous exercise. From within the Properties tab, select File from the
Data Location ring control. Insert Step.PropertiesList for the
Properties List Source control value. Select the Limits > button to
specify that you want to load all the step limit properties. Also highlight
the Locals.ResultString property and select the > button to add it to the
list of selected properties. The Properties tab should now resemble the
following image.

4. Click on the Source tab. For the File Location, browse and select the
file C:\Exercises\TestStand I\Limits.txt. If prompted,
specify that you would like to add the directory containing the selected
file to the list of search directories. Select Tab Delimited Text (.txt) for
the File Format option. The remaining settings can be left with their
default values. The Source tab should now resemble the following
image.

5. Click OK to store your changes and close the Edit Property Loader
dialog. Save the changes made to the sequence file.
6. Open the C:\Exercises\TestStand I\Limits.txt file and edit
the property values to reflect the changes shown in the following image.
Be sure you save the Limits.txt file after making the changes.

7. In the Sequence Editor, set a breakpoint on the Load Properties step

in the Setup step group. Execute the sequence in single-pass mode.
When the execution pauses on the Load Properties step, go the
Context tab and drag the low and high limits of the Resistor 1 Test from
the context menu into the watch window, as shown below. For example,
the high limit is located under RunState»Sequence»Main»[“Resistor
1 Test”]([0])»Limits.High. You can also drag the local variable
ResultString into the watch window as well. Return to the Steps tab and
click the Step Over button in the toolbar to execute the property loader
step. Notice that the values of the limits in the watch window are
updated. Click Resume to finish the sequence execution and examine
the test report to verify that all limits were updated correctly.

8. Remove the breakpoint that you set on the Load Properties step in
step 7 of this exercise before continuing to the next exercise.

Exercise 10-3 Using the Expressions to Load Properties

Objective: To use the Property Loader step to import different properties dynamically based on
the value of a TestStand expression.
The property loader step can be a powerful tool in sequence development.

The step can allow one sequence file to test many different components,
each with a different set of property values. For example, assume that two
UUTs need to pass a similar set of tests, except that each UUT has a different
set of associated properties. It would be adequate to create one sequence for
each UUT, although they were identical except for the certain properties of
their steps. It would be easier and more practical to create one sequence and
use the property loader step to load in the correct properties dynamically
during the execution of the sequence. This exercise demonstrates how to
test for the presence of a particular UUT and load the properties associated
with that UUT for the rest of the sequence based on the results of that test.
1. Launch Notepad and open the prevoiusly created text file
C:\Exercises\TestStand I\Limits.txt. Change the limits as
shown and save the file as Limits1.txt. Do not close the text file yet.
2. Change the limits as shown and save the file as

C:\Exercises\TestStand I\Limits2.txt. With both text files
now saved, close Notepad.

3. In the Sequence Editor, open the previously created sequence file

C:\Exercises\TestStand I\Ex 10-2 Resistor Test with
Property Loader.seq. You completed this file in the previous
exercise. Save this sequence file as Ex 10-3 Resistor Test with
Limit Expression.seq.
4. From within the MainSequence of the sequence file, select the Setup
step group tab and insert a Message Popup step before the property
loader step. Name the step Select Properties to Use.
5. Right-click on the new step and select Edit Message Settings from the
popup menu. Set the fields in the Text and Buttons tab of the
Configure Message Box Step dialog as shown. Once you have
completed the settings, click OK to return to the sequence display.

6. Right-click on the Load Properties step and select Edit Property

Loader from the popup menu. Select the Source tab and the Use
Expression to Specify File option. Use the Expression Browser to
enter the following File Name Expression:
"Limits" + Str(RunState.Sequence.Setup["Select Properties
to Use"].Result.ButtonHit) + “.txt"
This expression loads the file with the name Limitsx.txt, where x
corresponds to the button selected by the operator.
Note The x value is obtained from the Result.ButtonHit property value NOT the
expression specified for the button, i.e. if Button 1 was labeled “25”, Result.ButtonHit
would still yield the value “1” and NOT the value “25”. This exercise could have also
enabled the response text box within the message popup step and had the operator type
in a “1” or a “2” rather than use buttons.
7. Click OK to return to the Edit Property Loader dialog box, which

should resemble the following image.

8. Click OK to return to the sequence display window.

9. Save the changes you have made to the sequence.
10. Execute the sequence by selecting Execute»TestUUTs. On the first
UUT, select Button 1 in the Choose Limits File message popup. For the
second UUT, select Button 2. Stop the execution after the second UUT
and examine the rest report. The limits for the first UUT are from
Limits1.txt and the limits for the second UUT are from
Limits2.txt.

Notes

Appendix A
Introduction to
Interchangeable Virtual Instruments
Appendix A: Introduction to
Interchangeable Virtual Instruments
Introduction to Interchangeable Virtual Instruments (IVI)

This section introduces and describes how you can use Interchangeable Virtual Instrument (IVI)
drivers in your applications. IVI is a new instrument driver architecture with two key
improvements to drivers—IVI drivers are intelligent, meaning they track the state of the instrument
and make run-time decisions based on that state to improve performance, and IVI drivers are
interchangeable, meaning you can swap instruments under the same driver.
As the tools and techniques for test system development have evolved, test developers have shifted
to a more modular approach for controlling instruments. This evolution has driven test developers
from writing programs with instrument commands littered throughout their code to using modern
techniques for packaging instrument I/O commands in self-contained “instrument drivers”. The
benefits of separating instrument I/O code in instrument drivers from test logic code are
tremendous—not only is it easier to write your test programs, it is also easier to maintain your test
code when you use instrument drivers.
© National Instruments Corporation A-1 TestStand I Fundamentals Course Manual

What is an Instrument Driver?
Set of high-level functions to control an

instrument
• Initialize, configure, measure, close
• They use GPIB or VISA internally
• Can be written in and for any programming
language
What is an Instrument Driver?

In the early days of computer-controlled instrumentation systems, programmers used BASIC, C,
FORTRAN, or PASCAL I/O statements in their application programs to send and receive
command and data strings (or register values) to and from the various instruments connected to
their computer via GPIB, serial, or VXI. Each instrument responded to a particular command that
the instrument manufacturer documented in a manual, and programmers were responsible for
learning these commands. Software development is often the most time consuming part of
implementing an automated test system. This is especially the case when test engineers need to
relearn the same command strings or register values over and over again whenever they create new
applications. It quickly became apparent that programmers could save significant time and money
if they wrote generic high-level routines that encompassed the low-level commands used to
program the instrument. These reusable generic routines came to be known as instrument drivers.
An important category of instrument drivers is IVI, Interchangeable Virtual Instruments, which
make it possible to use the same software interface for different hardware instruments.
TestStand I Fundamentals Course Manual A-2 ni.com

What is IVI?
• IVI Foundation announced in August ‘98

• Charter: define standard programming interface for
instrument drivers
• Define instrument driver class specifications:
Instrument Class (e.g., IviDMM)
Base Capabilities (Required):
Driver Capabilities
e.g., Measure AC Volts & DC Volts
Extension Groups (Optional):

e.g., Measure Temperature
Vendor-Specific Capabilities (Optional):

e.g., Trigger at User-Specified d Threshold
What is IVI?
In early 1997, National Instruments was approached by several instrument end-user companies
interested in developing a new standard for instrument drivers that would be built on existing
approaches such as VXIplug&play and would also address several concerns such as instrument
state-caching, simulation and interchangeability.
As a result of the discussions, a group of nine companies formed the Interchangeable Virtual
Instruments or IVI Foundation. The charter of the Foundation is to define a standard programming
interface for instrument drivers while allowing for instrument interchangeability, regardless of the
instrument manufacturer or I/O bus interface.
The Foundation developed the standards by identifying common instrument types such as digital
multimeters or oscilloscopes, and then identifying a common set of features within each instrument
type and dividing the features into three groups: base capabilities, extension capabilities, and
vendor specific capabilities. The Foundation then developed a set of specifications for each of these
instrument types, and defined that as an instrument class.

IVI Instrument Drivers
• Intelligent
– State Caching
– Multithreading
– Simulation
• Interchangeable
– Generic instrument classes
– Class drivers
– Configuration in MAX
• Easy to use
IVI Instrument Drivers

IVI instrument drivers introduce a number of features to address the drawbacks of traditional
drivers. Without affecting the ease of use of instrument drivers, IVI drivers introduce features that
increase performance and make it possible to write hardware independent test applications.
The “intelligent” side of IVI drivers refers to state caching, multithreading and simulation. State
caching refers to the driver’s ability to maintain the state of the instrument in software, thus
eliminating redundant I/O. For example, when performing a frequency sweep, the function that sets
the frequency may set three or four other instrument attributes. With an IVI driver calling this
function it will only result in sending the command to set the frequency. IVI State caching provides
that only the changed frequency value is reset.
In addition to being multithread safe, IVI drivers also allow you to simulate an instrument. You can
write an application, run it in simulation mode, and verify the validity of each of your parameters
and therefore the correctness of the application. Once you are comfortable with your application’s
robustness, you can use the application with an actual instrument and deploy your system.

IVI Instrument Drivers (Continued)
IVI Instrument Drivers (Continued)

The “interchangeable” side of IVI drivers has been made possible by the standardization of the
internal structure of instrument drivers. Classes of defined instruments, such as oscilloscopes or
digital multimeters, have defined functions that must be present in an IVI driver for a given
instrument class. This ensures interchangeability within the instrument class. Once you have
written an application using an IVI driver, it should be trivial to use another instrument of the same
class, provided that it has IVI drivers. Also, you will not have to recompile any of your test code
since changes are managed in MAX. The classes have been defined by the IVI foundation
(www.ivi.org); a group of end-users, system integrators, and instrument vendors. For example,
you can use a Fluke 45 or an HP 34401A with the same application as long as you have the specific
drivers for those instruments.

IVI Driver
• One driver per instrument

• High-level, easy-to-use functions
– Based on VXIplug&play driver model
• Improved driver development tools
– More consistent, higher quality drivers
• Driver architecture based on instrument
attribute model
IVI Driver
IVI drivers have a number of similarities with traditional drivers. Like traditional drivers, an
IVI driver must be present for each instrument. They are also VXIplug&play compliant.
Improvements introduced through the IVI standard have lead to more consistent and higher quality
drivers.
IVI has several built-in features for meeting the most advanced test development requirements:
• A state caching engine eliminates redundant instrument I/O
• Range checking validates values for attributes before they are configured on the instrument
• Error checking to query the instrument’s error queue
• Built-in simulation capabilities
• Multithread-safe drivers
• Standard attribute model and APIs for various types of instruments
• Driver development tools
• Instrument interchangeability
• Consistent driver architecture
• Usable in LabWindows/CVI, LabVIEW, Visual Studio, and so on

IVI Attribute Model
Instrument settings correspond to driver attributes.

ATTR_TRIGGER_LEVEL
ATTR_TRIGGER_SOURCE
ATTR_VERTICAL_RANGE
ATTR_VERTICAL_COUPLING
ATTR_INPUT_IMPEDANCE
ATTR_VERTICAL_OFFSET
ATTR_HORZ_TIME_PER_RECORD
IVI Attribute Model

IVI-specific drivers offer many other additions and enhancements in addition to the benefits of
VXIplug&play instrument drivers. These features are comprised of a standard attribute model,
state-caching, range-checking, error query, and multithreading. This section discusses each of
these features in more detail.
Standard Attribute Model

The IVI drivers follow a standard attribute model. An attribute is a quality or characteristic of an
object, in this case, an instrument. Attributes for a function generator are shown above and would
include the waveform type, frequency, Amplitude, and voltage offset. Instruments may have
several input or output acquisition channels. Each of these may have independent hardware
settings. For example, an oscilloscope may have different settings for vertical range for each of its
input channels. IVI drivers use channel-based attributes for these cases.
A standard attribute model also implies that you can develop a software layer that allows
instruments with similar capabilities to be interchanged without changing the test code.

State Caching
• Physical state of instrument maintained in a

software cache
• High level functions grouping attributes
together
– Communication with instrument is only performed
when the attribute’s cached value is invalid
– Minimizes redundant I/O to instrument
– Minimizes costly instrument command parsing
State Caching
The attribute model of IVI drivers is key to implementating state caching. Each physical state or
attribute of an instrument is maintained as an attribute in a software cache. High level functions
group together a number of attributes and communicate with an instrument only when a particular
cached attribute value becomes invalid. This eliminates both redundant I/O and instrument
re-configuration.

Range Checking
• Drivers verify the values specified for an

attribute
– Traditional drivers indicated valid range through
online documentation
– IVI drivers provide this information and verify the
entries in an application
• Attribute dependencies handled by driver
– e.g. Probe attenuation and vertical range
Range Checking
IVI drivers verify the values for an attribute such as range in software, and return errors before
communicating with the instrument. Traditional drivers document valid ranges for parameters or
settings but do not provide error checking or trapping themselves.
IVI drivers also take into account any attribute inter-dependencies. For example, the valid vertical
range for an oscilloscope is usually dependent upon the probe attenuation for the probe that is
connected to a particular channel. IVI drivers can dynamically calculate the valid vertical range by
checking the probe attenuation.

Simulation
• Simulation mode does not require a physical

instrument
• Verify values to be sent to instruments while
developing the test application
• Simulate acquired data
– Random data with instrument specific drivers
– User defined data with class drivers
Simulation
Simulation eliminates the need to have an actual instrument present when developing an
application. With range checking and simulation the application developer can verify the
correctness of the test application before even purchasing the instrument or deploying a system on
a test floor.
Simulation allows the application developer to verify the values being sent to the instrument
through range checking, and also simulate the data being returned from instruments. Thus the test
application developer can write the entire application, test it through simulation, and spend very
little time testing with the actual hardware before deploying the system.

Standardization
• IVI class specification sets guidelines for

internal structure and programmatic interface
of similar instruments
• Instrument classes
– Functional classes (e.g. oscilloscopes)
– IVI Foundation defines classes
(www.ivifoundation.org)
– Establish instrument characteristics and
programmatic interface
Standardization
The IVI class specifications are determined by the IVI foundation (www.ivifoundation.org).
The class specifications set guidelines for the internal structure and programmatic interface of
similar instruments. Thus IVI drivers provide the application developer with a consistent,
standardized programming model.

Instrument Classes
• Define a standard API for programming

instruments
– e.g., all scopes are programmed the same way
• Allow for the development of hardware-
independent test programs
• IVI Foundation establishes class
specifications
– www.ivifoundation.org
Instrument Classes
The “interchangeable” side of IVI drivers has been made possible by the standardization of the
internal structure of instrument drivers. Instrument classes define a function set that must be
present.
The IVI class specifications divide instrument features into fundamental capabilities and extension
groups.
Fundamental capabilities are attributes and functions that are commonly supported by the majority
of instruments in a class (for example, range setting for a DMM or probe attenuation for a scope).
This defines the basic functionality that can be interchanged among instruments in a particular
class.
Extension groups are for less common features that are popular in a large number of instruments
(for example, different scopes have different triggering protocols, so glitch triggers, runt triggers,
and so on are considered extension groups).

IVI Class Specification
Scope Example
Fundamental
Capabilities
Extensions
Initialize
Configure Vertical Runt Width Video
Configure Horizontal Trigger Trigger Trigger
ReadWaveform Functions Functions Functions
Close
Etc....
Standard Functions and Attributes
IVI Class Specification

The IVI class specifications divide instrument features into fundamental capabilities and extension
groups. Attributes and functions that are commonly supported by the majority of instruments in a
class (for example, range setting for a DMM, or probe attenuation for a scope) are considered
Fundamental Capabilities. This defines the basic functionality that can be interchanged among
instruments in a particular class.
Fundamental Capabilities are common functions, attributes, and attribute values supported by more
than 95 percent of the instruments of a given class, that must be implemented in all
instrument-specific IVI drivers in the class. Extensions are less common capabilities and optional
(for example, the Arb extension is supported only by true arbitrary waveform generators).
Two examples that show the difference between fundamental capabilities and extensions are
described here in reference to the Scope and DMM class drivers:
• The Scope class defines the vertical and horizontal subsystems as part of the fundamental
capabilities. Different oscilloscopes support different triggering mechanisms and protocols,
and the Scope class defines the most common as extended features.
• The DMM class defines trigger and multipoint measurement functions as extended capabilities.
Less common features such as autoranging capabilities and measurement functions such as
light intensity are also included in the extensions.

IVI Driver Standard
Easy-to-use Functions
VXIplug&play Driver - Configure, Read etc.
Required Utility Functions:
Application Functions - Initialize
- Reset
- Self-Test
- Error-Query
Required Functions - Error Message
- Revision-Query
- Close
How should you develop
the code?
Code How should you structure
IVI the code?
How should the code
execute?
VISA Industry-standard I/O Library
IVI Driver Standard

Traditional drivers use VXIplug&play standard to write drivers.VXIplug&play defines a set of
functions that every VXIplug&play compatible driver must expose. However, it does not address
how the functions are written.
IVI is also based on VXIplug&play, but it extends the standard by defining a template for the
internal structure of drivers. It also introduces an attribute-based model that allows you to
implement advanced features.
IVI drivers maintain the flexibility of traditional drivers and address the areas where traditional
drivers were lacking. IVI drivers allow you to develop more consistent and better performing
applications.

Where Does IVI Fit In?
Test Program • Instruments classified by

type
IVI Class Driver – Can develop non class-
compliant drivers
IVI IVI • Two-tiered architecture:
Specific Specific
Driver Driver – Instrument-specific drivers
performance improvements
– Generic class drivers
I/O Library
(VISA or other) interchangeability
• Builds on VISA or other
Hardware
standard I/O library
Where Does IVI Fit In?

The IVI Foundation defined an architecture for its drivers that is hierarchical and layered in nature
and that leverages industry-standard technology. This architecture fits into a complete modular
system from National Instruments. The test program uses IVI drivers for the instrument
communication. The IVI layer in turn uses an industry-standard I/O library such as VISA to
communicate with the hardware that is in the system, regardless of whether it is GPIB, VXI, PXI™
or computer-based instrument hardware.
The IVI layer itself is divided into two sub-layers. The lower is the IVI-specific driver layer.
These are instrument-specific drivers that are intended to be used with specific instrument models,
and they are designed to provide the performance improvements of IVI, such as state-caching,
multithreading, and simulation.
The upper sub-layer is the IVI class driver layer. These are the generic class drivers that you can
use in conjunction with specific drivers to control any instrument in a class. This layer provides the
interchangeability benefit of IVI.
The IVI specs also allow drivers to be created for instruments that do not fall into one of the IVI
defined classes. Users can develop specific drivers to take advantage of performance benefits or
define their own instrument class.

Using IVI Instrument Specific
Drivers
Same methodology as using traditional drivers

• Initialize with Options function
• Option string
– Used to specify the driver operation configurations
– “Simulate=0, RangeCheck=1, QueryInstrStatus=1,
Cache=1, DriverSetup=Model:E3633A”
• Configure, Measure etc.
• Close
Using IVI Instrument Specific Drivers

Using IVI drivers is no different from using traditional instrument drivers. You must have the IVI
Engine installed which can be obtained from the National Instruments web site (ni.com).
The main difference between traditional drivers and IVI drivers is that IVI drivers have two
Initialize functions. The first is the same as traditional drivers and the second is the “Initialize with
Options” VI or function. This VI or function includes one parameter, called the “option string”
which the traditional Initialize VI or function does not contain. The option string can be used to
specify which of the IVI driver features you wish to enable or disable.
An example is “Simulate=0,RangeCheck=1,QueryInstrStatus=1,Cache=1,
DriverSetup=Model:E3633A”:
1. Does not simulate the instrument.
2. Does check the range or value of attributes.
3. Does Query the instrument status
4. Does maintain the State Cache.
5. Sets the driver to talk to a E3633A model (In this case HPE3633A)

Using IVI Instrument Specific
Drivers (Continued)
Using IVI Instrument Specific Drivers (Continued)

By selecting different options you can effectively set up different phases of development.
When testing your application’s robustness you would enable RangeCheck and QueryInstrStatus.
Once you are comfortable with your application’s state you can disable these two options and
therefore maximize the speed of your application. This provides an easy way to switch between
“Development” and “Deployment” modes.

Types of IVI drivers
Class Driver
Test Program IviDmm_Init
IviDmm_Configure
IviDmm_Trigger
IviDmm_Read...
IviDmm Specific Driver

fl45_Init
fl45_Configure
fl45_Trigger
fl45_Read…
fl45 fl45_special... Specific Driver
hp34401A hp34401A_Init
hp34401A _Configure
hp34401A _Trigger
hp34401A _Read…
hp34401A_special...
Types of IVI Drivers

There are two types of IVI drivers:
• Instrument specific IVI driver (Ex: fl45)—This driver has built-in range checking, error
checking, simulation, etc. Each instrument-specific driver contains the class’s defined attributes
and functions in addition to instrument specific functions/attributes. This driver is intended to
communicate with only one instrument.
• Class driver (Ex: IviDmm)—This driver isolates the test program from the specific
instrument model and allows you to interchange instruments, provided they meet the test
system requirements. Interchangeability in software is limited to interchangeability in
hardware. For example, you cannot use a digital multimeter (DMM) with a resolution of 0.001
V if your test program requires a DMM with 0.0001 V resolution. In this case, you must use a
DMM capable of measuring at least 0.0001 V.

Interchangeable Drivers
Test Program
• Swap instruments (LabWindows/CVI, LabVIEW, VB, etc.)
under generic class
drivers
– No source code change
or recompilation DMM Class
• Five classes defined Driver
– Scope
– DMM
– Arb or function generator
– Switch NIKeithley
Fluke 45
4050 2001
DMM
– DC power supply
Interchangeable Drivers
Test programs can call driver functions contained in either a specific driver or a class driver.
Programs developed with the generic class driver functions are hardware independent; you can use
them with any instrument that has an IVI driver for the particular class (provided the instrument
meets the test system specifications). Test programs can call a specific driver directly, call a generic
driver to allow interchangeability, or mix calls to the specific and class drivers to take advantage of
features the class driver does not expose.

IVI Architecture
User Application
(LabVIEW, LabWindows/CVI, Visual Basic, etc.)
Class Driver
(Scope, DMM, Switch, etc.)
IVI Engine
Instrument Driver
(fl45, hp54600, VXI-DAQ, Plug-In DAQ)
Instrument-Specific Capabilities
IVI Configuration
IVI Architecture
Test applications can make calls to a class driver, a specific driver (if interchangeability is not
important), or both. Both the class and instrument-specific drivers rely on the IVI engine for state
management. The class drivers also use entries in an IVI configuration file to direct the generic
class driver calls to the specific instruments in use.

IVI Configuration
• Measurement and Automation Explorer(MAX)

– Used to configure ivi.ini file
IVI Configuration
You configure your IVI instruments with the IVI configuration utility that is added into the
Measurement & Automation Explorer (MAX). The graphic above shows the IVI section of MAX.
You can configure the following settings with the IVI configuration utility:
• Logical Names—A logical name references the virtual instrument you want to use in your
application.
• Virtual Instruments—The combination of the physical instrument, the instrument driver, and
option settings. You can swap instruments without changing your program by changing the
Logical Name to reference a new virtual instrument.
• Simulation Virtual Instrument—A particular simulation driver and the initial attribute
settings for the driver.
• Instrument Drivers—An IVI specific driver configuration item that specifies a code module,
such as a DLL, for a specific driver.
• Class Drivers—An IVI Class driver configuration item that refers to a default simulation
virtual instrument. The class driver uses the default simulation virtual instrument when you
enable simulation.
• Simulation Drivers—An IVI simulation driver configuration item that specifies a code
module, such as a DLL, that a class driver can use to simulate a device.
• Devices—An IVI device configuration item that specifies the address of an instrument to use.

IVI Configuration
• Logical names (example: Dmm1)

– Identify the instrument for initialization
• Virtual channel names
– Aliases for instrument-specific channel names
• Default setup
– List of attributes and values to set
– Processed by the class driver after invoking the specific driver’s
init function
– Sets instrument-specific attributes so that the driver behaves
interchangeably
IVI Configuration
With MAX, you can configure the following:
• Logical names—A logical name references the virtual instrument you want to use in your
application. A virtual instrument is the combination of the physical instrument, the instrument
driver, and option settings. By changing the virtual instrument logical name references, you can
swap instruments without changing your program.
• Virtual channel names—Virtual channel names aliases for instrument-specific channel
names. By using virtual channel names, your program does not contain instrument-specific
channel names.
• Default setup—You can define a list of attributes and their values. After the class driver calls
the specific driver initialize function, these attributes are set to the specified values. With this
feature, you can set instrument-specific attributes outside your program. This feature has two
benefits—it configures the instrument so that it behaves interchangeably, and it maximizes the
possibility of changing instruments.
• Inherent Attributes—You can specify whether attributes such as range checking, state
caching, query instrument status, spy, interchange check and record coercions are enabled
or not.

Logical Names
• Used by class driver Initialize functions
• Associated with a specific instrument
Logical Names
When you call a class driver Initialize function, you pass a logical name alias rather than a resource
descriptor to identify the particular virtual instrument to use. Logical names are used by the class
drivers to isolate the test code from the specific instruments in use and point to the specific
instruments that are being used via a configuration file. For example, a frequency response
program can access instruments with the logical names of “DMM” and “FGEN” without worrying
about which model is actually used. Whether the DMM is an HP34401A or a Fluke 45 can be
configured in MAX.
Logical names are assigned to a specific virtual instrument configuration entry point. Each virtual
instrument configuration entry contains information regarding the instrument model, address,
instrument driver location, and so on.
Virtual instruments assigned to a logical name can be changed by right-clicking on a virtual name
and selecting properties.

Virtual Instruments
• Identify a specific
model in a driver that
supports several
different instrument
models in a family
Virtual Instruments
The logical name for an instrument references a virtual instrument. The virtual instrument used for
configuring IVI class drivers here is not the same as a virtual instrument (VI) in LabVIEW. Here, a
virtual instrument is the combination of settings for a particular instrument associated with a
specific logical name.
The window above shows the properties that can be configured for a virtual instrument.
The tktds3x0, a virtual instrument, is associated with the tktds3x0 IVI-specific driver and to no
physical device.
Specific Driver Options

Drivers that support multiple instrument models must be configured with an optional parameter
that identifies the specific instrument model used. In a specific driver, you would specify this
parameter as part of the Initialize with Options function with the option string set to
DriverSetup=Model:XXX, where XXX is the model. For example, DriverSetup=Model:TDS
340A specifies that you are using the TDS 340A with the Tektronix 300 series instrument driver.
Class drivers use the Specific Driver Options field to associate a particular instrument with a
“family” driver.

Instrument Driver Configuration
• Configure the
instrument specific
driver to point to:
– Driver module (DLL)
– Function prefix (e.g.,
hp33120a_init)
– Instrument’s IVI class
(e.g., IviFgen)
Instrument Driver Configuration

This is used to configure a virtual instrument to use a specific driver. In the above slide the virtual
instrument hp33120a has been configured to use a driver - hp33120a_32.dll.
Once you select your driver, Function Prefix, and Class it should be populated with the respective
prefix and class. In the above case the prefix is hp33120a which belongs to the function generation
class. The function prefix is used to call functions within the driver.

Device Configuration
• Configure the physical

instrument to
communicate to:
– Instrument’s VISA
resource descriptor (e.g.,
GPIB::1::INSTR,
DAQ::3::INSTR,
PXI0::16::INSTR)
Device Configuration
The last step is for you to describe the device and interface information for each instrument. For the
example shown above, the Tektronix TDS220 scope is connected to the GPIB bus and has a
primary address of 1. Therefore, the Resource Descriptor is “GPIB::1::INSTR”. You can
determine the GPIB address of an instrument using the Measurement and Automation Explorer.
Examples of the Resource Descriptor string for other interfaces are shown at the bottom of this
window and are described in more detail in the IVI Driver Library User Manual.

Inherent Attributes
• Set inherent attributes

– State-caching
– Range-checking
– Query instrument status
– Record coercions
– Interchange-checking
– Spying
– Simulation
Inherent Attributes
The Inherent Attributes tab contains the settings for the various IVI software attributes. The IVI
class drivers do not contain an Initialize With Options VI, so the attributes such as state-caching,
range checking, and query instrument status are set with check boxes in the configuration window.

Virtual Channel Names
• Used as aliases to
instrument-specific
channel names
• Configured via channel
tab in Virtual instrument
properties dialog
Virtual Channel Names

The Channels tab of the Virtual Instrument Properties window is shown above.
Virtual channel names allow you to associate descriptive names with instrument-specific channels.
Virtual channel names are configured for each driver in the system and isolate the test code from
the specific channel naming conventions (such as CH1) each driver uses. You should use virtual
channel names whenever you want to develop hardware-independent test programs.

Default Setup
• Configured via
instrument driver
properties dialog
Default Setup
The Default Setup tab is used to configure instrument attributes from outside a program. You
generally use the Default Setup to configure attributes that must be set for a particular instrument,
but that may not be available for other instruments in that class.
For example, you are using a four-channel oscilloscope in an application that uses only two
channels. Since you are not going to refer to two of the four possible channels, you can disable
them by using the Default Setup.

IVI Foundation Update
• Current classes: • Future classes:

– Multimeter (DMM) – RF signal generator
– Oscilloscope – Spectrum analyzer
– Switch – Power meter
– Arbitrary waveform/ – Digital instruments
function generator – AC power supplies
– DC power supply • C and COM-based
• 50 companies architecture
IVI Foundation Update

Since its founding in August of 1998, the IVI Foundation has been working on revising the
specifications for the five instrument classes that were initially defined. Revision 2.0 of the
following class specifications were completed and subsequently voted on and approved by the
Foundation membership in December of 1999 – digital multimeters, oscilloscopes, switches or
matrices, arbitrary waveform or function generators, and DC power supplies.
In addition, the Foundation’s membership roster has been expanding steadily from nine founding
members to more than 50 current members. The membership includes end-user companies,
systems integrators, as well as all major instrument and software vendors, including National
Instruments, Agilent Technologies, Tektronix, and Rohde & Schwarz.
With the experience of developing and revising the first set of instrument classes, the Foundation
has now turned its attention to defining new instrument class specifications such as RF signal
generators, spectrum analyzers, power meters, digital instruments, and AC power supplies. In
addition, the Foundation will look into defining interfaces for the latest in software component
technology, starting with the current drive to define a COM interface.

Instrument Driver Network (IDNet)
• More than 100 instrument specific IVI drivers

available for FREE
• IVI Engine available for FREE download
• Basic IVI Class Drivers
– Allow instrument interchangeability
– Do NOT support advanced simulation & spying
– Available for FREE download
Instrument Driver Network (IDNet)

You can obtain information about IVI at ni.com/idnet to:
• Download drivers
• Get IVI Engine
• Get information on instrument driver standards
• Obtain basic IVI Class Drivers
You can obtain information about IVI at ni.com/ivi to:

• Get information on IVI drivers
You can obtain information about IVI at www.ivifoundation.org to:

• Get information on IVI class specifications

Documentation Comment Form
National Instruments encourages you to comment on the documentation supplied with our products. This information
helps us provide quality products to meet your needs.
Title: TestStand I Fundamentals Course Manual
Edition Date: February 2001
Part Number: 322317E-01
Please comment on the completeness, clarity, and organization of the manual.

____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
If you find errors in the manual, please record the page numbers and describe the errors.
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
Date manual was purchased (month/year): __________________________________________________________
Thank you for your help.

Name _______________________________________________________________________________________
Title ________________________________________________________________________________________
Company ____________________________________________________________________________________
Address _____________________________________________________________________________________
____________________________________________________________________________________________
E-mail Address _______________________________________________________________________________
Phone ( ___ )____________________________________ Fax ( ___ ) ___________________________________
Mail to: Customer Education Fax to: Customer Education

National Instruments Corporation National Instruments Corporation
11500 North Mopac Expressway 512 683 6837
Austin, Texas 78759-3504
Course Evaluation
Course _______________________________________________________________________________________
Location _____________________________________________________________________________________
Instructor _________________________________________ Date ____________________________________
Student Information (optional)

Name ________________________________________________________________________________________
Company _________________________________________ Phone ___________________________________
Instructor
Please evaluate the instructor by checking the appropriate circle. Unsatisfactory Poor Satisfactory Good Excellent
Instructor’s ability to communicate course concepts ❍ ❍ ❍ ❍ ❍

Instructor’s knowledge of the subject matter ❍ ❍ ❍ ❍ ❍
Instructor’s presentation skills ❍ ❍ ❍ ❍ ❍
Instructor’s sensitivity to class needs ❍ ❍ ❍ ❍ ❍
Instructor’s preparation for the class ❍ ❍ ❍ ❍ ❍
Course
Training facility quality ❍ ❍ ❍ ❍ ❍
Training equipment quality ❍ ❍ ❍ ❍ ❍
Was the hardware set up correctly? ❍ Yes ❍ No
The course length was ❍ Too long ❍ Just right ❍ Too short
The detail of topics covered in the course was ❍ Too much ❍ Just right ❍ Not enough
The course material was clear and easy to follow. ❍ Yes ❍ No ❍ Sometimes
Did the course cover material as advertised? ❍ Yes ❍ No
I had the skills or knowledge I needed to attend this course. ❍ Yes ❍ No If no, how could you have been better
prepared for the course? _________________________________________________________________________
_____________________________________________________________________________________________
What were the strong points of the course? __________________________________________________________
_____________________________________________________________________________________________
What topics would you add to the course? ___________________________________________________________
_____________________________________________________________________________________________
What part(s) of the course need to be condensed or removed? ____________________________________________
_____________________________________________________________________________________________
What needs to be added to the course to make it better? ________________________________________________
_____________________________________________________________________________________________
Are there others at your company who have training needs? Please list. ____________________________________
_____________________________________________________________________________________________
_____________________________________________________________________________________________
Do you have other training needs that we could assist you with? _________________________________________
_____________________________________________________________________________________________
How did you hear about this course? ❍ National Instruments web site ❍ National Instruments Sales Representative
❍ Mailing ❍ Co-worker ❍ Other _____________________________________________________________

Test Stand PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Test Stand PDF

Загружено:

Авторское право:

Доступные форматы

TestStand I Fundamentals

Course Software Version 2.0

TestStand I Fundamentals Course Manual

National Instruments Corporate Headquarters

© National Instruments Corporation iii TestStand I Fundamentals Course Manual

The Default Process Model: Test UUTs Mode ..........................................................2-10

TestStand I Fundamentals Course Manual iv ni.com

© National Instruments Corporation v TestStand I Fundamentals Course Manual

Exercise 5-1A Creating Pass/Fail Tests in LabVIEW..............................................5-27

TestStand I Fundamentals Course Manual vi ni.com

© National Instruments Corporation vii TestStand I Fundamentals Course Manual

TestStand I Fundamentals Course Manual viii ni.com

IVI Configuration .......................................................................................................A-22

© National Instruments Corporation ix TestStand I Fundamentals Course Manual

© National Instruments Corporation xi TestStand I Fundamentals Course Manual

Technical Support Options

The NI Web and TestStand Support pages offer these resources to

Telephone Support (USA):

Technical Support Options

TestStand I Fundamentals Course Manual xii ni.com

In this course, you will learn how to:

Note You can customize many of the topics discussed in this

© National Instruments Corporation xiii TestStand I Fundamentals Course Manual

Creating Sequences Operator Interface

Lesson 6 addresses how you can develop multiple user levels.

TestStand I Fundamentals Course Manual xiv ni.com

Items You Need for This Course

Items You Need for This Course

© National Instruments Corporation xv TestStand I Fundamentals Course Manual

• Exercises reinforce the topics presented

TestStand I Fundamentals Course Manual xvi ni.com

Lesson 1: Introduction to TestStand

The second part addresses the issue of “What is TestStand?”

© National Instruments Corporation 1-1 TestStand I Fundamentals Course Manual

The Role of a Test Executive

Operations different for Operations repeated for

The Role of a Test Executive

TestStand I Fundamentals Course Manual 1-2 ni.com

Our Goal for TestStand

To build an off-the-shelf test executive that:

Our Goal for TestStand

© National Instruments Corporation 1-3 TestStand I Fundamentals Course Manual

Two Products in One

TestStand I Fundamentals Course Manual 1-4 ni.com

The TestStand Architecture

Main Components of TestStand

The TestStand Architecture

This lesson continues with a detailed discussion of each component.

© National Instruments Corporation 1-5 TestStand I Fundamentals Course Manual

The Sequence Editor is:

The Sequence Editor

TestStand I Fundamentals Course Manual 1-6 ni.com

The Operator Interface:

The Operator Interface

© National Instruments Corporation 1-7 TestStand I Fundamentals Course Manual

The TestStand Engine is focused on execution, speed,

The TestStand Engine offers:

TestStand I Fundamentals Course Manual 1-8 ni.com

LV CVI DLL ActiveX TestStand HT

© National Instruments Corporation 1-9 TestStand I Fundamentals Course Manual

Application Programming Interface

CVI DLL ActiveX TestStand HT

The TestStand Architecture