NI TestStand 2: Framework Development Course Manual · interface updates, report generation, and database logging. The process model in TestStand controls the set of such operations,

NI TestStand™ 2: Framework Development Course Manual

Course Software Version 2012May 2013 EditionPart Number 325704J-01

TestStand 2 Course Manual

Copyright

© 2001–2013 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 NoticesYou 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.

Sam

ple

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

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.

PatentsFor patents covering National Instruments products/technology, refer to the appropriate location: Help»Patents in your software, the patents.txt file on your media, or the National Instruments Patent Notice at ni.com/patents.

Sam

ple

Worldwide Technical Support and Product Informationni.com

Worldwide OfficesVisit 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.

Sam

ple

Sam

ple

© National Instruments | v

Contents

Student GuideA. NI Certification .....................................................................................................viiB. Course Description ...............................................................................................viiC. What You Need to Get Started .............................................................................viiiD. Installing the Course Software..............................................................................viiiE. TestStand Directories............................................................................................ixF. Course Goals.........................................................................................................ix

Lesson 1Test Frameworks

A. Purpose of the Test Framework ............................................................................1-2B. Components of a Framework................................................................................1-3C. Framework Requirements.....................................................................................1-4

Lesson 2TestStand API

A. Introduction to the TestStand API ........................................................................2-2B. TestStand API Organization .................................................................................2-3C. Calling the TestStand API ....................................................................................2-13D. Common TestStand API Uses ..............................................................................2-20

Lesson 3Custom Steps

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

Lesson 4Process Models

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

Lesson 5User Interfaces

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

mpl

e

Contents

vi | ni.com

Lesson 6Design Considerations

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

Appendix ACustomizing Database Interaction

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

Appendix BAdditional Information and Resources

Sam

ple

© National Instruments | 4-1

4Process Models

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.

Topics

A. Process Model Structure

B. Customizing a Process Model

C. Common Process Model Modifications

D. Creating Custom Result Processing Plug-ins

Sam

ple

Lesson 4 Process Models

4-2 | ni.com

A. Process Model StructureUsually, 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 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

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 you can make changes only to the process model instead of to each test the system contains.

Sam

ple



Sequence TypesA 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

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

Entry PointsA 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 points—Execution entry points and Configuration entry points.

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 Configure»Result Processing in the Sequential process model to configure how the process

1 Execution Entry Points2 Configuration Entry Points3 Process Model Callbacks

4 Subsequences5 Engine Callbacks

1

4

5

2

3

Sam

ple


4-4 | ni.com

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 variables—Station global variables are easy to create and retain their 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 file—The 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.

SubsequencesProcess 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 CallbacksProcess 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.

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 CallbacksProcess 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 callbacks—a sequence file version and a process model version.

Sam

ple



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

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 ModelThe 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.Sa

mpl

e


4-6 | ni.com

C. Common Process Model Modifications

Prompting MechanismsOne 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.

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.

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.

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

ple



Result CollectionThe 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 operator’s 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.

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

Creation of the report in TestStand involves the following two steps:

• Result Collection—The 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 Generation—Modifying 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

Sam

ple


4-8 | ni.com

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

Figure 4-5. Result Collection

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.

Sam

ple



ResultListEach 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

Standard TestStand Step Type PropertiesIn 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

Sam

ple


4-10 | ni.com

Subsequence ResultListWhen 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

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:

• SequenceFile—Absolute path of the sequence file that contains the subsequence.

• Sequence—Name of the subsequence the step called.

• Status—Status of the subsequence the step called.

• ResultList—Value 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 CollectionUse 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

Sam

ple



Additional ResultsYou 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 dialog box in a TestStand User Interface to add and configure additional results.

Figure 4-9. Additional Result Built-in Step Type

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

Sam

ple


4-12 | ni.com

Custom Step TypesBecause 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.

Specifying Additional Step Properties Using AddExtraResultCall 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 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.

Sam

ple



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

Insert SubpropertiesThe Step.Result container and the Locals.ResultList array are PropertyObjects. 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 GenerationModifying 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:

• Report Options—Set 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 report—Add 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 routines—Modify 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.Sa

mpl

e


4-14 | ni.com

Adding Items to the ReportCommon items to add to a report include message strings and report flags such as IncludeInReport, IsMeasurementValue, and IsLimit.

Adding Message Strings To ReportsEach 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.

Figure 4-12. Viewing Reports

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 FlagsTestStand 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:

Sam

ple



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

Overriding Report CallbacksYou can override the following report callbacks, as shown in Figure 4-13, from within a client sequence file:

• ReportOptions—Override 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.

• TestReport—Generates 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.

• ModifyReportHeader—Override 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.

• ModifyReportEntry—Override 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.

• ModifyReportFooter—Override 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

Sam

ple


4-16 | ni.com

Report Generation CodeAn 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 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 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 Configure»Search Directories to configure the search directories.

D. Creating Custom Result Processing Plug-insYou 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, 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.Sa

mpl

e



Figure 4-14. Result Processing Window

Plug-in Sequence File ComponentsComplete the following steps to generate a new plug-in that you can modify.

1. Select Configure»Result Processing to launch the Result Processing dialog box.

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

• <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 Configure»Result Processing to launch the Result Processing dialog box.

2. Click the Add button and select the plug-in name from the drop-down list.Sam

ple


4-18 | ni.com

Plug-in Entry Points—ConfigurationPlug-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.

Figure 4-15. Plug-in Configuration Entry Points

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 Points—ExecutionThroughout 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 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.

1 Standard Options 2 Additional Options

1 2

Sam

ple



Plug-in—PropertiesEach 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:

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

Custom Plug-in ExamplesTestStand 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.

Sam

ple

Sam

ple



Self-Review: Quiz

1. Client sequence files can override normal sequences defined in the process model.

a. True

b. False

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

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

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 APISam

ple

Sam

ple



Self-Review: Quiz Answers

1. Client sequence files can override normal sequences defined in the process model.

a. True

b. False

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

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

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 Sa

mpl

e


4-24 | ni.com

Notes

Sam

ple

Documents

NI TestStand 2: Framework Development Course Manual · interface updates, report generation, and database logging. The process model in TestStand controls the set of such operations,