The TestStand Engine is an ActiveX/COM automation server that exposes functionality through an API. Microsoft developed the ActiveX application communication standard to provide a method of communication between applications. Widely used in the industry for many years, ActiveX is built on COM technologies. Because TestStand is built on COM, it will continue to work on future versions of Windows operating systems beyond the lifespan of ActiveX.
ActiveX uses a client/server approach. An ActiveX server is an application that exposes specific functionality to clients that follow the ActiveX standard. In addition, ActiveX applications use Object Oriented Programming (OOP).
The ActiveX server architecture allows any programming language capable of invoking ActiveX code, such as LabVIEW, LabWindows™/CVI™, C#, VB .NET, or C++, to interact with the TestStand Engine. When programming with the TestStand API, the implementation depends on the language you use. For example:
- LabVIEW uses Property and Invoke Nodes to make API calls.
- LabWindows/CVI uses an instrument driver wrapper around API calls.
- C# or VB .NET call the API using an interop assembly TestStand provides.
- TestStand itself provides an ActiveX/COM Adapter to access the API, and you can also use expressions to access the API directly.
Regardless of the way you access the API, the resulting behavior is the same in any environment, since the functionality is implemented within the TestStand engine regardless of the interface you use.
The TestStand API defines several classes to represent types of TestStand objects, such as the SequenceFile class or the Execution class. Each of these classes defines properties and methods to access relevant data or perform actions. For example, the SequenceFile class defines the Path property to store the path of the sequence file on disk, and the Save method to save the sequence file.
Refer to the TestStand API reference help topic for a full list of the available classes defined in the TestStand API. Click a particular class to see more information on it, and the properties and methods it defines.
Many classes in TestStand are related through inheritance: where a more specific class can inherit properties or methods from a more generic class. For example, the SequenceFile class is a more specific version of the PropertyObject class. The TestStand API defines an inheritance relationship between these classes to allow objects of a more specific class to have access to the properties and methods of more generic classes.
The SequenceFile class inherits properties and methods from the more generic PropertyObjectFile and PropertyObject classes
Almost all TestStand API classes inherit from the base PropertyObject class, which includes common methods and properties that TestStand objects share. The PropertyObject class defines generic properties, such as Name and Numeric Format, and provides common methods for object management, such as cloning, setting and getting values, creating and deleting objects, or manipulating arrays. Because most TestStand API classes inherit from the PropertyObject class, they can also access these generic properties and methods. For example, you can use the PropertyObject.Clone() method to create a copy of a step, a sequence, or a sequence file object.
Many development environments prevent you from accessing the properties of a parent class directly. Similarly, in TestStand you cannot call the Clone() method directly on a SequenceFile object. However, the TestStand API provides methods to cast an object to access properties and methods of the more generic class. To access properties and methods defined in the PropertyObject class, you can cast the object into its parent class by calling the AsPropertyObject method. For example, to access the Clone() method on a sequence file object, use
Refer to the NI TestStand Help for more information about the API inheritance and the PropertyObject class properties and methods.
Dynamic Properties versus Built-In Properties
TestStand Objects have two distinct types of properties:
- Built in properties (API Properties), which are defined by the class of the object, are present for all objects of a certain class.
- Dynamic Properties (Sub-Properties), which are defined by the object, can differ between objects of the same class.
A step object has Dynamic Properties that can differ based on the step type, and Static properties which are defined by the Step class in the TestStand API
It can be easy to confuse these two distinct types of properties, since you can access both in a TestStand expression using the “.” Operator. However, when you use the API in other programming languages, only built-in properties are available through direct access, such as when using a property node in LabVIEW.
To access Dynamic Properties, you use the PropertyObject API methods, such as GetValString() and GetValNumber(), using a LookupString to specify the name of the Dynamic Property:
In some cases, you can access a property in multiple ways using either dynamic properties or Built-in properties. When using the TestStand API in a code module, using built-in properties is preferable, since these properties can be accessed directly without the need for maintaining lookup strings.
TestStand Object Relationships
TestStand Objects can contain other objects of a different class, referred to as API Containment . For example, a SequenceFile object contains Sequence objects for the sequences defined in the sequence file. Sequence objects, in turn, each contain Step objects.
Objects in the TestStand API often contain other objects of a different class
Understanding the containment relationships between objects is helpful when navigating specific objects. If a parent object contains multiple child objects of a certain class, you must provide either a property name or index to specify the desired child object. For most child objects, you access the contained objects from a parent object using a specific getter method, which accepts the object name or index as a parameter. For example, to access a step within a sequence file, you use:
SequenceFile.getSequenceByName(“MainSequence”).GetStepByName(“RAM Test”, StepGroup_Main)
In addition, child objects can access their parents through the API. Since a child object always can have only one parent, you use a property rather than a getter method to directly access the parent. For example, if you have a SequenceContext object and need to access the parent execution, you could use:
In many cases, built-in properties are provided to access more distant ancestors. For example, you can directly access the execution object from a Sequence Context object:
Navigating through TestStand API Objects
In addition to navigating using containment relationships, many classes provide properties or methods to access other related objects. For example, the Module class provides the Adapter property to access the corresponding adapter which is executing.
You can use the chart provided in the TestStand API Reference help topic to determine how you can access a desired object from the current object. A subset of this chart is shown below.
From the sequenceContext object, you can navigate object relationships to access other objects