Community Documents
I work on the NI VeriStand R&D team. As you may know, NI VeriStand 2011 just launched. In this post I'm going to talk about some of the exciting new stimulus profile features available in 2011. We invested a lot of time prior to the 2011 release engaging with users and researching what types of problems users were trying to solve with our legacy stimulus profile system. This effort involved direct feedback from users and gathering example test scripts to search for common requirements.
Analyzing the Legacy Stimulus Profile System
Our analysis of theses issues resulted in the following list of limitations in the current system:
Limited portability of profiles between systems
If you designed a stimulus profile for one system, it might be difficult to reuse it on another similar system. The generators had hardcoded mappings that could not be changed without editing the profile.
No way to parameterize profiles
Often users want to run the same profile multiple times with different parameters. For instance, the duration to run a test might change, or the maximum high limit threshold to check might need to be adjusted.
Only one profile can run at a time
There was no way to run multiple profiles at the same time. Many users are creating test rigs that are capable of servicing multiple UUTs at the same time. Only having one profile active at time limited their testing efficiency.
Limited Pass/Fail support
The only way to have a profile return a meaningful pass/fail result was to have an analysis generator in the system check for expected values. For basic step-type profiles, there was no way to indicate any pass/fail result.
No way to create subroutines
Often users had a profile section that they might want to call in multiple places. For instance, you might want to have a profile that sets up correct initial values in the environment that you want to call before each main profile.
Limited timing configuration
Only one step of a profile could be executed in a given time step. This helped ensure determinism, but it made it impossible to perform compound operations in one timestep. For instance, if a user wanted to check if X < Y AND X > Z, that would take two timesteps to process.
Lack of basic programming structures, variables and functions
There were no for loops, while loops, if statements, local variables, etc. Users had to store data in User Channels from the system definition due to a lack of local variables, and use Conditional steps to carefully mimic standard looping and branching operations. Also, the profile did not support custom calculations beyond +,-,* or /. Boolean and trigonometric operations were not supported.
No Stop/Abort actions
Users often wanted to invoke some special shutdown code if a profile was stopped prematurely. For instance, you might want to reset all your digital lines at the end of a profile, even if the profile is stopped by a user.
Limited API support
There was no configuration API to programmatically script stimulus profiles. This is very useful if a user wants to create a custom front-end application for their operators to interact with.
Editing environment restricted to VeriStand
The only way to edit stimulus profiles was to launch VeriStand and invoke the Stimulus Profile Editor from the Workspace or Project Explorer. Users wanted to be able to author test scripts without launching all of VeriStand.
Can't log data without running a profile
Since data logging was configured in a stimulus profile, there was no easy way to log data without running a stimulus profile. Often users would create a dummy profile that just had a long Dwell step in it just so that logging would run in the meantime.
Looking at this list, we decided that it would not be feasible to build on top of the current system to add the necessary functionality while maintaining the necessary level of backwards compatibility. We made the decision to create a new stimulus profile system that would address these issues, while leaving the existing stimulus profile system in place and renaming it the Legacy Stimulus Profile editor.
The New Stimulus Profile System
The first main difference between the old system and the new system is that we have split the profile into two components called the Stimulus Profile and the Real-Time Sequence. The real-time sequence defines the deterministic logic that runs in the VeriStand Engine, while the stimulus profile is the non-deterministic host-side test sequencer that controls which real-time sequences to run, how to map those real-time sequences to system definition channels, as well as other host-side routines such as controlling data logging, running macro files, and interacting with the VeriStand application environment. Both document types are created using the new Stimulus Profile Editor application. This is a new top-level, configuration-based application that ships with NI VeriStand that can be used to create and execute stimulus profiles and real-time sequences. Users create these documents by dragging and dropping elements from a dynamic palette into a document tree and then configuring the properties of the element in a separate Property Browser pane.
Real-Time Sequences
The real-time sequence generally consists of a set of sequential steps to be executed. These steps consist of looping and branching structures, such as a While Loop, For Loop, If/Else and Switch statement, as well as formulaic expressions that allow the user to perform custom calculations. These formulaic expressions can contain arbitrary compound operations, and include support for a full library of boolean operations (AND, OR, etc.), bitwise operations, arithmetic operations, trigonometric functions, exponential functions, as well as support for special built-in functions and custom user-defined functions.
Let's look at the contents of a real-time sequence that plays back a sine wave according to its specified parameters:
The example above shows two main step types used in a real-time sequence, the Expression and the While Loop. The expression statement represents a formulaic calculation. Many of the operations it can perform are self-explanatory. Note that these operations can be arbitrarily complex. Order of operations in compound operations is preserved through the use of parentheses. You will also see the use of some supported built-in functions like sin, which computes the sine of a given value. You will also note the use of other special built-in functions like seqtime, which returns the relative time in seconds since the virtual machine started executing the top-level sequence. The While Loop can be used to repeat a certain set of steps while a given condition is true. This condition is also represented in the form of an expression, and can therefore include compound Boolean and arithmetic operations.
The example sequence above does not directly map to any system definition channels. Instead it just defines a set of parameter variables that serve as the interface for the real-time sequence. How you map pass in parameter values depends on how you call the real-time sequence. Real-time sequences can be called top-level or they can be called as subsequences from other real-time sequences. If you call the real-time sequence from a stimulus profile, then you define in the stimulus profile what the parameter values are for the sequence. Those values can be specified as a system definition channel mappings or as constant value assignments. For instance, you might map the SinewaveOut parameter to an analog output channel in your system, and you might specify that the Amplitude parameter gets value 10.0. You can also call a real-time sequence as a subsequence from another real-time sequence. You call a subsequence directly from an expression statement by invoking using standard function syntax. In this case you specify the parameters as standard functional arguments. For instance, you could call the sequence above with the following expression: SineWave(Var1, 10.0, 1.0, 0.0, 0.0, 60.0). This would map the variable Var1 to the SinewaveOut parameter, and would therefore play the sine wave pattern onto this variable. Also here you see that the value 10.0 was mapped to the Amplitude parameter. The References pane shown above maps subsequences to function names used in expressions.
Real-time sequences having parameters allows users to port them between test rigs, because the user can map the parameters to different channels for each test rig. It also allows users to create reusable libraries of sequences to be called as subsequences to provide custom calculations. Real-time sequences contain optional return variables, which allow their result to be used as part of a calculation. For instance, a user might create the following sequence:
They could then call this sequence as part of a calculation in the following expression: Var2 = Sum(10, 20).
