Академический Документы
Профессиональный Документы
Культура Документы
le
mp
Course Software Version 2012
May 2013 Edition
Part Number 325704J-01
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
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
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
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
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.
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
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.
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.
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.
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
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
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.
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
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
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.
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.
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.
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
If you use the DLL option for generating the report body, modify the C_report.c source file and
rebuild modelsupport2.dll.
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.
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
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.
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.
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
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
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
Notes
le
mp
Sa
4-24 | ni.com