Test Stand

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 retrievalsyst em,or translating, in whole or in part, without theprior 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 InstrumentsCorporation

iii

TestStand I Fundamentals CourseManual

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

TestStandIFundamentalsCourseManual

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 InstrumentsCorporation

v


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 LabWindows/CVI...................................... 5-90 Exercise 5-3B 5-3C Debugging Debugging Tests Tests Using 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 Exercise 5-7

LabWindows/CVI using The TestStand API ................................... 5-130 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


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 Interaction Database 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 Data Operation Step Type (Continued) ......................................................................8-23 Data Operation Step Type (Continued) ......................................................................8-24 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


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 Instrument Driver?....................................................................................A-2 What is an 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


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

©


ix


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.

©


xi

TestStandI Fundamentals Course Manual

Introduction

Technical Support Options Internet Support: NI Web Support Email Support TestStand Support

ni.com ni.com/ask 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 programs List Serverdatabase Example 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.


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 conceptspresented 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.

©


xiii


Introduction

Course Map Day 2

Day 1 TestStand Environment

User Management

Creating Sequences

Operator Interface

Variables, Properties, and Expressions

Report Generation

Result Collection

Database Features

Creating Test Modules in External Environments

Distributing 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.


xiv

ni.com

Introduction

Items You Need for This Course TestStand version 2.0 or later

TestStand I: Fundamentals Course Manual

Computer running Windows 95/NT/98 with an internal PC speaker (Recommended: Pentium II 266 MHz or better and 64MB RAM)

TestStand Development Course disks

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 Idirectory. You also need LabVIEW 6.0 or later, LabWindows/CVI 5.5, and Excel 97 or Excel 97 Viewer for some of the exercises.

©


xv


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


xvi

ni.com

Lesson 1 Introduction to TestStand

Lesson 1: Introduction to TestStand In this lesson, you will learn: • The role of a test executive • The basic TestStand concepts • The TestStand architecture

Introduction to TestStand 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.

©


1-1


Lesson 1

Introduction to TestStand

The Role of a Test Executive Components of a Test System: Operations different for each product tested:

Operations repeated for each product tested:

• Calibration

• Operator interfaces

• Configuring instruments

• User management

• Data acquisition

tive

u (UUT) tracking • Unit Under cTest e E st results • Archiving Te • Test flowxcontrol

• Measurements • Analyzing results

• Test reports

• Test strategies

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.


1-2

ni.com

Lesson 1


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 thatsi 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.

©


1-3


Lesson 1


What is TestStand? Two Products in One • Ready-to-run test executive • Development environment for buildinga 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.


1-4

ni.com

Lesson 1


The TestStand Architecture Main Components of TestStand • Sequence Editor • Operator Interfaces • TestStand Engine • Module Adapters

The TestStand Architecture To understand TestStand, you must understand its four major components: • Sequence Editor • Operator Interfaces •

TestStand Engine

• 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.

©


1-5


Lesson 1


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.


1-6

ni.com

Lesson 1


TestStand Architecture: 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 LabVIE W, LabWindows/CVI, Delphi, and Visual Basic

The Operator Interfac e 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.

©


1-7


Lesson 1


TestStand Architecture: TestStand Engine

The TestStand Engine is focused on execution, speed, flexibility, and long-term support/compatibility. The TestStand Engine offers: • Multithreaded sequ encing • 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.


1-8

ni.com

Lesson 1


TestStand Architecture: 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 usedifferent adapters within the same sequence.

©


1-9


Lesson 1


TestStand Architecture Samples in Source: LV, CVI, VB

Custom Operator Interface

Sequence Editor

ActiveX Clients

Application Programming Interface

TestStand Engine (ActiveX Server)

LV

CVI

DLL

Process Model


The TestStand Architecture 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 adapt ers 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 h t e 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.


1-10

ni.com

Lesson 1


Exercise 1-1 Objective: To launch TestStand and run a sequence file from the Sequence Editor

Approximate time to complete: 10 minutes

©


1-11


Lesson 1


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



1-12

ni.com

Lesson 1


Lesson 1 Summary: Introduction toTestStand

• 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 • Operator Interfaces • TestStand Engine • 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.

©


1-13


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 . Afterinput the Sequence Editor loads, you are promptedand to the log in. The default for the Login Name isadministrator password is left empty. ClickOK 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.


1-14

ni.com

Lesson 1

Introduction to TestStand Exercises

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.

©


1-15



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 ht e box when you select it.)

Note Checking the CPU test does not cause a failure, because thatstep 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.


1-16

ni.com

Lesson 1


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 anfinish execution, clickStop in the UUT Information dialog box. After you 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. SelectExecute»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 srcinal test passed. Dependencies for determining which steps execute are called preconditions. Preconditions are discussed in more detail later in this course.

©


1-17



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 sequencefile 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 inTestExec.ini in the \cfg\ directory. When the test system is distributed, the Engine Installation Wizard includesTestExec.ini in the files to be distributed. 7. When the exercise is complete, close the execution window and sequence display window by selectingFile»Close.

End of Exercise 1-1


1-18

ni.com

Lesson 1


Exercise 1-2A Running a Sequence File from the LabVIEW Operator Interface Objective:

To become fam iliar with running test sequences fro m the opera tor 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:

\Examples\OperatorInterfaces The purpose of this lesson is simply to explore the default LabVIEW operator interface and familiar with some of the differences and similarities between it become 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.

©


1-19



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.


1-20

ni.com

Lesson 1


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 clickOK . 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 clickingOK ), 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.

©


1-21



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 backto the sequence display window and clicking theTest 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.


1-22

ni.com

Lesson 1


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 selectingFile»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 selectingFile»Exit from the sequence display window.

End of Exercise 1-2A

©


1-23



Exercise 1-2B Running a Sequence File from the LabWindows/CVI Operator Interface Objective:

To become fam iliar with running test sequences fro m the opera tor 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 modifyor 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:

\Examples\OperatorInterfaces The purpose of thisand lesson is tofamiliar explore with the default LabWindows/CVI operator interface become 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.


1-24

ni.com

Lesson 1


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.

©


1-25



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 clickOK . 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.


1-26

ni.com

Lesson 1


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

©


1-27



Notes


1-28

ni.com

Lesson 2 The TestStand Environment

Lesson 2: The TestStand Environment

In this lesson, you will learn about: • TestStand sequences, step groups, and sequence files • The debugging featuresin 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.

©


2-1


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.


2-2

ni.com

Lesson 2


TestStand Sequences: Step Groups As shown below, all TestStand sequences have three step groups TestStand Sequence Cleanup Setup

Main

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.

©


2-3


Lesson 2


TestStand Sequence Files Sequence files include the MainSequence, its subsequences and steps, and all included callbacks Sequence File MainSequence

Subsequence

Setup

Setup

Main Cleanup

Pre-UUT Callback Setup

Main

Main

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 asequence namedMainSequence, which is different from the Main step group.


2-4

ni.com

Lesson 2


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 selectingConfigure»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.

©


2-5


Lesson 2


Exercise 2-1 Objective: To understand subsequences, setup and cleanup routines, and execution tracing



2-6

ni.com

Lesson 2


Exercise 2-2 Objective: To become familiar with using breakpoints and debugging tools in the Sequence Editor.


©


2-7


Lesson 2


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 andafter 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 theUser directory so that you maintain a copy of the srcinals.


2-8

ni.com

Lesson 2


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.

©


2-9


Lesson 2


Default ProcessModel Sequential Model: Test UUTs mode Pre-UUT Callback

Pre-UUT Loop

Setup Pre-UUT Main Cleanup

Main Sequence

Main Sequence

Post-UUT

Setup Main

Loop until operator quits

Generate Report

Cleanup Post-UUT Loop

The Default Process Model: Test UUTs Mode The flowchart above depicts the order in whichMainSequence 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 theMainSequence 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 MainSequence without can serve as hooks for you to customize the process model for each altering the process model directly.


2-10

ni.com

Lesson 2


SequentialModel.seq

SequentialModel.seq Execution entry points in process models, such as Test UUTs and Single Pass, use callbacks to invoke theMainSequence 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 theMainSequence 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.

©


2-11


Lesson 2


The Process Model & TestStand Architecture ActiveX Clients

Custom Operator Interface

Sequence Editor

Application Programming Interface


PROCESS MODEL Callbacks Callbacks

LV

CVI

DLL


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 flowof operations in executing sequence files. While xeecuting 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.


2-12

ni.com

Lesson 2


Exercise 2-3 Objective: To understand the default process model Approximate time to complete: 20 minutes

©


2-13


Lesson 2


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 theTestStand User Manual .


2-14

ni.com

Lesson 2


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 theExamples 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 computer s 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.

©


2-15


Lesson 2


Lesson 2 Summary: The TestStand Environment • 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 canthink of TestStand as providing fully customizable“templates” for every aspect TestStandModel.seq, and of testing. There is a default template available for the process itself, 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.


2-16

ni.com

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 cancall 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 namedCPU 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, are ina the sequence file.Sequences The light blue icon forthe thesubsequences step type denotes callsame to a subsequence. are discussed in greater detail later in the course.

©


2-17


Lesson 2


.

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 selectingFile»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.


2-18

ni.com

Lesson 2


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 theWindow 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.

©


2-19


Lesson 2


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 selectingConfigure»Station Options, which displays the Station Options dialog box.


2-20

ni.com

Lesson 2


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 theEx 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

©


2-21


Lesson 2


Exercise 2-2 Objective:

Running a Sequence File with Breakpoints and Single Stepping

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 eachStop button.


2-22

ni.com

Lesson 2


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 buttonInto

Step buttonOver

Step buttonOut Of

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 thestep 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 debuggingoptions are available in the operator interfaces. However, these tools will appear under menus rather than as task bar buttons.

End of Part A

©


2-23


Lesson 2


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, thewatch 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 windowonly 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.


2-24

ni.com

Lesson 2


3. This launches the expression browser, which is discussed in a later lesson. Click the + sign next toLocals and notice the following list of local variables.

©


2-25


Lesson 2


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.


2-26

ni.com

Lesson 2


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 theOK 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 theOK 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 thetime. different change the selections you make each Thisvariables is a simple use in of response the watchto 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 labeledContext. 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 menuBoth is easier than produce using thethe expression browser to generate expressions. methods same results.

©


2-27


Lesson 2


8. Select the same expressions to watch as in steps 2-5 using this drag-and-drop method from theContext 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


2-28

ni.com

Lesson 2


Exercise 2-3 Understanding the Sequential Process Model Objective:

To become fa miliar with the TestStand Sequential process model by e xecuting 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.

©


2-29


Lesson 2


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 theMainSequence 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 invokea 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 calledexecution entry points. Execution entry points appear in theExecute menu of the Sequence Editor or operator interface. Complete the following steps to runEx 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 theOK 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 theOK button to close the banner prompt. The process model now displays the UUT Information dialog box again. Type in another serial number and click theOK button to loop on the sequence again. Repeat this procedure for several serial numbers and click theStop 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.


2-30

ni.com

Lesson 2


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 \Components\NI\Models\ TestStandModel\ and open SequentialModel.seq, the default TestStand process model sequence file. 2. Select Sequencescontained from the sequence windowView selector. This shows All all sequences in SequentialModel.seq , as shown on the next page. SequentialModel.seqhas 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 theExecute 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.

©


2-31


Lesson 2


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 selectingToggle 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 theWindow 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 selectDebug»Step Over until the sequence is paused with the execution pointer on the MainSequence Callback step. Click theStep Into button or select Debug»Step Into to step into the main sequence. Notice that the execution has now proceeded to the steps of theEx 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 theResume 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


2-32

ni.com

Lesson 2


Notes

©


2-33


Lesson 2


Notes


2-34

ni.com

Lesson 3 Creating Sequences

Lesson 3: CreatingSequences

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.

©


3-1


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.


3-2

ni.com

Lesson 3

Creating Sequences

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, T estStand 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 • Adapter —Creates a step that does not call a test module

©


3-3


Lesson 3

Creating Sequences

Adding a Step to a Sequence: 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 • • • • • • • •

StatementPopup Message 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 theInsert 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 T ( rue 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.


3-4

ni.com

Lesson 3

Creating Sequences

Step Types Numeric limit test

Property Loader

• Measured value • Limits (H, L)

Database:

String limit test • Returned String

• Open/Close Database • Open/Close SQL Statement • Data Operations

• ComparisonString

Synchronization:

Pass/fail test • Result (T/F)

• Lock • Semaphore • Rendezvous • Queue

Action Sequence call Label

Notification •• Wait • Thread Priority • Batch Synchronization • Batch Specification

Statement

IVI:

Goto

• Dmm • Scope • Fgen • Tools

Message popup

User-defined step type

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.

©


3-5


Lesson 3

Creating Sequences

Adding a Step to a Sequence: Step 3 - Specify the Test Module • Each step may have an associated test module • Multiple steps can access the same module

Test Modules Sequence Step 1

LabVIEW VI

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. Atest 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 selectSpecify 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.


3-6

ni.com

Lesson 3

Creating Sequences

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.

©


3-7


Lesson 3

Creating Sequences

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 subdirectory of the configured search directories

The third option shows a path that is relative to one of the 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.


3-8

ni.com

Lesson 3

Creating Sequences

Adding a Step to a Sequence: 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 selectingProperties, 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

©


3-9


Lesson 3

Creating Sequences

Step Properties: General Tab

Step Properties: General Tab The Properties dialog box opens with a view ofGeneral 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 anEdit 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 selectSpecify 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.


3-10

ni.com

Lesson 3

Creating Sequences

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, displays the conditions that must be true for the current step to execute.You can organize several precondition statements by usingAnyOf 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).

©


3-11


Lesson 3

Creating Sequences

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 Sequen ce Failur e • Debugging features: – Run mode: normal, skip, force pass, force fail – Breakpoint – Ignore Run-time Errors

Step Properties: Run Options Tab 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: •

Pre Load 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 closing sequence file (fast execution and completion of sequence, slower when closingwhen sequence). Note Execution time refers hereto the time for the entire test sequence(s) tocomplete.


3-12

ni.com

Lesson 3

Creating Sequences

Step Properties: Run Options Tab (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 toSKIPPED.

• Force Pass —Does not execute the module, but sets the step status toPASSED. • Force Fail —Does not execute the module, but sets the step status toFAILED. 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. •

©

DoNot Evaluate Precondition —Does not evaluate the precondition for the step when running in interactive mode.


3-13


Lesson 3

Creating Sequences

Step Properties: Run Options Tab (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 theToggle Breakpoint command in the pop-up menu.

•

St ep Failure Causes Sequence Failure —Specifies whether TestStand sets the sequence status to FAILED when the step status isFAILED.

•

Ignore Run-Time Errors —Allows any run-time errors generated by this step to be ignored for debugging purposes.


3-14

ni.com

Lesson 3

Creating Sequences

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 theDestination pulldown menu (appears if the option is chosen).

• Terminate execution —Terminates the sequence execution. • Call Sequence —Calls a particular sequence specified in theSequence pulldown menu. •

©

Break—Suspends execution at this step. You can then use the debugging tools available to step through the sequence, or use theResume option in the Debug menu to continue the sequence execution.


3-15


Lesson 3

Creating Sequences

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

Step Properties: Loop Options Tab 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 isPASSED. – 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.


3-16

ni.com

Lesson 3

Creating Sequences

Step Properties: Loop Options Tab (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.


3-17


Lesson 3

Creating Sequences

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 E xecute 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.

•

BatchSynchronization —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.


3-18

ni.com

Lesson 3

Creating Sequences

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.

©


3-19


Lesson 3

Creating Sequences

Exercise 3-1 Objective: To create steps in the Sequence Editor Approximate time to complete: 20 minutes


3-20

ni.com

Lesson 3

Creating Sequences

Exercise 3-2 Objective: To create and edit a new sequence file using step looping Approximate time to complete: 20 minutes

©


3-21


Lesson 3

Creating Sequences

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.


3-22

ni.com

Lesson 3

Creating Sequences

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 subsequ ence will be returned to the calling sequence located on the client computer.

©


3-23


Lesson 3

Creating Sequences

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 andyou will see a report which displays thewaveform 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.


3-24

ni.com

Lesson 3

Creating Sequences

Exercise 3-3 Objective: To create a sequence using different step types Approximate time to complete: 20 minutes

©


3-25


Lesson 3

Creating Sequences

Optional Exercise 3-4 Objective: To show how TestStand runs multiple sequence s in parallel Approximate time to complete: 10 minutes


3-26

ni.com

Lesson 3

Creating Sequences

Lesson 3 Summary: CreatingSequences

• 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).

©


3-27


Lesson 3

Creating Sequences Exercises

Exercise 3-1 Creating Steps in the Sequence Editor Objective:

To add new ste ps 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 stepAlarmStart. You can always rename a step later by right-clicking on it and selecting rename from the context menu.


3-28

ni.com

Lesson 3 Creating Sequences Exercises

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.

©


3-29


Lesson 3


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

3-30

ni.com


6. Click on the Specify Module button. This brings up the Edit DLL Call dialog box. Click theBrowse button and select the fileDllfuncs.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. ClickOK 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 theStopBeep Functionfunctions Name Control. For(the thisprocess exercise, the a StartBeep and are used foronly adding step for the StopBeep function is described later).

©


3-31


Lesson 3


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 thefunction 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.


3-32

ni.com


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, clickOK to finish.

©


3-33


Lesson 3


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 thatRun 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 Failits—TestStand does not execute the step evaluate preconditions. Instead, TestStand setsand thedoes statusnot of the step to FAILED automatically.


3-34

ni.com


•

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 StartBeep the case of a step that is specified as an Action step such as the 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.

©


3-35


Lesson 3


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 aFAILED 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.


3-36

ni.com


11. Create another action step by right-clicking on theAlarmStart 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

©


3-37


Lesson 3


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 chooseto 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.


3-38

ni.com


Right-click in the sequence window and selectInsert 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. ClickOK 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.

©


3-39


Lesson 3


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 selectProperties. 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.


3-40

ni.com


7. Save the finished sequence file before moving on to the next exercise.

End of Exercise 3-2

©


3-41


Lesson 3


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 becalled 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-42

ni.com


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 selectingInsert 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.

©


3-43


Lesson 3


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 selectInsert Step»Action. Rename the step to Pick Test to Fail.

8. Right-click on this action step and choose Specify Module.


3-44

ni.com


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. ClickOK 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.

©


3-45


Lesson 3


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 theInstruction Set Test, Cache Test, and FPU Test steps, as shown below.


3-46

ni.com


14. Right-click on theRegister 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 theInstruction Set Test step, except select Instruction Set Test.vi. 17. Cache Repeat Test.vi all of step 14 and 15 for theCache Test step, except select .

©


3-47


Lesson 3


18. Repeat all of step 14 and 15 for theFPU Test step, except selectFPU 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 parameterCPUFail. Save the sequence and use theView Ring to select the MainSequence sequence again.


3-48

ni.com


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 theUse 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. Not ice 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 theUse Prototype of Selected Sequence option is checked.

©


3-49


Lesson 3


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.


3-50

ni.com


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

©


3-51


Lesson 3


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 theC/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-52

ni.com


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.

©


3-53


Lesson 3


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.


3-54

ni.com


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: Value Expression:

©


seqContextCVI ThisContext

3-55


Lesson 3


11. Select the result parameter and fill in the following information: Parameter:

result

Value Expression: Result Action:

Step.Result.PassFail No Action

12. Select the errorOccurred parameter and fill in the following information: Parameter:

errorOccurred

Value Expression:

Step.Result.Error.Occurred

Result Action:

No Action

13. Select the errorCode parameter and fill in the following information: Parameter:

errorCode

Value Expression:

Step.Result.Error.Code

Result Action:

No Action

14. Select the errorMsg parameter and fill in the following information:


Parameter:

errorMsg

Value Expression:

Step.Result.Error.Msg

3-56

ni.com


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. ClickOK to exit the Edit DLL Call dialog.

15. Select the MainSequence from the View Selector Ring . Save the sequence and run it by clicking theRun 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

©


3-57


Lesson 3


Optional Discu ssion 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.

Feature Test functions can have a variety of prototypes

C/CVI Standard DLL Flexible Prototype Prototype No

Yes

Allows you to pass any argument to a test function directly

No

Yes

Automatically passes a predefined set of common arguments to each test function

Yes

No

Allows debugging C source files from TestStand

Yes

Allows debugging DLL functions from TestStand

Yes 1,2

Code modules can be C source files, object files, or static libraries

Yes

No (DLLs only)

Can call DLLs created with MSVC++, Borland C++, Delphi, or another compiler

Yes

Yes

Backward compatible with LabWindows/CVI Test Executive Toolkit

Yes

No

Can create source code from code templates Can use TestStand API within code modules

Yes Yes

1,2

4

No Yes1,3

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.


3-58

ni.com


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

©


3-59


Lesson 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.


3-60

ni.com


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

©


3-61


Lesson 3


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


3-62

ni.com


4. Click onthe runforever.seq [Executing] window. The execution window continues running. Notice that with this window as the active window, theRun button is once again enabled.

©


3-63


Lesson 3


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 theX button in the top right corner of the execution window or selectingTermi nate All Executions under the debug menu. When you click this button, the following dialog box appears. Select the option toTerminate 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.


3-64

ni.com


7. When finished closing all sequence execution windows, close the sequence file to complete the exercise.

End of Exercise 3-4

©


3-65


Lesson 3


Notes


3-66

ni.com

Lesson 4 TestStand Parameters, Variables, and Expressions

Lesson 4: TestStand Parameters, Variables, and Expressions

In this lesson, you will learn about: • Parameters • Local Variables • Sequence File Global Variables • Station Global Variables • RunState Properties • The Expression Browser (to view variablesand 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 propert ies in expressions throughout the TestStand environment.

©


4-1


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.


4-2

ni.com

Lesson 4


TestStand Parameters • Directly pass data between calling sequence and subsequence • Define in Parameters tab of sequence display window Sequence File Subsequence 1 Calling Sequence

Parameter 1 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 theParameters 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.

©


4-3


Lesson 4


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 of10, while the second parameter is passed the value of a parameter in the calling sequence. Under theHow 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 ru n time.


4-4

ni.com

Lesson 4


Local Variables • Share data among all steps in a sequence • Access using expressions and/or test modules Sequence A Step 1

Step 2

Seq A Locals

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.

©


4-5


Lesson 4


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.


4-6

ni.com

Lesson 4


Exercise 4-1 Objective: To add a local variable to a sequence and pass data between steps


©


4-7


Lesson 4


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 Step 2

Seq B Locals

Sequence File Global Variabl es 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 es quence file has its own unique set of global variables.


4-8

ni.com

Lesson 4


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

©


4-9


Lesson 4


Station Globals Station globals have the largest scope: they share data between multiple sequence files

Sequence File A Sequence A Step 1

Step 2

Seq A Locals

Sequence B Step 1

Step 2

Seq File Globals

Seq B Locals

Station Globals

Sequence File B Sequence A Step 1

Step 2

Seq A Locals

Sequence B Step 1

Step 2

Seq File Globals

Seq B 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 toStationGlobals.ini each time the Sequence Editor is closed. This enables TestStand to keep track of data values even when it is shut down. Thi s 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 StationGlobals.ini TestStand API includes an ActiveX method that may be called to update explicitly.


4-10

ni.com

Lesson 4


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

©


4-11


Lesson 4


RunState Subproperties • Some subproperties are not filled until run time since their contents depend on the invoked sequence

Empty

Filled

RunState Subproperti es It is important to note that some of the properties listed under theRunState property object are empty when a sequence is not being executed. To find which subproperties are available when a sequence is not being executed, selectView»Browse Sequence Context from the menu and expand the RunState property object. The majority of theRunState subproperties will be listed at this time. However, some of the subproperties that are containers will not contain any information, such as theRoot, Main, Caller, and Execution properties. To view whichRunState 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 theRunState property object to view the available properties according to the current sequence invocation.


4-12

ni.com

Lesson 4


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 theRunState property in different ways. Thisexample obtains theUUT serial number from theRoot subproperty. Since the Root subproperty only contains information when the sequence is executing, the UUT serial number will only be visible via theRoot subproperty at run-time. Follow the steps below to find the UUT serial number in theRunState 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.

©


4-13


Lesson 4


The Expression Browser • Simplifies building complex expressions • Launch from the Browsebutton next to any expression window • Includes two tabs: – Variables/Properties – Operators/Functions

The Expression Browser The TestStand Expression Browser allows you to use theTestStand 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 aBrowse 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.


4-14

ni.com

Lesson 4


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 aCheck 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.

©


4-15


Lesson 4


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 parametersfrom 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 srcinally.


4-16

ni.com

Lesson 4


Exercise 4-2 Objective: To create locals, file globals, and station globals and use the expression browser to understand the scope of variables


©


4-17


Lesson 4


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



4-18

ni.com

Lesson 4


Exercise 4-4 Objective: To use expressions and parameters in subsequence executions


©


4-19


Lesson 4


Exercise 4-5 Objective: To create a test which dynamically selects which sequence to run Approximate time to complete: 20 minutes


4-20

ni.com

Lesson 4


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 TestStandenvironment

• 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 RunStat e 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 T estStand sequence editor, the next lesson will discuss how test programs from external development environments interact with TestStand.

©


4-21


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 theC:\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.


4-22

ni.com


3. Click on the Main tab. You must change the module called during the ROM Test step at this point. Right-click on theROM 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 arelative path when TestStand prompts for how the path should be stored. Select theShow 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 NationalInstruments 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-23



4. Edit the StartBeep step to set the tone using theFrequency local variable. Right-click on the StartBeep step and select Specify Module. In the Parameters section, delete the constant value of1000 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 haveLocals.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


4-24

ni.com


Exercise 4-2 Examine the Uses and Differences between Locals, File Globals, and Station Globals Objective:

To create lo cal variables, file global variables, and stat ion 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 Variable s 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 theLocals 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 variableLocalA.

©


4-25



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 abrowse 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. ClickClose 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.


4-26

ni.com


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 fileEx 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 selectAll Sequences to see all the sequences in this sequence file.

Notice that there is only one sequence, namedMainSequence, in this sequence file.

©


4-27



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.


4-28

ni.com


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 selectInsert Global»Number. Name this variable TestFileGlobalA. Save the sequence file by selectingFile»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 theView 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 inMainSequence is available for use in all other sequences in theEx 4-2 All Variables2.seq sequence file. In this way, you can use sequence file

©


4-29



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 selectInsert 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. ClickClose 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


4-30

ni.com


beside the station global calledTS 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 theLogin 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

©


4-31



Exercise 4-3 Objective:

Using Expressions to Change Step Properties

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


4-32

ni.com


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-33



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 theVideo Test step. Click the + sign beside Limits to display the Low and High limit properties as shown below. After selecting theLow property, click the Insert button.


4-34

ni.com


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.

©


4-35



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. ClickOK to close the Expression Browser.


4-36

ni.com


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.

©


4-37



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 theBrowse 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 cursorTest”]. after RunState.Sequence.Main[“Video 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.


4-38

ni.com


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 clickOK to return to the Edit Statement Step dialog box and ensure that it appears as shown below.

©


4-39



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.



4-40

ni.com


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 dat a 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


4-41



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.


4-42

ni.com


10. Click on the Browse button in the Post Expression. In the Variables/Properties tab, right-click on Locals and selectInsert String as shown. Name the new variableCPUType.

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")

©


4-43



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 theEdit 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"


4-44

ni.com


Button 4

"4"

Cancel Button

None

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

©


4-45



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 seq uence 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 theLoad 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


4-46

ni.com


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 clickBrowse and use the expression browser to create the expression:

RunState.Sequence.Main["Specify Number of CPUs"] .Result.ButtonHit

©


4-47



31. Click on the CPUFail parameter. 32. Select the Enter Expression option. 33. Enter the following expression into its string control or clickBrowse and use the expression browser to create the expression: Locals.CPUFail


4-48

ni.com


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.

©


4-49



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 selectingToggle 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 selectingDebug»Step Into. Notice that the Call Stack pane listsINTELProcessor 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.


4-50

ni.com


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 selectingExecute»Restart.

©


4-51



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 selectingDebug»Step Into. Notice that the Call Stack pane listsAMDProcessor sequence at the bottom of the call stack. 15. Complete the execution by selectingDebug»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.



4-52

ni.com


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 thePreconditions expression of each step to determine which step will execute.

©


4-53



Save and close the sequence.

End of Exercise 4-5


4-54

ni.com


Notes

©


4-55



Notes


4-56

ni.com

Lesson 5 Creating Test Modules in External Environments

Lesson 5:Creating Test Modu les 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 directl y from TestStand.

©


5-1



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 e ofas test a different adapter whichtyp acts anuses 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.


5-2

ni.com


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 Error Data

• LabVIEW Adapter

Test Data

• LabWindows/CVI Adapter

Data Transfer in TestStand There are three ways to pass data between an external test module and TestStand: •

Pass parameters directly usingpredefined 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.

©


5-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.


5-4

ni.com


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.

©


5-5



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 TestData

TestError

Result

Flag

Measurement InBuffer

Location Code

OutBuffer

Message

ModPath ModFile SeqContextCVI AdditionalData

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


5-6

ni.com


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 the UUT. above structure is for reporting errors with the test system itself, not for test failures relatedthat to the 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.

©


5-7



Data Transfer inTestStand Method 2—Passing parameters directly without using structures TestStand Engine

Data Space Data 1 Data 2

Test Module

• Flexible DLL Adapter • ActiveX Automation Adapter

Data Space Data 1 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.


5-8

ni.com


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 TestStand step using structures 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 Approximate time to complete: 35 minutes

©


5-9



Exercise 5-2A, 5-2B, or 5-2C 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 TestStand step using structures 52-C Objective: To create a numeric test in a DLL called with the DLL Flexible Prototype Adapter Approximate time to complete: 15 minutes


5-10

ni.com


Exercise 5-3A, 5-3B, or 5-3C 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 Approximate time to complete: 10 minutes

©


5-11



Data Transfer in TestStand 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 Engine

TestStand ActiveX Object

Step Properties

Test Program

TestStand Variables

•Any programm ing language thatsupports 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.


5-12

ni.com


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).

©


5-13



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 Ac tiveX 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.


5-14

ni.com


TestStand and ActiveX Automation • The TestStand Engine itself is an ActiveX server

Sequence Editor

Operator Interface

(ActiveX Clients)

• The Sequence Editor and operator interfaces are ActiveX clients • In addition, test modules can also be ActiveX clients (to access properties and methods of the engine)


LV Test

CVI Test

VB Test

(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.

©


5-15



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 theG Programming Reference Manual. Note To use TestStand 2.0 VIs with LabVIEW, you must have LabVIEW 5.1 or later.


5-16

ni.com


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 an d 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.

©


5-17



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.


5-18

ni.com


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 variableNum1 to 5.0. In the next set of exercises, you will use ActiveX to pass data within either LabVIEW or LabWindows/CVI.

©


5-19



Exercise 5-4A, 5-4B, or 5-4C 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 Approximate time to complete: 20 minutes


5-20

ni.com


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

5-5Buses Objective: To write a simple Numeric Limit Test that the C/CVI Standard Prototype Adapter Approximate time to complete: 20 minutes

©


5-21



Exercise 5-6A or 5-6B 5-6A Objective: To use the TestStand API to pass data between TestStand andLabVIEW 5-6B Objective: To use the TestStand API to pass data between TestStandand LabWindows/CVI Approximate time to complete: 35 minutes


5-22

ni.com


Exercise 5-7 5-7 Objective: To pass data between TestStand and your test module using the DLL Flexible Prototype Adapter Approximate time to complete: 35 minutes

©


5-23



Using TestStand Code Templates • TestStand allows test developers to create code in an externalenvironment 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 redundantprogramming

Using TestStand Code Templates Another powerful feature of TestStand is the ability to create tests in LabVIEW or Create Code option LabWindows/CVI from within the TestStand Sequence Editor. Selecting the 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 selectCreate Code. This feature allows you to develop your test sequences in an efficient and consistent way.


5-24

ni.com


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 theCode 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.

©


5-25



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.


5-26

ni.com

Lesson 5 Creating Test Modules in External Environments Exercises

Exercise 5-1A Creating Pass/Fail Tests in LabVIEW Objective:

To create a pa ss/fail test in LabVIEW and pass the re sults 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 theKeyboard 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 nameEx 5-1A Keyboard

©


5-27



Diagnostics.vi, and select the C:\Exercises\TestStand I \VIs directory. Notice that the search returnsFile 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 theVIs subdirectory.


5-28

ni.com


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 namedEx 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 theReport 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.

©


5-29



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 theFunctions»User Libraries»TestStand subpalette.


5-30

ni.com


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.

©


5-31



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. ClickOK 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 theLabVIEW 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. SelectTools»Build Application or Shared Library (DLL)… to open the Build Application or Shared Library (DLL) - New script dialog box.


5-32

ni.com


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, theSupport file directory field is automatically updated toC:Exercises\Teststand I \VIs\data. d. Leave other options set to default. Note that under Build Options, the default selection is to createSingle target file containing all VIs. 3. The resulting New script dialog box should resemble the following image.

©


5-33



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 clickingOpen 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.


5-34

ni.com


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. SelectBuild. This shows the progress bar and when complete it will indicateBuild 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 you the previously created DLLs and its supporting filesor will be overwritten. At this point can either continue and overwrite existing files 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 selectSpecify 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.

©


5-35



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, SpecifyLocals.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. SpecifyLocals.TestData for the Value Expression. Choose C Struct for the Category. Select TestData for the Struct Type. The dialog box should appear as follows.


5-36

ni.com


Note When using the C Struct category you must have the corresponding datastructure defined within the TestStand environment and have theAllow 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 selectingExecute»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 sequence file window.

End of Part C End of Exercise 5-1A

©


5-37



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. 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 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 theKeyboard 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.


5-38

ni.com


Right-click below the steps of the sequence and selectInsert 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 theModule 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 returnsFile 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 onCreate Code.

©


5-39



When prompted, clickOK 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 clickingOK .


5-40

ni.com


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, calledKeyboardDiagnostics.

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 theCreate Code button.

©


5-41



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 nameKeyboard 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.


5-42

ni.com


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 Part B: Configuring the Step Properties 1. In the TestStand Sequence Module Call dialog box. Editor, click OK to exit the Edit C/CVI 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 theKeyboard Diagnostics step to open the Keyboard Diagnostics PassFailTest Properties dialog box. Click thePreconditions 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 Insert AllOf.

©


5-43



f. Click Keyboard Test. g. Click Insert Step Fail.

3. Click OK to exit the Preconditions dialog box. Then, clickOK 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. ClickOK 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 theBuild»Target Type menu.


5-44

ni.com


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 selectSymbols Marked for Export, as shown.

6. The KeyboardDiagnostics function is marked for export with the dllexport definition. ClickOK to close the DLL Export Options window. To close the Target Settings window, clickOK 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

©


5-45



Dynamic Link Library (*.dll). Notice that the extension is changed automatically, and TestStand also finds the newly createdKeyboard 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, selectFile»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 End of Exercise 5-1B


5-46

ni.com


Exercise 5-1C Creating Pass/Fail Tests for the DLL Flexible Prototype Adapter Objective:

To create a p ass/fail test in a DLL and pa ss the result to a TestStand step usi ng the DLL Flexible Prototype Adapter. It is important to understand the different types of tests you can create in 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 1. Launch the Sequence Editor. Select File»Open and select the sequence 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 selectInsert 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.

©


5-47



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, clickCreate Code. The following dialog box appears.


5-48

ni.com


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, clickYes to unload the current project andOK 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

©


5-49



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;


5-50

ni.com


The DLL test function uses pointers to pass data between TestStand and the test function. In theKeyboardDiagnostics 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.

©


5-51



13. Confirm the DLL target settings by selectingBuild»Target Settings. Make certain the settings match those in the figure below.

14. Verify which functions LabWindows/CVI exports by clicking the Change button in the Exports area. Be sure to selectSymbols Marked for Export, as shown below.

15. The KeyboardDiagnostics function is marked for export with the dllexport definition. ClickOK to close the DLL Export Options window. To close the Target Settings window, clickOK again. 16. Create a DLL by selectingBuild»Create Release Dynamic Link Library.


5-52

ni.com


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 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 theKeyboard Diagnostics step. 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 Insert AllOf.

©


5-53



f. Click Keyboard Test. g. Click Insert Step Fail.

3. Click OK to exit the Preconditions dialog box. ClickOK 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 selectingExecute»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. ClickOK to continue. Click Stop to end the execution.

End of Part B End of Exercise 5-1C


5-54

ni.com


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

©


5-55



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.


5-56

ni.com


6. You must create the code for this VI, so click on Create VI. When prompted for the directory to save in, selectC:\Exercises\ TestStand I\VIs (if not already selected) and clickOK 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.

©


5-57



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 theTestData 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 theTest 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 Part B: Configuring the Step Properties 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


5-58

ni.com


Video Diagnostics step to open the Video Diagnostics NumericLimitTest Properties dialog box. Click thePreconditions 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 Video Test. g. Click Insert Step Fail.

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 selectingExecute»Single Pass. Select the video test to fail.

©


5-59



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 theLabVIEW 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. SelectTools»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.


5-60

ni.com


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 toC:\Exercises\Teststand I \VIs\data. d. Leave other options set to default. Note that under Build Options, the default selection is to createSingle 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

©


5-61



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. SelectBuild. This shows the progress bar and when complete it will indicateBuild 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 theDLL 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 theVideo 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.


5-62

ni.com


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, SpecifyLocals.Error for the Value Expression. Choose C Struct for the Category. Select CustomError for the Struct Type. The dialog should appear as follows.

©


5-63



Note When using the C Struct category youmust have the corresponding data structure defined within the TestStand environment and have theAllow 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 sequence file window.


5-64

ni.com


End of Part C End of Exercise 5-2A

©


5-65



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. 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 modulepasses 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 1. Launch the Sequence Editor. Select File»Open and select the sequence 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 theVideo 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 Adapter Selection Ring. 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/CVIstep Standard between step. theRAM Diagnostics KeyboardAdapter Diagnostics and thePrototype 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 theEdit Limits option. Click OK to return to the sequence file.


5-66

ni.com


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. ClickOK to return to the C/CVI Edit Module dialog box, which should now appear as shown below.

©


5-67



Click on Create Code. When prompted, clickOK to confirm that the project file should be created in theC:\Exercises\TestStand I\CVI Project Files subdirectory. Make sure this subdirectory is selected; if not, select this directory before clickingOK. 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, calledVideoDiagnostics.

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 thetestData structure. Also, use replaceStringFuncPtr to provide a string to theoutBuffer string. Make sure your code appears exactly as shown.


5-68

ni.com


Save the source file asVideo 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 bebuilt is configured tobe a debug version of the DLL by selectingBuild»Configuration»Debug. 11. Confirm the DLL target setting by selecting Build»Target Settings. Make certain the settings match those in the figure below.

©


5-69



12. Verify which functions LabWindows/CVI exports by clicking the Change button in the Exports area. Be sure to selectSymbols Marked for Export, as shown below.

13. The VideoDiagnostics function is marked for export with the dllexport definition. ClickOK . Then, click OK again to close the Target Settings window. 14. Create a DLL by selecting Build»Create Debuggable Dynamic Link Library.


5-70

ni.com


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. ClickOK to exit the Edit C/CVI Module Call dialog box. 2. The Video Diagnostics step should execute only if theVideo Test step fails and the Powerup Test and CPU Test steps have passed. Double-click Video Diagnostics step. Click the Preconditions button.on Setthe 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 Insert AllOf. f. Click Video Test. g. Click Insert Step Fail.

©


5-71



3. Click OK to exit the Preconditions dialog box. ClickOK again to exit the Step Properties dialog box. 4. Save the sequence as C:\Exercises\TestStand I\Ex 5-2B Creating Numeric Limit Tests Using CVI.seq. Execute the sequence by selectingExecute»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 theoutBuffer 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 End of Exercise 5-2B


5-72

ni.com


Exercise 5-2C Objective:

Creating Numeric Limit Tests for the DLL Flexible Prototype Adapter

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 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 Adapter Selection Ring. 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 theRAM 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.

©


5-73



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


5-74

ni.com


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. ClickNo .

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.

©


5-75



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 andC String Buffer when you intend to modify the string. For theValue Expression, click the Browse button and insert, Step.Result.ReportText.


5-76

ni.com


Notice that the Function Prototype and Function Call fields at the bottom of the window are updated as you fill in the fields. TheModule 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 theSource 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.

©


5-77



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


5-78

ni.com


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 displaysFile Not Found , select, Edit»Add Files to Project»Source (*.c) . Then double-click Ex 5-2C Video Diagnostics.c, which you just created. Click theOK button to add this to the project. 15. In the LabWindows/CVI Project window, double-clickEx 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, besure to use proper syntaxin your code.

©


5-79



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 selectingBuild»Configuration»Debug.


5-80

ni.com


22. Confirm the DLL target settings by selectingBuild»Target Settings. Make certain the settings match those in the figure below.

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 . SelectProject the function panel file C:\Exercises\TestStand I\CVI 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 theEx 5-2C Video Diagnostics.dll by selecting Build»Create Debuggable Dynamic Link Library.

©


5-81



28. Return to the sequence editor. In the Edit DLL Call dialog box, click the Browse button for the DLL Pathname control and select theEx 5-2C Video Diagnostics.dll that you just created. When asked how you resolve the path to this code module, selectUse 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 theVideo 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. 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 Insert AllOf. f. Click Video Test.


5-82

ni.com


g. Click Insert Step Fail.

3. Click OK to exit the Preconditions dialog box. ClickOK again to exit the Step Properties dialog box. 4. Save the sequence as C:\Exercises\TestStand I\Ex 5-2C Creating Numeric Limit Tests With DLL Adapter.seq. Execute the sequence by selectingExecute»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 theoutBuffer string returned from the code module. It should contain the string“no adapter present.”

©


5-83



6. When finished, save and close the sequence file.

End of Part B End of Exercise 5-2C


5-84

ni.com


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.

©


5-85



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-86

ni.com


5. From the Video Diagnostics VI front panel, selectWindows»Show Diagram. Select Windows»Show Tools Palette. In the Tools palette, click on the Breakpoint tool (the stop sign).

©


5-87



6. With the Breakpoint tool, click on any wire to set a breakpoint. Run the VI bytoclicking the code. Run button. You can use the LabVIEW tools debug the Click the Pause/Continue button todebugging 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 theTest 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 debuga 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 notthe 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.


5-88

ni.com


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.


©


5-89



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. 1. In the Sequence Editor, select File»Open and select the sequence file

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 theC/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.


5-90

ni.com


Execute Steps in an External Instanc e 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 file. Execute Steps In-Process tells TestStand not C tosource launchcode 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. ClickDone in the Adapter Configuration dialog box.

©


5-91



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.


5-92

ni.com


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 configurationoption to run LabWindows/CVI Tests In Process. SelectConfigure»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. ClickDone in the Adapter Configuration dialog box. To stop the LabWindows/CVI projecttscvirun.prj, which is used for debugging, press to terminate execution. Finally, close the LabWindows/CVI IDE. When finished with the exercise, save and close the sequence file.


©


5-93



Exercise 5-3C Objective:

Debugging Tests that use the DLL Flexible Prototype Adapter

To debug code modules that use the DLL Flexible Prototype Adapter. Exercise 5-3B shows how to step into code modules called with theC/CVI Standard Prototype Adapter. In contrast, you cannot step into code modules that are called with theDLL Flexible Prototype Adapter. However, this exercise demonstrates how to debug your test code rom f your C development environment. 1. In the Sequence Editor, select File»Open and select the sequence file 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 theVideo Diagnostics step calls Ex 5-3C Video Diagnostics.dll. Remember that the solutions for each exercise can be found in theC:\Solutions\TestStand I directory. 2. Exit the sequence editor. 3. In LabWindows/CVI, select File»Open»Project. Open the project file C:\Exercises\TestStand I\CVI Project Files\Ex 5-3C 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);


5-94

ni.com


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 launchtothe sequence editor from LabWindows/CVI. If prompted save changes, select Yes .

©


5-95



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 theVideo 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 theC/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


5-96

ni.com


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 anyTestStand 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. 2. Right-click on the Video Diagnostics step and select Specify 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.

©


5-97



When prompted for the directory to save in, selectC:\Exercises\ TestStand I\VIs (if not already selected) and clickOK 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.


5-98

ni.com


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 theSequence Context control from the TestStand subpalette as shown below.

©


5-99



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 selectShow 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


5-100

ni.com


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 theStep.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.

5-101



The TestStand ActiveX API functions are in theTestStand subpalette as shown.

In this exercise, a random number is passed into theNew 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 theNew 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


5-102

ni.com


Part C: Configuring the Step Properties Notice that the VI is now found. ClickOK to leave the Edit LabVIEW VI Call dialog box. TheVideo Diagnostic step should appear between the RAM Diagnostics step and the Keyboard Diagnostics step. 1. The Video Diagnostics step should execute only if theVideo Test step fails and the Powerup Test and CPU Test steps have passed. Double-click on theVideo Diagnostics step. Click the Preconditions button. Set the preconditions as shown below.

2. Save the sequence as C:\Exercises\TestStand I\Ex 5-4A Using the ActiveX API with LabVIEW.seq. Execute the sequence by selectingExecute»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 theresults for this test.

©


5-103



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 theReport Text string returned from the code module if the value is greater than 10.



5-104

ni.com


Exercise 5-4B Using the ActiveX API in Code Modules with LabWindows/CVI Objective:

To pass numer ic data and a st ring from a code m odule to TestStand using Ac tiveX. 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 veryuseful because you can use itto 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. 2. Right-click on the Video Diagnostics step and select Specify Module. Fill in the resulting dialog boxes as shown below. After you complete the dialog boxes, theVideo Diagnostics step calls the VideoDiagnostics function created in Exercise 5-2B. Remember that the solutions for all exercises are in theC:\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.

©


5-105



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 launchesLabWindows/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, loadTSAPICVI.fp from the \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.


5-106

ni.com


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.

©


5-107



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 thetTestData 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. cursor Select Code »Insert Call to insert thisfile. function where your Video Diagnostics.c last was in theFunction 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 selectSet String Value. Fill in the parameters as shown below and insert this function call in the Video Diagnostics.c file.


5-108

ni.com


12. Return to the Video Diagnostics.c file and be sure that you filled in the function calls as shown. Note The code shown is for illustration only, besure to use proper syntaxin your code. 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 clickOK to close the Edit C/CVI Module Call dialog box. 14. Switch to the Sequence Editor and right-click on theVideo Diagnostics step in the sequence file. SelectBrowse Sequence Context from the context menu. In this tree, select Step.Result.Numeric as shown below. This is the same Lookup String passed into theTS_PropertySetValNumber function call. Notice that you could have copied this variable/property with theCopy Property Path button and pasted it into the function call.

©


5-109



Notice also that any property or variable could be referenced with similar Lookup Strings. 15. Finally, check the error status with a macro defined intsutil.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. Note The code shown is for illustration only, besure to use proper syntaxin your code. #include "stdtst.h" #include "tsutil.h" void __declspec(dllexport) TX__TEST VideoDiagnostics(tTestData *testData, tTestError *testError) { int error = 0; ErrMsg errMsg; ERRORINFO errorInfo; double measurement; measurement = 5 + (rand()%11); /* value from 5 to 15 */ tsErrChkMsgPopup (TS_PropertySetValNumber (testData->seqContextCVI, &errorInfo, "Step.Result.Numeric",


5-110

ni.com


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 selectingBuild»Configuration»Debug. 20. Create the DLL by selecting Build»Create Debuggable Dynamic Link Library. If LabWindows/CVI says access is denied to overwrite the

©


5-111



DLL, you need to selectFile»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 theSequence 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. 23. The Video Diagnostics step should execute only if theVideo Test step fails and the Powerup Test and CPU Test steps have passed. Double-click on theVideo Diagnostics step. 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 Insert AllOf. f. Click Video Test.


5-112

ni.com


g. Click Insert Step Fail.

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.


©


5-113



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

To return numeric data and a st ring from a code mod ule 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 theC:\Solutions\TestStand I\CVI Project Files\ directory.


5-114

ni.com


©


5-115



3. Click OK to close the Edit DLL Call dialog box. 4. In LabWindows/CVI open the project file C:\Exercises\TestStand I\CVI Project Files\Ex 5-4C 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 theTestStand API 2.0 instrument driver. If you do not, loadTSAPICVI.fp from the C:\TestStand\API\CVI\ directory by selectingInstrument»Load.

7. In the TestStand API instrument driver, go to the Property Object»Values tree and select Set Numeric Value.


5-116

ni.com


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 Error Info Lookup String Options New String Value

seqContextCVI &errorInfo "Step.Result.Numeric" 0 10 + (rand()%11)

5-117



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 theSequence 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.

•

NewNumeric 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 Error Info Lookup String Options New String Value

seqContextCVI &errorInfo "Step.Result.ReportText" 0 "Unstable VSS readings at video controller"

5-118

ni.com


14. Return to the VideoD_API.c file and be sure that you filled in the function calls as shown. Note The code shown is for illustration only, besure to use proper syntaxin your code. 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 clickOK to close the Edit DLL Call dialog box. ClickOK 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 theTS_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.

©


5-119



Note All properties and variables could be referenced with similar lookupstrings.

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 labelError:. Enter the macro as shown in bold below. Make sure that the code appears exactly as shown below. Note The code shown is for illustration only, besure to use proper syntaxin your code. #include "stdtst.h" #include "tsutil.h" void __declspec(dllexport) __stdcall VideoDiagnostics_API(CAObjHandle seqContextCVI, short *errorOccurred, long *errorCode, char errorMsg[1024]) { int ErrMsg ERRORINFO


error = 0; errMsg = {'\0'}; errorInfo;

5-120

ni.com


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. indows/CVI please refer tothe Note For more information on type libraries for LabW 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. 21. Confirm the DLL target settings by selectingBuild»Target Settings. Make certain the settings match those in the figure below.

©


5-121



Click Type Library and check the box next toAdd 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. ClickOK 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 theVideo Diagnostics step, then select Specify Module. From the function ring select VideoDiagnostics_API. Select No if you get the following window:


5-122

ni.com


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. 26. The Video Diagnostics step should execute only if theVideo Test step fails and the Powerup Test and the CPU Test steps have passed. Double-click theVideo Diagnostics step. 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.

©


5-123



c. Click CPU Test. d. Click Insert Step Pass again. e. When prompted to insert AllOf or AnyOf, choose Insert AllOf. f. Click Video Test. g. Click Insert Step Fail.

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.

End of Exercise 5-4C


5-124

ni.com


Exercise 5-5A Creating a Simple Test Using the LabVIEW Standard Prototype Adapter Objective:

To write a simp le Numeric Limit Test that uses th e LabVIEW St andard Pr ototype 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 Plot Title

DBL String

Numeric Control (Input) 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

©


5-125



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.



5-126

ni.com


Exercise 5-5B Creating A Simple Test Using The C/CVI Standard Prototype Adapter Objective:

To write a si mple 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 theC/CVI Standard Prototype Adapter. Functions to use: SinePattern, YGraphPopup, ACDCEstimator

For SinePattern use the following parameters: Parameter

Value

Number of Elements Amplitude Phase Number of cycles Sine Pattern

1024 1.0 0.0 4 sine (Declare this in CVI.)

Save the sequence as Ex 5-5B Simple CVI Numeric Limit Test.seq.


©


5-127



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 stepSineACEstimator, which you created in the previous exercise. Add anotherNumeric 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 theSequence Context ActiveX Pointer checkbox as shown below:


5-128

ni.com


VIs to use: TestStand - Get Property Value (Number).vi TestStand - Get Property Value (String).vi

Both functions are available in theTestStand palette. Save the VI. Save the sequence file.


©


5-129



Exercise 5-6B Passing Parameters from TestStand to LabWindows/CVI using The TestStand API Objective:

To learn how t o use the TestStand API to pa ss data bet ween 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 asEx 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 stepSineACEstimator, which you created in the previous exercise. Add anotherNumeric 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 itSineACEstimator_API. This function will be a modification of theSineACEstimator 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.


5-130

ni.com


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


©


5-131



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 informati on) 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 theCalculate Graph step to alter the parameters for the sine wave generation. Notes An alternative option toalter the parameters for the sinewave generation would be to use the Pre Expression of the succeeding step. This method behaves similarly, but avoids the overhead of adding extraStatement 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 inmemory when you pass it as a structure parameter. In this exercise, this custom data type and all


5-132

ni.com


of its settings have already been set for you. For more information on TestStand types, please refer to theTestStand User Manual.

End of Exercise 5-7

©


5-133



Notes


5-134

ni.com

Lesson 6 User Management

Lesson 6: User Management In this lesson, you will learn how to: • Add users tothe 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.

©


6-1


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 selectView»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 theusers.ini file in the \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.


6-2

ni.com

Lesson 6

User Management

Default User Profiles Privilege Profile

Operator

Operate Debug Develop

Configure Users

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.

©


6-3


Lesson 6

User Management

Exercise 6-1 Objective: To set user login access and privileges ni the user manager and create a new profile



6-4

ni.com

Lesson 6

User Management

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 T estStand User Manager for TestStand-specific data and privileges to be associated with the user.

©


6-5


Lesson 6

User Management

Lesson 6 Summary: User Management • Create multiple users with differe nt capabilities • Create a variety of profiles usin g different combinations of privileges • Limit modification of information in the User Manager to users with the configure.editUsers privilege • ConfigureTestStandto 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 fileStationGlobals.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.


6-6

ni.com

Lesson 6 User Management Exercises

Exercise 6-1 Setting User Login Access and Privileges Objective:

To become fam iliar with the user manager for adding and con figuring 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 login at any time. ClickOK to continue. 2. Click on the User Manager button in the toolbar or selectView»User Manager. This brings up the User Manager window, as shown below.

©


6-7


Lesson 6

User Management Exercises

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 theOK 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.


6-8

ni.com


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 chooseProperties. When a value for a user is changed, the change affects only that specific user. Note On the tree branches, noticea 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.

©


6-9


Lesson 6


7. Log in again in the Sequence Editor by selecting File»Login at any time. Notice that in the pull-down ring control for theLogin 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 yb 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. TheProfiles tab contains the list of all currently defined profiles. As mentioned in Part A, TestStand has four + Operator default profiles. Click theto sign next the to the andoperators then click the + sign next to Privileges examine privileges that have by default. The following screen should appear.


6-10

ni.com


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 doesnot 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 chooseInsert 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.

©


6-11


Lesson 6


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 thePrivileges»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. ClickOK 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. ClickOK to return to the user manager. The resulting screen should resemble the following image.


6-12

ni.com


7. Click the User List tab again to create a new user. WithUser List selected in the left pane, right-click in the right pane and selectInsert 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.

©


6-13


Lesson 6


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 newprivilege properties. Refer to the User Management chapter in theTestStand User Manual for more information.



6-14

ni.com


Notes

©


6-15


Lesson 6


Notes


6-16

ni.com

Lesson 7 Result Collection and Report Generation

Lesson 7: Result Collection and Report Generation In this lesson, you will learn about: • What, When, and Where of result collection • Generating reports from collected results • Report generation featuresin 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 learnwhich 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.

©


7-1


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.ResultListis an initially empty array of containers

When and Where Results are Stored TestStand automatically collects the results of each step. Each sequence has ResultList a 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 theResult 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 theRun Options tab in the Step Properties dialog box. You can control result collection for an entire sequence by going tothe Edit»Sequence Properties dialog. You can enable/disable result recording for all sequences on a station level from theExecution tab in the Configure»Station Options dialog.


7-2

ni.com

Lesson 7


What Results are Stored Sequence Step 0

Step.Result Step.TS Step.*

Step 1

Step.Result Step.TS Step.*

Locals.ResultL ist (array) Step Result [0] (container) Step Result [1] (container)

Step n-1 Step.Result Step.TS Step.*

Step Result [n-1] (container)

* Indicates other it ems may be present depending on step type

What Results are Stored Step.Result In TestStand, each step type can have a different set of subproperties under its property. Therefore, the Step Result varies according to the step type. TestStand can append step results that containResult properties from different step types to the sameResultList array. When TestStand copies the Result property for a step to itsStep 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 Step Result as properties to each step result. TestStand adds standard result properties to the subproperties of the TS property. These standard result properties include the Start Time, oTtal Time, Module Time, Index, Step Name, Step Group, ID, Interactive Execution Number, and Step Type.

©


7-3


Lesson 7


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 somecollected 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 theirst f step in the sequence and so on. Notice that within each ResultList container you see sev eral 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.


7-4

ni.com

Lesson 7


Subsequence Results • Locals.ResultList[x].TS.S equenceCall • The ResultList of the subse quence 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 storethe result of the sequence. The subproperty name willvary 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 orTS.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.

©


7-5


Lesson 7


Formatting Results into a Report Process Model

Report Header (Reportgen_xxx.seq)

Test UUTs/Single Pass

Report Body Test Report Callback

ResultList[0]

Test Report Sequence

(ModelSupport.dll)

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 andthe 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 theConfigure»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 theResultList parameter.


7-6

ni.com

Lesson 7


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 selectingConfigure»Report Options as shown on the next slide.

©


7-7


Lesson 7


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 methodto 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.


7-8

ni.com

Lesson 7


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 thereport 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 pathna me. You can also select a base report name to be used in every report file pathname that is genera ted, as well as specify whether to force each ifle 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.

©


7-9


Lesson 7


Inserting Message in Report

Inserting Message in Report Each default step type has aReportText 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.


7-10

ni.com

Lesson 7


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 selectingConfigure»External Viewers to specify the application that TestStand launches to display the report. View»Launch Report You can then use the external application to view reports by selecting the Viewer command when an Execution window is active.

©


7-11


Lesson 7


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



7-12

ni.com

Lesson 7


Lesson 7 Summary Result Collection and Report Generation • 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 stephas 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 thestep 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 tobe returned to the process model (srcinal 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 formatsall 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.

©


7-13


Lesson 7

Result Collection and Report Generation Exercises

Exercise 7-1 Customizing Report Generation Objective:

To demonstr ate the built -in options for customi zing repor t generati on 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.


7-14

ni.com

Lesson 7


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 thereport, 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.

©


7-15


Lesson 7


Click OK to close this dialog. 3. Click the Report File Pathname tab. You will see the following dialog box.


7-16

ni.com

Lesson 7


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 theDirectory 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 theBase 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

©


7-17


Lesson 7


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.


7-18

ni.com

Lesson 7


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 UU T Serial Number to UUT Repor t 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 filesare 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.

©


7-19


Lesson 7


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. ClickOK 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 theReport File Pathname tab. You will see the following dialog box.


7-20

ni.com

Lesson 7


When you use the Batch process model, theReport 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

©


7-21


Lesson 7


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


7-22

ni.com

Lesson 7


Notes

©


7-23


Lesson 7


Notes


7-24

ni.com

Lesson 8 Database Interaction

Lesson 8: Database Interaction In this lesson, you will learn about: • 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.

©


8-1


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.


8-2

ni.com

Lesson 8


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 SQLcommands, 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.

©


8-3


Lesson 8


Database InterfaceTechnologies • 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.


8-4

ni.com

Lesson 8


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.

©


8-5


Lesson 8


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.


8-6

ni.com

Lesson 8


Configuring Database Options 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 ca n 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 theBuild 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 "FILE Expression will contain the file path and name of the file, for example, NAME=C:\\Program Files\\Common Files\\System\\OLE DB\\Data Links\\Access.UDL"

©


8-7


Lesson 8


Configuring Database Options Configure»Database Options»Sche mas

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. TheStatements 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.


8-8

ni.com

Lesson 8


Configuring Database Options Configure»Database Options»Statements

Configuring Database Options: Statements Statements tab in the Define the statements associated with the previously selected schema 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

©


8-9


Lesson 8


Configuring Database Options Configure»Database Options»Colum ns/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.


8-10

ni.com

Lesson 8


Logging Property • Contains n i formation 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 Logging in the sequence When the database logger starts, it creates a temporary property named context in which it evaluates expressions. TheLogging property contains sub-properties that provide information about database settings, process model data structures, and the results that the Logging to refer to logger processes. As logging progresses, the logger updates sub-properties of 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 theTestStand User Manual .

©


8-11


Lesson 8


Default Schema: Generic Recordset • UUT_RESULTS: Overall UUT test results • STEP_RESULTS: Overall test step results • STEP_: Step type specific results • MEAS_IVI_: 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 also allows the database logger to record TestStand User step results that contain a varying number of results. similar It measurements. See the Manual for a list of the names, data types, and descriptions of each column in the tables mentioned above.


8-12

ni.com

Lesson 8


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 theTestStand\Components\NI\Model\ TestStandModel\Database directory.

©


8-13


Lesson 8


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 theVIEW button on the Data Link tab in the Edit Database Logging Options dialog box or from theTools»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 includeView 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 theClear 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.


8-14

ni.com

Lesson 8


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


©


8-15


Lesson 8


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


8-16

ni.com

Lesson 8


Database Step Types Database Step Types

Database Actions

5 Built-in

5 Basic

Step Type • Open Database

Action Connect to a database

• Open SQL Statement • Data Operation Statement • Close SQL Statement • Close Database

Select data within a database table Performoperationson selecteddata Close references to the table 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

©


8-17


Lesson 8


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 anOpen SQL Statement step. The Data Link dialog box is very similar to the previously discuss ed Data Link tab that is available when you select Configure»Database Options. The only difference is theDatabase Handle control, which is used to specify the name of a variable or property of typeNumber to which you assign the returned value of the database handle. The Open Database step type has the propertyStep.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.


8-18

ni.com

Lesson 8


Open SQL Statement Step Type

Open SQL Statement Step Type After you open a database, use theOpen SQL Statement step type to select a set of data in the database with which to work. Using the SQL command SELECT in theSQL 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. •

St atement 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.

©


8-19


Lesson 8


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. •

D ata 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 theTable ring control with the tables that the selected data link defines. When you select a table in theTable control, TestStand populates theColumn 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 theColumn control.

•

You can use the Add button to insert the selected table and column into theTable and Column list control. You can remove an item from the list control using theRemove 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 thatTestStand evaluates at run-time. This is used to search the database for a specific entry or entries.


8-20

ni.com

Lesson 8


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 typeNumber 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 theRecord Index control. The Record Index control contains a literal numeric value or a numeric expression that TestStand evaluates at run-time.


8-21


Lesson 8


Data Operation Step Type (Continued)

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 aPut command (see Put below). –

Get—Gets the values from the selected record. TheColumn 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 moreSet 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. •

C olumn List Source —Specifies the name of the variable or property that contain s the column values the step gets or sets. The named property must be an array of type DatabaseColumnValue.


8-22

ni.com

Lesson 8



Data Operation Step Type (Continued) The Column Values tab applies only toGet , 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 aGet 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. TheColumn 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 theTestStand 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.

©


8-23


Lesson 8



Data Operation Step Type (Continued) • Column Values —Specifies the mappings of column names to variables or properties that the step uses. The list control contains the specified mappings. TheColumn 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 aGet operation, the Value control must contain the name of a variable or property. When the Data Operation step performs Put a 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 theTestStand User Manual for a list of format strings.


8-24

ni.com

Lesson 8


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 typeNumeric 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 typeNumber that contains the SQL statement handle to close. Note TestStand does not automatically close SQL statement handles. Y ou 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.

©


8-25


Lesson 8


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 typeNumber 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. Y ou 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.


8-26

ni.com

Lesson 8


Exercise 8-2 Objective: To create a Microsoft Access database session using built-in TestStand database step types Approximate time to complete: 30 minutes

©


8-27


Lesson 8


Summary: Database Step Types There are five basics actions in a database session, and there are five corresponding built-in database step types. StepType

Action

•Open Database •Open SQL Statement

Connect to a database Select data within a database table

•Data OperationStatement

Performoperationson selecteddata

•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


8-28

ni.com

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 Paneland double-click on the ODBC icon. The ODBC Data Source Administrator dialog box appears as shown.

©


8-29


Lesson 8


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.


8-30

ni.com

Lesson 8


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.

©


8-31


Lesson 8


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.


8-32

ni.com

Lesson 8


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.

©


8-33


Lesson 8


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.


8-34

ni.com

Lesson 8


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

©


8-35


Lesson 8


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.


8-36

ni.com

Lesson 8


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. TheExecute 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.

©


8-37


Lesson 8


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 theExecute 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-38

ni.com

Lesson 8


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 UUT during an execution a last sequence file, the connection to one the database remains open untilofthe UUT test is complete.

©


8-39


Lesson 8


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 to viewer can display data in the database you must File »Nespecify w Data a data link your database. Tothe specify a data link select 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-40

ni.com

Lesson 8


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

©


8-41


Lesson 8


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 NumberOfFailUUTs

Numeric Numeric

SerialNumber

String

ListOfSerialNumbers

String

8-42

ni.com

Lesson 8


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.

©


8-43


Lesson 8


6. Insert an Open SQL Statement database step below the previously Open Statement addedStatement step. Name the step . Edit the Editcontrol Open SQL dialog for this stepSQL so that the Databa se Handle contains the expressionLocals.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’”.


8-44

ni.com

Lesson 8


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.

©


8-45


Lesson 8


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.


8-46

ni.com

Lesson 8


11. Next you need to modify the contents of the Column Values tab. TestStand Access should the specified DataStatement Link Name . Select the only statement in the ring be control for the SQL value. From the Column Name/Number ring control, select UUT_SERIAL_NUMBER. For theValue 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.

©


8-47


Lesson 8


12. Double-click on the Data Operation step to display the Data Operations Properties Select the Loop Options tab. From the Loop Type ring control,dialog. 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


8-48

ni.com

Lesson 8


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.

©


8-49


Lesson 8


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


8-50

ni.com

Lesson 8


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 the expression Locals.StatementHandle OK control . Click to closecontains 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.

©


8-51


Lesson 8


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


8-52

ni.com

Lesson 8


Notes

©


8-53


Lesson 8


Notes


8-54

ni.com

Lesson 9 The Operator Interface

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.

©


9-1


Lesson 9

The Operator Interface

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 • through This separation the: is achieved in TestStand – 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

The Operator Interface 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.


9-2

ni.com


Available Operator Interfaces • Four Operator Interfaces arencluded i 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.

©


9-3


Lesson 9


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.


9-4

ni.com


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 theTest 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.

©


9-5


Lesson 9


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.


9-6

ni.com


How the Operator Interface Works

UIMessages Operator Interface

TestStand Engine

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.

©


9-7


Lesson 9


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.


9-8

ni.com


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


©


9-9


Lesson 9


Lesson 9 Summary: The Operator Interface • 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 TestStan operator interfa are shipped withdsource code in ces LabVIEW, LabWindows/CVI, Visual Basic, and Delphi • Operator Interface utilizesUIMessages 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.


9-10

ni.com

Lesson 9

The Operator Interface Exercises

Exercise 9-1 Running Tests from the Operator Interface Objective:

To learn how t o run a sequenc e 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 theOK 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

\Examples\Demo\C\computer.seq.

©


9-11


Lesson 9


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. SelectC/CVI Standard Prototype Adapter and click on the Configure button.


9-12

ni.com

Lesson 9


4. The figure below shows the LabWindows/CVI Standard Adapter Configuration window. Click theExecute Steps In External Instance of CVI radio button. Click theOK button to return to the Adapter Configuration window. When prompted, clickOK 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 selectingConfigure»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.

©


9-13


Lesson 9


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. •

En able Tracing —Turns tracing in the execution display on and off. You can also enable or disable tracing into specific callbacks.

•

nteract I ive 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.


9-14

ni.com

Lesson 9


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 10 seconds, prompt for action When terminating, time limit of 5 seconds, prompt for action When aborting, time limit of 5 seconds, prompt for action

©


9-15


Lesson 9


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\Components\ NI\Models\TestStandModels\SequentialModel.seq.


9-16

ni.com

Lesson 9


User Manager Options

In this tab, you can set the user configuration options for TestStand. For this exercise, select theCheck User Privileges box to enable the user privilege checking. Also, check theUse Default box in the User Manager File section. The default file should be c:\TestStand\Cfg\Users.ini.

The Automatically Loginlogin Windows System User option logs in users Note automatically with the network 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.

©


9-17


Lesson 9


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 theTestStand 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.


9-18

ni.com

Lesson 9


6. The operator interface window includes an option for customizing the items that appear in theTools menu. Click on Tools»Customize.

In the Customize Tool Menu window, click theAdd button to add an option to the Tools menu.

There are four Item Types: Command: Sequence File:

©


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

9-19


Lesson 9


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 ofInaPart Sequence in the Operator Interface 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. TheTest UUTs button causes the sequence to run continually, while theSingle 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 theSingle 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 inConfigure»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.


9-20

ni.com

Lesson 9


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 opti on 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-21


Lesson 9


9. Choose Debug»Step Over to proceed to the Register test. 10. Choose Debug»Resume to continue execution of the Register Test.



9-22

ni.com

Lesson 9


Notes

©


9-23


Lesson 9


Notes


9-24

ni.com

Lesson 10 Additional Topics

Lesson 10: Additional Topics In this lesson, you will learn how to: • 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.

©


10-1


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 theImport/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.


10-2

ni.com

Lesson 10

Additional Topics

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 Spec ifies Step Propert y for Each Colum n —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 theAppend 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.

©


10-3


Lesson 10

Additional Topics

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.


10-4

ni.com

Lesson 10

Additional Topics

Exercise 10-1 Objective: To use a file or database to edit the properties and variables of a sequence


©


10-5


Lesson 10

Additional Topics

Exercise 10-2 Objective: To use theProperty Loader step to dynamically import properties and variables from a file or database Approximate time to complete: 5 minutes


10-6

ni.com

Lesson 10

Additional Topics

Exercise 10-3 Objective: To use the Property Loader step type to import different values based on evaluating expressions Approximate time to complete: 15 minutes

©


10-7


Lesson 10

Additional Topics

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.


10-8

ni.com

Lesson 10

Additional Topics

Distributing TestStand How to distribute TestStand • Create a TestStand Run-Time engine installation • Distribute the Operator Interface • Distribute sequences and code modules UUT

UUT

UUT

Development 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

©


10-9


Lesson 10

Additional Topics

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 uncompresse s 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 Tools»Run wizard for creating the TestStand Run-Time engine installation. The menu option 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.


10-10

ni.com

Lesson 10

Additional Topics

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 Inter face, the engine cannot view or run the sequence. To distribute your operator interface, build tiinto 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 fromyour test sequences andyou 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 theApp 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.

©


10-11


Lesson 10

Additional Topics

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 codepaths module files paths – Absolute vs. Relative – Search Directories

• Assemble VIs for Run-Time Distributiontool • 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 theTestStand User Manual .


10-12

ni.com

Lesson 10

Additional Topics Exercises

Exercise 10-1 Importing and Exporti ng 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 adapter from the adapter selector ring. The adapter is for creating a step in a TestStand not callasany external code. Otherwise, steps sequence behave inthat thedoes same way 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 selectingInsert Step»Tests»Numeric Limit Test. Name the step Resistor 1 Test. 3. Because this step is using the 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 thePost 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. ClickOK to return to the sequence display window. 4. Copy the new step by either selecting it and pressing , or by right-clicking on it and choosingCopy. Paste four copies of the step by pressing four times or right-clicking in the window and selecting Paste. Name the steps so that they readResistor 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 selectingInsert 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.

©


10-13


Lesson 10 Additional Topics Exercises

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 C:\Exercises\TestStand Location ring control. Specify the path 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.


10-14

ni.com

Lesson 10


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

©


10-15



properties you are interested in from this list. To select all of thestep limit properties, simply click on theLimits > 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 theExport 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.


10-16

ni.com

Lesson 10


12. This message indicates that you have successfully exported the selected properties to the fileC:\Exercises\TestStand I\Limits.txt. Close the message by selecting theOK 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.

©


10-17



14. Now that you have edited the selected properties, you need to import them back into the sequence. Launch theImport/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 theDone 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


10-18

ni.com

Lesson 10


Exercise 10-2 Using the Pr operty Loade r Step Type Objective:

To use the Proper ty Loader st ep type to impo rt a proper ties 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 theI\Ex sequence C:\Exercises\TestStand 10-1fileResistor 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 theMainSequence. 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 toload and from whatdata location. Notice the similarity in the configuration tabs between theEdit Property Loader dialog and the Import/Export Properties dialog from the previous exercise. From within theProperties tab, select File from the Data Location control. Insert Step.PropertiesList the to Properties Listring Source > button control value. Select the Limits for 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.

©


10-19



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.


10-20

ni.com

Lesson 10


5. Click OK to store your changes and close theEdit 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.

©


10-21



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 theLoad 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 underRunState»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.


10-22

ni.com

Lesson 10


8. Remove the breakpoint that you set on the Load Properties step in step 7 of this exercise before continuing to the next exercise.


©


10-23



Exercise 10-3 Using the Exp ressions to Load Propert ies 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 ofproperty 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 asLimits1.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.


10-24

ni.com

Lesson 10


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 theSetup 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, clickOK to return to the sequence display.

©


10-25



6. Right-click on the Load Properties step and select Edit Property Loader from the popup menu. Select theSource 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 nameLimitsx.txt, where x corresponds to the button selected by the operator. Note The x value is obtained from theResult.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.


10-26

ni.com

Lesson 10


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 selectingExecute»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.


©


10-27



Notes


10-28

ni.com

Appendix A Introduction to Interchangeable Virtual Instruments

Appendix A: Introductionto 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 k ey 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.

©


A-1


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.


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) s ie itl i b a p a C r e v i r D

Base Capabilities (Required): 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.

©


A-3


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.


A-4

ni.com

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.

©


A-5


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 attributemodel

IVI Driver IVI drivers have a number of similarities with traditional drivers. Like traditional drivers, an plug&play compliant. IVI driver must be present for each instrument. They are also VXI 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 beforethey 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


A-6

ni.com

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 ofa standard attribute model, state-caching, range-checking, error query,and multithreading. This section discusses eachof 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 shownabove 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 forthese 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.

©


A-7


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.


A-8

ni.com

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.

©


A-9


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.


A-10

ni.com

Standardization • IVI class specification sets guidelines for internal structure and program matic 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 foundationwww.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.

©


A-11


Instrument Classes • Define a standard API for programming instruments – e.g., all scopes are programmed the same way

• Allow for the developm ent of hardwareindependent 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 thatare commonly supported bythe 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).


A-12

ni.com

IVI Class Specification Scope Example

Fundamental Capabilities Extensions Initialize Configure Vertical Configure Horizontal ReadWaveform

Runt Width Video Trigger Trigger Trigger 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 arecommonly supported bythe majority of instruments ina class (for example, range setting for a DMM, or probe attenuation for a scope) are considered Fundamental Capabilities. This defines the basic functionality thatcan 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 aspart of the fundamental capabilities. Different oscilloscopes supportdifferent triggering mechanismsand 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.

©


A-13


IVI Driver Standard Easy-to-use Functions - Configure, Read etc.

VXIplug&playDriver

Required Utility Functions: - Initialize - Reset - Self-Test - Error-Query - Error Message - Revision-Query - Close

Application Functions Required Functions

Code

IVI

VISA

How should you develop the code? How should you structure the code? How should the code execute?

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.


A-14

ni.com

Where Does IVI Fit In? • Instruments classified by type

Test Program

– Can develop non classcompliant drivers

IVI Class Driver

IVI Specific Driver

IVI Specific Driver

• Two-tiered architecture: – Instrument-specific drivers performance improvements

– Generic class drivers

I/O Library (VISA or other)

interchangeability

• Builds on VISA or other standard I/O library

Hardware

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 isin 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.

©


A-15


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 siteni.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)


A-16

ni.com

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.

©


A-17


Types of IVI drivers Class Driver IviDmm_Init IviDmm_Configure IviDmm_Trigger IviDmm_Read...

Test Program

IviDmm

Specific Driver fl45_Init fl45_Configure fl45_Trigger fl45_Read… fl45_special... Specific Driver hp34401A_Init hp34401A _Configure hp34401A _Trigger hp34401A _Read… hp34401A_special...

fl45 hp34401A

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.


A-18

ni.com

Interchangeable Drivers

• Swap instruments under generic class drivers – No source code change or recompilation

• Five classes defined

Test Program (LabWindows/CVI, LabVIEW, VB, etc.)

DMM Class Driver

– Scope – DMM – Arb or function generator – Switch

Fluke 45 2001 NIKeithley 4050 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.

©


A-19


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.


A-20

ni.com

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. •

VirtualInstruments —The combination of the physical instrument, the instrument driver, and option settings. You can swap instruments without changing your program yb 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.


A-21


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.


A-22

ni.com

Logical Names • Used by class driver Initialize functions • Associated with a specific instrument

Logical Names When you ca ll a class driver Initialize function, you pass a logical name alias rather than a resource descriptor to identify the particular virtual instrument touse. Logical names are usedby the class drivers to isolate the test code from the specific instruments in use and point to the specific instruments that are being usedvia 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 ora 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.

©


A-23


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.


A-24

ni.com

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.

©


A-25


Device Configuration

• Configure the physical instrument to communicateto: – 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 theIVI Driver Library User Manual .


A-26

ni.com

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 anInitialize 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.

©


A-27


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 asCH1) each driver uses. You should use virtual channel names whenever you want to develop hardware-independent test programs.


A-28

ni.com

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.

©


A-29


IVI Foundation Update • Current classes:

• Future classes:

– Multimeter (DMM)

– RF signal generator

– Oscilloscope

– Spectrum analyzer

– Switch

– Power meter

– Arbitrary waveform/

– Digital instruments

function generator – DC power supply

– AC power supplies

• 50 companies

• C and COM-based 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.


A-30

ni.com

Instrument Driver Network (IDNet)

• More than 100 instrument specific IVI drivers available forFREE • 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 atni.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 atni.com/ivi to: •

Get information on IVI drivers

You can obtain information about IVI atwww.ivifoundation.org to: •

©

Get information on IVI class specifications


A-31


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:


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 ( ___ ) ___________________________________

Education Mail to: Customer National Instruments Corporation 11500 North Mopac Expressway Austin, Texas 78759-3504

Fax to:

Customer Education National Instruments Corporation 512 683 6837

Course Evaluation Course _______________________________________________________________________________________ Location _____________________________________________________________________________________ Instructor _________________________________________

Date ____________________________________

Student Inf ormation (optional) Name ________________________________________________________________________________________ Phone ___________________________________

Company _________________________________________

Instructor Please evaluate the instructor by checking the appropriate circle. Unsatisfactory Poor ❍

Instructor’s ability to communicate course concepts

❍

❍

Instructor’s knowledge of the subject matter

❍

❍

Instructor’s presentation skills

Satisfactory Good

❍ ❍

❍

❍

❍ ❍ ❍

Excellent

❍ ❍ ❍

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? The course length was

❍

❍

Too long

Yes ❍

❍

No

Just right

The detail of topics covered in the course was

❍

❍

Too short ❍

Too much

The course material was clear and easy to follow.

❍

Yes

❍

❍

Yes

❍

No

Did the course cover material as advertised?

I had the skills or knowledge I needed to attend this course.

❍

Just right

No

Yes

❍

❍

❍

Not enough

Sometimes

No

Ifno,howcou ldyouhav e beenbet ter

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? ❍

Mailing

❍

Co-worker

❍

❍

National Instruments web site

❍

National Instruments Sales Representative

Other _____________________________________________________________

Test Stand

Recommend Documents