Вы находитесь на странице: 1из 30

NI TestStand 2: Framework

Development Course Manual

le
mp
Course Software Version 2012
May 2013 Edition
Part Number 325704J-01

TestStand 2 Course Manual


Sa
Copyright
20012013 National Instruments. All rights reserved.
Under the copyright laws, this publication may not be reproduced or transmitted in any form, electronic or mechanical, including
photocopying, recording, storing in an information retrieval system, or translating, in whole or in part, without the prior written
consent of National Instruments Corporation.
National Instruments respects the intellectual property of others, and we ask our users to do the same. NI software is protected by
copyright and other intellectual property laws. Where NI software may be used to reproduce software or other materials belonging
to others, you may use NI software only to reproduce materials that you may reproduce in accordance with the terms of any
applicable license or other legal restriction.
End-User License Agreements and Third-Party Legal Notices
You can find end-user license agreements (EULAs) and third-party legal notices in the following locations:
Notices are located in the <National Instruments>\_Legal Information and <National Instruments>
directories.
EULAs are located in the <National Instruments>\Shared\MDF\Legal\License directory.
Review <National Instruments>\_Legal Information.txt for more information on including legal information
in installers built with NI products.
Trademarks
Refer to the NI Trademarks and Logo Guidelines at ni.com/trademarks for more information on National Instruments
trademarks.
ARM, Keil, and Vision are trademarks or registered of ARM Ltd or its subsidiaries.
LEGO, the LEGO logo, WEDO, and MINDSTORMS are trademarks of the LEGO Group. 2013 The LEGO Group.
TETRIX by Pitsco is a trademark of Pitsco, Inc.2013
FIELDBUS FOUNDATION and FOUNDATION are trademarks of the Fieldbus Foundation.
EtherCAT is a registered trademark of and licensed by Beckhoff Automation GmbH.
CANopen is a registered Community Trademark of CAN in Automation e.V.
DeviceNet and EtherNet/IP are trademarks of ODVA.

le
Go!, SensorDAQ, and Vernier are registered trademarks of Vernier Software & Technology. Vernier Software & Technology and
vernier.com are trademarks or trade dress.
Xilinx is the registered trademark of Xilinx, Inc.
Taptite and Trilobular are registered trademarks of Research Engineering & Manufacturing Inc.
FireWire is the registered trademark of Apple Inc.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Handle Graphics, MATLAB, Real-Time Workshop, Simulink, Stateflow, and xPC TargetBox are registered trademarks, and
TargetBox and Target Language Compiler are trademarks of The MathWorks, Inc.
Tektronix, Tek, and Tektronix, Enabling Technology are registered trademarks of Tektronix, Inc.
The Bluetooth word mark is a registered trademark owned by the Bluetooth SIG, Inc.
mp
The ExpressCard word mark and logos are owned by PCMCIA and any use of such marks by National Instruments is under license.
The mark LabWindows is used under a license from Microsoft Corporation. Windows is a registered trademark of Microsoft
Corporation in the United States and other countries.
Other product and company names mentioned herein are trademarks or trade names of their respective companies.
Members of the National Instruments Alliance Partner Program are business entities independent from National Instruments and
have no agency, partnership, or joint-venture relationship with National Instruments.
Patents
For patents covering National Instruments products/technology, refer to the appropriate location: HelpPatents in your software,
the patents.txt file on your media, or the National Instruments Patent Notice at ni.com/patents.
Sa
le
mp
Sa

Worldwide Technical Support and Product Information


ni.com
Worldwide Offices
Visit ni.com/niglobal to access the branch office Web sites, which provide up-to-date contact information, support phone
numbers, email addresses, and current events.
National Instruments Corporate Headquarters
11500 North Mopac Expressway Austin, Texas 78759-3504 USA Tel: 512 683 0100
To comment on National Instruments documentation, refer to the National Instruments Web site at ni.com/info and enter the
Info Code feedback.
Sa
mp
le
Contents

Student Guide
A. NI Certification .....................................................................................................vii
B. Course Description ...............................................................................................vii
C. What You Need to Get Started .............................................................................viii
D. Installing the Course Software..............................................................................viii
E. TestStand Directories............................................................................................ix

le
F. Course Goals.........................................................................................................ix

Lesson 1
Test Frameworks
A. Purpose of the Test Framework ............................................................................1-2
B. Components of a Framework................................................................................1-3
C. Framework Requirements.....................................................................................1-4
mp
Lesson 2
TestStand API
A.
B.
C.
D.
Introduction to the TestStand API ........................................................................2-2
TestStand API Organization .................................................................................2-3
Calling the TestStand API ....................................................................................2-13
Common TestStand API Uses ..............................................................................2-20

Lesson 3
Custom Steps
A. Custom Step Types ...............................................................................................3-2
B. Step Templates......................................................................................................3-17

Lesson 4
Process Models
Sa
A. Process Model Structure .......................................................................................4-2
B. Customizing a Process Model...............................................................................4-5
C. Common Process Model Modifications ...............................................................4-6
D. Creating Custom Result Processing Plug-ins .......................................................4-16

Lesson 5
User Interfaces
A. Available User Interfaces......................................................................................5-2
B. TestStand User Interface (UI) Controls ................................................................5-4
C. User Interface Messages (UIMessages)................................................................5-10
D. Front-End Callbacks .............................................................................................5-12

National Instruments | v
Contents

Lesson 6
Design Considerations
A. Modularity ............................................................................................................6-2
B. Choosing Where To Implement Functions ...........................................................6-2
C. Data Management .................................................................................................6-5
D. Error Handling ......................................................................................................6-6
E. XML Style Sheets .................................................................................................6-8
F. Framework Deployment .......................................................................................6-11

le
Appendix A
Customizing Database Interaction
A. Relational Databases.............................................................................................A-2
B. Structured Query Language ..................................................................................A-3
C. Customizing Database Interaction ........................................................................A-4
D. Modifying Schemas ..............................................................................................A-4
E.
mp Database Step Types .............................................................................................A-9

Appendix B
Additional Information and Resources
Sa

vi | ni.com
Process Models
4
In this lesson, you learn about the TestStand process model. You learn how to customize and
modify common process models. You also, learn how to create custom result-processing plug-ins.

le
Topics
A. Process Model Structure
B. Customizing a Process Model
C. Common Process Model Modifications
D. Creating Custom Result Processing Plug-ins
mp
Sa

National Instruments | 4-1


Lesson 4 Process Models

A. Process Model Structure


Usually, the test system must perform a series of operations before and after the test system
executes the sequence that performs the tests. Common operations include operator prompts, user
interface updates, report generation, and database logging. The process model in TestStand
controls the set of such operations, how tests are configured, and the flow of execution.

Although the TestStand Engine handles the actual creation and execution of thread objects and
execution of steps, the process model controls the additional operations that occur during an

le
execution. When you call an entry point, you execute a sequence in the process model.

The process model is a special type of sequence file. Most custom process models are based on the
built-in TestStand process models, as shown in Figure 4-1. The sequences within a process model
include more options than sequences in a normal sequence file. Using the Advanced tab of the
Sequence File Properties dialog box to change any sequence file to a process model.
Figure 4-1. Process Model Structure in TestStand
mp
The process model interacts with the client sequence files and code modules through the TestStand
API. A modular test architecture organizes operations common to many or all tests inside the
process model. Isolating common operations can make the test system easier to maintain because
Sa
you can make changes only to the process model instead of to each test the system contains.

4-2 | ni.com
TestStand 2 Course Manual

Sequence Types
A normal sequence file can include callbacks and subsequences. A process model file can also
contain Execution entry points and Configuration entry points. Use the icon colors in the Sequences
pane, shown in Figure 4-2, to differentiate among the sequence types in the process model.
Figure 4-2. Sequence Types

le
1

mp 5

1 Execution Entry Points 4 Subsequences


2 Configuration Entry Points 5 Engine Callbacks
3 Process Model Callbacks

Use the Model tab of the Sequence Properties dialog box to change any sequence in a process
model to a different type.

Entry Points
A process model defines a set of entry points, and each entry point is a sequence in the process
model file that invokes a test sequence file. Defining multiple entry points in a process model gives
the user different ways to invoke a Main sequence or configure the process model. The sequence
for a process model entry point can contain calls to DLLs, subsequences, callbacks, Goto steps, and
so on. You can specify two types of entry pointsExecution entry points and Configuration entry
points.
Sa
Execution entry points are the main sequences in a process model. Each execution entry point
represents one way to execute the test system. For each client sequence file that uses the process
model, TestStand adds an item to the Execute menu for each Execution entry point in the process
model file. For example, the Test UUTs Execution entry point in the Sequential process model
prompts users for a serial number, performs a test, and prompts users to test additional UUTs or
display the report. In contrast, the Single Pass Execution entry point executes the test once without
prompting for a serial number, and displays the report.

Creating a complete custom Execution entry point is a large and complex task. Copying an existing
Execution entry point and modifying the entry point can be more convenient and efficient.

Use Configuration entry points to set configuration options for the process model. For example,
select ConfigureResult Processing in the Sequential process model to configure how the process

National Instruments | 4-3


Lesson 4 Process Models

model stores data and generates and displays test reports. Each Configuration entry point adds an
item to the Configure menu.

A configuration entry point executes a sequence and can perform any type of operation. Most
configuration entry points launch a dialog box in which you can configure some aspect of the
process model. The Configuration entry point stores the configuration so that steps in the
Execution entry points can use the configuration. You can use the following two common
techniques for storing the configuration of a process model:
Create station global variablesStation global variables are easy to create and retain their

le
values between executions and test sessions. However, any sequence can access station global
variables, which allows little protection for the configuration data.
Store the configuration data in a fileThe built-in TestStand process models store
configuration data in configuration (.ini) files from their configuration entry points, and load
the data from steps in each Execution entry point.

To practice the concepts in this section, complete Exercise 4-1.


mp
Subsequences
Process models can contain normal subsequences, that entry points or callbacks can call.
Subsequences in a process model are no different than subsequences in a normal sequence file. The
client sequence file cannot override these subsequences.

Process Model Callbacks


Process Model callbacks work differently in the process model than in a normal sequence file. The
process model can set sequences as callbacks you can be override. Client sequence files can use
callback sequences to override sections of an entry point.

Complete the following steps to create and use a Process Model callback.
Sa
1. Create a new sequence.
2. Use the Sequence File Properties dialog box to change the sequence to a callback.
3. Call the sequence from a Sequence Call step in one or more entry points.

You can add default steps to the callback for TestStand to execute if the client sequence file does
not override the callback. Use the sequence settings of the callback sequence to determine if
TestStand copies these default steps into the client sequence file when it overrides a callback.

Engine Callbacks
Process models can also override Engine callbacks. Engine callbacks in the process model work
similarly to Engine callbacks in a client sequence file. An Engine callback defines an action to take
when certain pre-defined events occur in the engine. The only difference is that process models
have two versions of most Engine callbacksa sequence file version and a process model version.

4-4 | ni.com
TestStand 2 Course Manual

Sequence file Engine callbacks, such as SequenceFilePostStep or SequenceFileLoad shown in


Figure 4-3, are active for the actual process model sequence file. Therefore, the
SequenceFilePostStep callback executes after each step in a process model sequence. A step in the
client sequence file does not trigger the callback. The SequenceFileLoad callback for a process
model executes each time the process model loads into memory.
Figure 4-3. Engine Callbacks

le
mp
Process model Engine callbacks define Engine callbacks for the client sequence file. Therefore, the
ProcessModelPostStep callback executes after each step in the client sequence file or any sequence
the client sequence file calls. If the client sequence file overrides the SequenceFilePostStep
callback directly, both callbacks execute after a step in the client sequence.

Station callbacks, defined in the StationCallbacks.seq file in the <TestStand>\


Components\NI\Callbacks\Station directory, apply to any sequence that runs on the
station. If you override the StationPostStep sequence in the StationCallbacks.seq file, the
ProcessModelPostStep sequence in the process model, and the SequenceFilePostStep sequence in
a client file, all three callbacks execute after each step in the client file.

B. Customizing a Process Model


Sa
The built-in TestStand process models provide much of the functionality that makes TestStand
valuable. Writing a custom process model completely from scratch might be counterproductive.
Instead, you can copy one of the built-in process models and modify the copy to create a custom
process model.

Some common modifications for a custom process model include creating custom configuration
and Execution entry points or additional callbacks for client sequence files to override. When you
customize an entry point, include the customization in a callback instead of using a subsequence
or inserting steps directly into the entry point so client sequence files can use a callback to override
the customization if necessary.

National Instruments | 4-5


Lesson 4 Process Models

C. Common Process Model Modifications

Prompting Mechanisms
One role of a test system is to guide the operator through the testing process. You can get
information from or display information for the operator by using the user interface, pop-up dialog
boxes, or prompts. Refer to Lesson 5, User Interfaces, for more information about user interfaces
and how you can update them from the process model.

le
Use prompts instead of the user interface to acquire or display critical information because prompts
launch no matter the interface in which the sequence executes, which can make debugging easier
because you can effectively run the sequence in the sequence editor.

Consider using prompts when you need the operator to enter important information, such as a serial
number or test type. Prompts function better than the user interface for this purpose because the
test automatically pauses and waits for a response from the operator, and because prompts do not
require synchronization with a user interface control.
mp
Use prompts when the operator must manually alter the UUT or test equipment, such as connecting
the UUT to a different instrument or connecting a new UUT. You can also use prompts to notify
the operator to manipulate the UUT, such as powering on the UUT, pressing buttons, or other
interactions.

You can also use prompts to display only important information to the operator, such as
notifications of critical errors or the overall status of the UUT. Use the user interface to display
other types of information on the user interface. Avoid overusing prompts to display information
because users must click each prompt to clear it, which might significantly increase test time.

For each prompt, determine whether the prompt is specific to one type of UUT or if it applies to a
category of UUTs. For example, in cell phone testing, prompts to navigate the menu and enable a
particular feature are most likely specific to a single type of cell phone. However, prompts to power
on the cell phone or press the 9 button can apply to all cell phones. Include UUT-specific prompts
in the client sequence file. Include general prompts in a custom process model.
Sa
To include a prompt in the process model, define a callback and add the callback to an Execution
entry point. Using a callback is a better choice than adding the prompt directly to the entry point
or using a subsequence because client sequence files can use a callback to override the default
prompt in case a particular UUT is an exception to the rule. Considering the cell phone example, a
specific model of cell phone might power on automatically when you connect the cell phone to the
test equipment. In this case, the client sequence for that cell phone model must override the
callback for the power on prompt to leave the callback blank.

To practice the concepts in this section, complete Exercise 4-2.

4-6 | ni.com
TestStand 2 Course Manual

Result Collection
The process model stores execution data in local variables as the process model executes, including
the configuration settings for the report and database, the ResultList, and information about the test
station, such as the operators name. You can pass many of these variables as parameters to
callbacks and subsequences. You can also customize the process model to modify the data or add
additional items. You can perform modifications statically by directly editing the local variables or
dynamically by calling the TestStand API.

le
The recommended way to modify process model variables is to pass the variables into a callback
as parameters and then modify the values in the callback so client sequence files can override the
settings with custom behavior.

By default, TestStand collects the results of certain step properties in memory and generates a
report, as shown in Figure 4-4.
Figure 4-4. Result Collection Process
mp
Sa
Creation of the report in TestStand involves the following two steps:
Result CollectionThe report can contain only what TestStand collects in memory during the
execution of the sequence. By default, TestStand collects all subproperties of the
Step.Result container into the Locals.ResultList array. You must explicitly add to the
result collection any extra results you want. You must modify report generation to include the
new data or content in the report.
Report GenerationModifying the content and appearance of the report involves changing
result collection and report generation. TestStand generates a report from the contents of the
ResultList in memory. You can change the appearance of all report formats by modifying the
sequences or DLLs that generate the report. You can also change the appearance of XML and

National Instruments | 4-7


Lesson 4 Process Models

ATML reports by modifying the style sheets they use. Refer to Lesson 6, Design
Considerations, of this course for more information about XML and ATML reports and style
sheets.

TestStand automatically collects the results of each step. Each sequence includes a ResultList local
variable, as shown in Figure 4-5, that is an initially empty array of containers. TestStand appends
a new container property called the Step Result to the end of the ResultList array before a step
executes. After the step executes, TestStand automatically copies the contents of the Result
subproperty for the step (Step.Result) into the appropriate step result container of the ResultList

le
array.
Figure 4-5. Result Collection

mp
Use the following techniques to control the scope of result collection:
Use the Run Options tab of the Step Properties dialog box to control the result collection option
for each step.
Use the Sequence Properties dialog box to control result collection for an entire sequence.
Use the Execution tab of the Station Options dialog box to enable or disable result collection
for all sequences on a station level.
Sa

4-8 | ni.com
TestStand 2 Course Manual

ResultList
Each step type can include a different set of subproperties under its Step.Result property.
Therefore, the step result varies according to the step type. TestStand can append step results that
contain Result properties from different step types to the same ResultList array. When
TestStand copies the Result property for a step to the Step Result container, TestStand adds the
step name and position in the sequence, as shown in Figure 4-6.
Figure 4-6. Creating the ResultList Array

le
mp
Standard TestStand Step Type Properties
In addition to copying step type-dependent step properties, TestStand adds a set of standard
properties to each step. These standard result properties include StartTime, TotalTime,
ModuleTime, Index, StepName, StepGroup, StepID, and StepType, as shown in Figure 4-7. You
can obtain useful information about the step by accessing the TS property in the ResultList
array.
Figure 4-7. TS Properties Include Standard TestStand Properties
Sa

National Instruments | 4-9


Lesson 4 Process Models

Subsequence ResultList
When a step calls a subsequence or generates a call to a callback sequence, TestStand creates a
special step result subproperty to store the result of the subsequence, shown in Figure 4-8, unless
the callback or sequence disables results.
Figure 4-8. Storing the Result of a Subsequence

le
mp
The subproperty name varies depending on the type of step that called the subsequence or
generated a call to a callback sequence. For example, TS.SequenceCall is the subproperty name
for a Sequence Call step type, and TS.PostAction is the subproperty name for a Post Action
callback.

TestStand adds the following properties to the subproperty it creates for each subsequence called:
SequenceFileAbsolute path of the sequence file that contains the subsequence.
SequenceName of the subsequence the step called.
StatusStatus of the subsequence the step called.
Sa
ResultListValue of Locals.ResultList for the subsequence the step called. This
property contains the results for the steps in the subsequence.

The ResultList property of a subsequence is also stored in the ResultList entry for the Sequence
Call step that called the subsequence.

Modifying Result Collection


Use the following techniques to change the contents of the Locals.ResultList property:
Use additional results to include extra information from any step.
Use a custom step type to add additional properties to the Step.Result container.
Use the Execution.AddExtraResult method of the TestStand API.
Use TestStand API to directly insert subproperties into the Step.Result container

4-10 | ni.com
TestStand 2 Course Manual

Additional Results
You can use the Additional Results built-in step type when you want to log data outside the context
of one particular step in the sequence. The Additional Results step specifies values to add to the
result list of a step. An additional result is a value TestStand adds to the result list of a step when
the step executes. An additional result can be a module parameter or a custom additional result in
which you specify the name and value of the result. You can configure TestStand to automatically
include additional results in reports and when logging results to a database. Use the Additional
Results edit tab, shown in Figure 4-9, in the TestStand Sequence Editor and the Additional Results

le
dialog box in a TestStand User Interface to add and configure additional results.
Figure 4-9. Additional Result Built-in Step Type

mp
You can also use the Additional Results panel on the Properties tab of any step to add and configure
additional results, as shown in Figure 4-10. Additional Results are values TestStand adds to the
result list of a step when the step executes. An additional result can be a module parameter or a
custom additional result in which you specify the name and value of the result. You can configure
TestStand to automatically include additional results in reports and when logging results to a
database. The default TestStand report generation sequences and XML style sheets do not display
additional results for skipped steps.
Figure 4-10. Additional Results on Properties Tab of a Step
Sa

National Instruments | 4-11


Lesson 4 Process Models

Custom Step Types


Because TestStand copies each property in the Step.Result container to the ResultList, one
way to add items to the results is to create a custom step type and place data items in the result
container of the custom step type. You can populate the data items using expressions or parameters
from code modules or substeps. Placing data items directly in the Step.Result container is a
good solution for data items you always want to include in the results but is a poor choice for data
items you include in the results based on a configuration setting.

le
Specifying Additional Step Properties Using AddExtraResult
Call the Execution.AddExtraResult method to specify an additional step property for
TestStand to copy from the step Result property to the ResultList after the execution of each
step. If a step does not include the property you specify, TestStand does not add that property to the
ResultList. You can call the method repeatedly to add any number of extra results. Other useful
methods are Execution.DeleteExtraResult and Execution.ClearExtraResultList.

You can place the additional properties you want to include in result collection in a custom step outside
the Step.Result container and then call the Execution.AddExtraResult method from an
mp
Execution entry point in the process model. You can place a precondition on the Execution.
AddExtraResult method to specify whether to include the properties in the report for the execution.

Recall that extra results can also be collected from the Properties tab in the step settings. You can
also use the Additional Results panel on the Properties tab of the Step Settings pane to log extra
parameters.

You must select the appropriate options in the Configuration entry points for report generation and
database logging to include limits and comparison types. The built-in process models include the
limits and operator outside the Step.Result container. Add these data items to report generation
and database logging by using the Execution.AddExtraResult method from a Setup Result
Settings sequence that the built-in entry points call, as shown in Figure 4-11. Preconditions on the
AddExtraResult steps cause the steps to execute only when you include limits or operators in the
report or database.
Sa

4-12 | ni.com
TestStand 2 Course Manual

Figure 4-11. Specifying Data Logging Limitations in a Setup Result Sequence

le
Insert Subproperties
The Step.Result container and the Locals.ResultList array are PropertyObjects.
mp
Therefore, you can use the TestStand API to directly modify the containers. Use the
PropertyObject.InsertSubProperty method to copy existing properties into the
ResultList. Use the series of SetVal methods, such as PropertyObject.SetValString,
to create new custom items with the InsertIfMissing option.

You can add or modify items directly in the Step.Result container by using a custom step
substep that calls the TestStand API. You can also use the TestStand API from a code module or
process model to directly insert properties into the ResultList. Take this approach if you want
to copy a local variable into the results of a step without using additional results.

Report Generation
Modifying the result collection is one part of generating a custom report. However, you must also
modify the report generation settings or routines to change the report. Use the following methods
to modify the report:
Sa
Report OptionsSet the report format and location and the items to include in the report.
Refer to the NI TestStand 1: Test Development Course Manual for more information about
report options.
Add items to the reportAdd items to the report by formatting the item into a string and
storing the string in the Step.Result.ReportText property. You can also include a
property in the ResultList and set the IncludeInReport flag on that property.
Modify the report generation routinesModify some or all the report by overriding the
report generation callbacks in the process model. You can also open the source code TestStand
uses to create the report and modify the code directly.

National Instruments | 4-13


Lesson 4 Process Models

Adding Items to the Report


Common items to add to a report include message strings and report flags such as IncludeInReport,
IsMeasurementValue, and IsLimit.

Adding Message Strings To Reports


Each default step type includes a ReportText subproperty that contains a message string that
TestStand includes in the report by default when the string includes text, as shown in pink in
Figure 4-12. TestStand automatically detects when you add text to Step.Result.ReportText.

le
Figure 4-12. Viewing Reports

mp
You must format the data for the ReportText property only as text. Additionally, each step
includes only one ReportText property, so you must limit the property to one data item or
carefully format data items within the string to avoid confusion.

Setting Report Flags


Sa
TestStand uses the IncludeInReport, IsMeasurementValue, and IsLimit flags to identify result
properties to include in the report.

TestStand step types enable the IncludeInReport flag on a subset of the step result properties to
specify that these properties automatically appear in the report. TestStand step types also enable
the IsMeasurementValue and IsLimit flags on the properties that hold output values or limit values.
The report generator uses these flags to selectively exclude limits or output values according to the
option you select in the Report Options dialog box. If an array or container property enables one
of these flags, the report generator considers the flag enabled for all array elements or subproperties
within the containing object.

You can set these flags manually or programmatically. Complete the following steps to manually
set the flags of a step property:

4-14 | ni.com
TestStand 2 Course Manual

1. Right-click the property in the step type definition and select Properties.
2. Click Advanced in the Step Properties dialog box.
3. Set the flags using the Edit Flags dialog box.

You call the PropertyObject.SetFlags method on the property for which you want to set
flags programmatically.

Modifying Report Generation Routines

le
Overriding Report Callbacks
You can override the following report callbacks, as shown in Figure 4-13, from within a client
sequence file:
ReportOptionsOverride the ReportOptions callback in the client sequence file to modify
the report options after TestStand reads the test station report options from disk. The
ReportOptions callback is initially empty in the default process model.
TestReportGenerates the contents of the test report for one UUT. Override this callback in
the client sequence file to change or replace the default test report generation behavior.

mp
ModifyReportHeaderOverride the ModifyReportHeader callback in the client sequence
file to modify the header that the TestReport callback generates. The ModifyReportHeader
callback is initially empty in the default process model.
ModifyReportEntryOverride the ModifyReportEntry callback in the client sequence file to
modify the report section that the TestReport callback generates for each result. The
ModifyReportEntry callback is initially empty in the default process model.
ModifyReportFooterOverride the ModifyReportFooter callback in the client sequence file
to modify the footer that the TestReport callback generates. The ModifyReportFooter callback
is initially empty in the default process model.
Figure 4-13. Report Callbacks You Can Override
Sa

National Instruments | 4-15


Lesson 4 Process Models

Report Generation Code


An alternative to overriding the Report callbacks in the client sequence file is to modify the process
model directly. Use this technique if you want the changes to exist in most or all sequence files.

If you use the DLL option for generating the report body, modify the C_report.c source file and
rebuild modelsupport2.dll.

Note If you recompile modelsupport2.dll, you must install the Microsoft


Windows SDK support files from the LabWindows/CVI installation CD, which might be

le
require a custom install or repair of LabWindows/CVI to acquire the necessary files.

If you use the Sequence option for generating the report body, customize the sequence files in
reportgen_txt.seq or reportgen_html.seq.

Note Before making changes to these report generation components, copy the
<TestStand>\Components\Models\TestStandModels directory to the
<TestStand Public>\Components\Models\TestStandModels directory, then
mp
edit the copy of TestStandModel.seq. By default, TestStand searches for the
TestStandModel.seq file in the <TestStand Public>\Components\Models
directory before searching the <TestStand>\Components\Models directory. Select
ConfigureSearch Directories to configure the search directories.

D. Creating Custom Result Processing Plug-ins


You can implement your own custom result processing by creating a new result processing plug-in.
A plug-in is a sequence file which contains specific sequences, known as plug-in entry points,
which are called by the process model at specific times throughout execution. Refer to the Model
Plug-in Entry Points topic in the NI TestStand Help for more information on each plug-in entry
point.

TestStand provides a method to generate a plug-in template which creates the sequences and data
types needed for the plug-in to work with the default process models. By creating a new plug-in,
Sa
you can implement your custom code without needing to make any modifications to the default
process models, preventing you from needing to maintain a custom model. Also, custom plug-ins
integrate seamlessly into the Result Processing window, shown in Figure 4-14, and appear much
like the built-in plug-ins.

4-16 | ni.com
TestStand 2 Course Manual

Figure 4-14. Result Processing Window

le
Plug-in Sequence File Components
Complete the following steps to generate a new plug-in that you can modify.
1. Select ConfigureResult Processing to launch the Result Processing dialog box.
mp
2. Enable the Show More Options option and click the Advanced button to launch the Advanced
Result Processing Settings dialog box.
3. Click the Create New Process Model Plug-in button.
4. Use a unique filename that includes your company name as a prefix for the plug-in, such as
Acme_ReportGenerator.seq.
5. Click Save to create and load the new plug-in sequence file.
6. TestStand creates and adds the following new data types to the file. The data types are empty
containers in which you can add plug-in-specific properties.
<plug-in name>Options
<plug-in name>AdditionalOptions
<plug-in name>RuntimeVariables
Sa
<plug-in name>PerSocketRuntimeVariables

Refer to the Creating Process Model Plug-ins topic in the NI TestStand Help for a more detailed
tutorial on creating a new model plug-in sequence.

To add an instance of the new plug-in to a result processing configuration, complete the steps
below. The process model uses this result processing configuration at run time to determine the
plug-ins to invoke.
1. Select ConfigureResult Processing to launch the Result Processing dialog box.
2. Click the Add button and select the plug-in name from the drop-down list.

National Instruments | 4-17


Lesson 4 Process Models

Plug-in Entry PointsConfiguration


Plug-in sequence files can contain two plug-in entry points, as shown in Figure 4-15, for displaying
configuration dialogs, Model Plugin - Configure Standard Options and Model Plugin -
Configure Additional Options. In your plug-in, you can define one or both of these entry point
sequences to allow users to configure the properties of the plug-in. In most cases, you will only
need to use the Configure Standard Options sequence to modify options. Use the Configure
Additional Options sequence when you create a new plug-in by extending an existing plug-in and
you want to provide a small number of additional options for the new plug-in.

le
Figure 4-15. Plug-in Configuration Entry Points

1
mp
Standard Options 2
1 2

Additional Options

Refer to the Model Plug-in Entry Points topic in the NI TestStand Help for more information on
each plug-in entry point.

Plug-in Entry PointsExecution


Throughout execution, the process model calls plug-in entry points in each enabled plug-in
instance at specific times during execution. For example, the Model Plugin Pre UUT plug-in
entry point is called immediately following the PreUUT callback. Therefore, any code in this
Sa
plug-in entry point sequence is executed directly after the serial number dialog is displayed. If you
are not using a particular entry point, you can delete it from the plug-in. If you later want to add
the plug-in entry point back to the plug-in, you must copy it from the generated template or from
an existing plug-in.

To gain a better understanding of where each plug-in entry point is called, inspect the process
model execution entry points (Single Pass or Test UUTs), and note the sequence calls which begin
with the text Model Plug-ins. Also, refer to the Model Plug-in Entry Points topic in the
NI TestStand Help for more information on each plug-in entry point.

By default, each plug-in entry point contains a number of parameters which contain information
about the current state of the execution and configuration information. These parameters are
automatically populated when the plug-in entry point is called by the process model.

4-18 | ni.com
TestStand 2 Course Manual

Plug-inProperties
Each plug-in has a number of configuration properties stored in the ModelPlugin container. This
container is accessible to all plug-in entry points as a parameter. Properties that are shared by all
plug-ins, such as the Enabled or NewThread property are contained in the ModelPlugin.Base
container.

Properties unique to the plug-in are contained in the ModelPlugin.PluginSpecific container. This
container is defined by custom data types that are generated with the plug in:

le
<plug-in name>Options
<plug-in name>AdditionalOptions

When creating a custom plug-in, configuration properties should be added to these containers as
needed. The plug-in entry points for configuration (such as Model Plugin - Configure Standard
Options) can be used to expose these properties to the user. Property values for custom plug-ins are
automatically stored in a configuration file along with settings for the built-in result processing
plug-ins.mp
Custom Plug-in Examples
TestStand includes two example plug-ins to help with development of custom plug-ins. The simple
text report example is a simplified version of the built-in report generator, allowing you to more
easily understand how a function plug-in is built. The source code used by the plug in is provided
in LabVIEW, LabWindows/CVI, and .NET. The basic step time report example shows how model
plug-ins can be used to gather other information as well, such as test performance. This example
generates an excel spreadsheet with trend information on step execution times. This information
can be useful in identifying steps that may be impacting test throughput.

For each example, a sequence is provided to install the plug-in to the correct directory. Once
installed, the example plug-ins will appear in the result processing dialog.
Sa

National Instruments | 4-19


Sa
mp
le
TestStand 2 Course Manual

Self-Review: Quiz
1. Client sequence files can override normal sequences defined in the process model.
a. True
b. False

le
2. Configuration entry points for the built-in process models store information in
a. File global variables
b. Station global variables
c. Parameters that are passed into Execution entry points
d. Configuration files on disk
mp
3. If you override the ProcessModelPostStep Engine callback in a process model and the
SequenceFilePostStep Engine callback in a client sequence file, what happens after a step in
the client sequence file executes?
a. TestStand executes only the callback from the process model
b. TestStand executes only the callback from the sequence file
c. TestStand executes both callbacks

4. Which of the following techniques can you use to change the contents of the
Locals.ResultList property?
a. Use additional results to include extra information from any step
Sa
b. Use a custom step type to add additional properties to the Step.Results container
c. Use the Execution.AddExtraResult method
d. Directly insert subproperties into the Step.Result container using the TestStand API

National Instruments | 4-21


Sa
mp
le
TestStand 2 Course Manual

Self-Review: Quiz Answers


1. Client sequence files can override normal sequences defined in the process model.
a. True
b. False

le
2. Configuration entry points for the built-in process models store information in
a. File global variables
b. Station global variables
c. Parameters that are passed into Execution entry points
d. Configuration files on disk
mp
3. If you override the ProcessModelPostStep Engine callback in a process model and the
SequenceFilePostStep Engine callback in a client sequence file, what happens after a step in
the client sequence file executes?
a. TestStand executes only the callback from the process model
b. TestStand executes only the callback from the sequence file
c. TestStand executes both callbacks

4. Which of the following techniques can you use to change the contents of the
Locals.ResultList property?
a. Use additional results to include extra information from any step
Sa
b. Use a custom step type to add additional properties to the Step.Results container
c. Use the Execution.AddExtraResult method
d. Directly insert subproperties into the Step.Result container using the TestStand
API

National Instruments | 4-23


Lesson 4 Process Models

Notes

le
mp
Sa

4-24 | ni.com

Вам также может понравиться