A continuing problem facing the test industry is the complexity of software in building and configuring automated test systems. A key factor in this complexity is the inability to easily interchange instrument components without reprogramming the system at some level. This proliferates many incompatible automated test system configurations with inherent development and support costs.
Today’s general-purpose computer user is accustomed to functional component interchangeability. The expectation is to be able to get a new component such as a printer, connect it up, install a new driver, and use it with minimal impact, if any, on existing applications.
The test industry has recognized this need, and several industry groups are working to resolve some of the underlying issues. The SCPI Consortium achieved standardized instrument command protocols. The VXIplug&play (VPP) Alliance set a goal for instrument interoperability and accomplished it across several standard computer platforms.
A more recent organization, the Interchangeable Virtual Instruments (IVI) Foundation, focuses on instrument interchangeability. Although an infant organization with ongoing development, the foundation has published several instrument class specifications, including one for switch modules. This provided us the impetus for developing an IVI-compliant driver for a product family of switch modules manufactured by Pickering Interfaces.
IVI Driver Design Considerations
The Pickering Interfaces Switch Modules encompass a broad range of variant models. Inherent in the family is a common intelligent control module. Besides supplying basic control functions for the instrument, the control module provides extended diagnostic support and preemptive monitoring of the system wellness.
Each module supports a service mode that reports marginal performing components in advance of their failure. This is analogous to the check-engine light found on most modern automobiles. The light is a trigger for further diagnosis and repair in advance of possible catastrophic failure.
Communications with the switch module are message based. Although this provides a level of standardization, the command strings are not uniform across the product family.
Providing a different driver for each model type creates logistics and maintenance burdens. Because of this, this implementation uses a generalized common driver that is configurable for the different models through a personality file. This way, adding new models or making current model changes only requires the personality file to be modified, while the driver code remains unchanged.
IVI Requirements
IVI is an emerging family of specifications. For this application, a published IVI Switch Class Specification defines the functions and behavior of the switch modules. To be IVI compliant, the driver must implement 16 base IVI functions and the IVI Switch Class Specification functions and attributes.
The combined function tree and requirements are summarized in Figure 1 (below). To reduce the complexity of the table, individual Get/Set/Check Attribute functions are not shown. Also excluded are scanner extensions that are not relevant to this application.
Figure 1. pivx30ivi Function Tree
The IVI Switch Class abstracts instrument control to a signal level. For example, to make a connection, the driver user specifies the two named channels or signals that he or she wishes to connect together as parameters in the IVI-mandated Connect function.
The driver is responsible for determining the signal path and its capability to connect this path and programming the switching hardware to make the specified connection. If the desired connection cannot be made, an error code explaining the cause is returned by the Connect function.
The abstraction of instrument control to signals is the fundamental technology behind instrument interchangeability and transportable application software. Any instrument with an IVI Switch Class-compliant driver will respond to the Connect function and report status in a standard manner. The Connect function in an application program will produce the same response independent of the underlying hardware, making the application code transportable.
IVI Driver Architecture
The base architecture and application program interface (API) requirements for an IVI-compliant driver are determined in IVI and VPP specifications. The native interfaces are C-centric, so a C tool set is a sound choice for the driver implementation. Figure 2 (below) shows the major component modules of the pivx30ivi_32 driver and their relationships.
Figure 2. pivx30ivi_32 Driver Architecture
From a software engineering perspective, this application is ideal for a pure object-oriented implementation. The switch class is a collection of named channels that encapsulate a set of channel properties (attributes). Each switch-module variant has a unique property and behavior set.
Conversely, the IVI and VPP driver interface is standard C-centric. Consequently, a non-object-oriented C-based interface layer is required to make the driver IVI and VPP compliant.
This IVI driver implementation embodies both technologies. One component is an object-oriented module written in C++. This module contains a pivxSW class that incorporates the IVI Switch Class base functions without the instrument-specific prefix mandated by VPP.
Switch-module behavior, programming information, associated channel names, attribute values, and simulation model data for the pivxSW class are derived from an ASCII personality file named pivx.ini. This module is supplied as a dynamic link library (DLL) named pivxIVIx.DLL and has a standard C interface.
Another component of the IVI driver is the pivx30ivi_32.DLL module. This module is the base IVI- and VPP-compliant driver. It supports the required IVI and VPP functions and includes all the prior implementation VPP driver functions for backward compatibility. This module uses the IVI Engine and VISA libraries and associated DLLs.
Operationally, one IVI driver supports all the different switch models with the differentiation supplied by the personality file. When the driver is initialized via pivx30_init (VPP form) or pivx30_InitWithOptions (IVI form), the software interrogates the selected switch-module hardware for the model number. Then the driver uses this information to instantiate and configure a pivxSW switch object per the physical and behavioral properties defined in the personality file for that module.
Subsequent IVI driver function calls are dispatched to the pivxSW object, which qualifies the request and performs state caching, simulation, and error reporting. If the function call ultimately requires instrument programming, an appropriate command string is generated and returned to the base IVI driver by the pivxSW module. The IVI driver then passes this command string to an IVI session that, in turn, routes this instrument command to the instrument via the VISA layer.
One of the requirements of IVI is the capability to operate in the simulation mode where the driver responds to IVI function calls just as if there was actual instrumentation hardware present. Simulation-mode operation involves setting the correct values in the options parameter field of the pivx30_InitWithOptions function.
For simulation, the option parameter must have the Simulate=1 and DriverSetup= fields set. In the simulation mode, the driver relies on the DriverSetup field for the model number for obtaining the appropriate model data from the personality file.
While operating in the simulation mode, instrument settings are maintained by the pivxSW object just as if actual hardware was present. Functions that elicit an instrument response return dummy messages.
Switch-Module Personality File
The design of the personality file is patterned after the Windows INI file format, which contains major section headers, keywords, and data. This allows it to be accessed and processed using standard Windows API calls.
As an ASCII readable file, it can be developed and maintained using any convenient text editor. One personality file serves all the different switch product configurations and is easier to manage than a collection of smaller individual files.
There are four major sections to the switch-module personality file. Each section begins with a header that contains a keyword enclosed in square brackets, such as [IDENTIFICATION].
The body of each section follows the header and consists of one or more data lines. One data item is defined per line containing a keyword and an associated field separated by an equal sign (=). The four sections are defined as:
- Identification—general identification fields such as file format version number and file time stamp.
- Module Index—catalog for the module types in the personality file.
- Module Header—a unique module identification defined and indexed in the module index section. It contains the main body of switch-module characterization and attribute data.
- Attribute Overrides—an optional section that contains individual channel attribute overrides which replace the initial global settings defined in the module section.
Channel Map Coding
The channel map entries in the personality file are the enabling components of this design that make it possible to use one common instrument driver over the switch-module product family. Channel-map data contains an encoded list of the channel or signal names and associated switch behavior. The behavior encoding is accomplished through the punctuation summarized in Figure 3 (below).
Figure 3. Channel Map Coding Chart
| Punctuation Character |
Use |
| : (colon) | Switch contact operator. Channels named on one side of the colon connect to the channels named on the other side when the switch is closed. |
| ^ (up carat) | Exclusive Or logical operator. |
| | (vertical bar) | Or logical operator. |
| & (ampersand) | And logical operator. |
Channel names are any-length, case-sensitive alphanumeric labels. The command string to cause the switch operation is placed within brackets as a subscript to the channel that it affects. The command string is the ASCII string necessary to cause the related switch closure.
Sometimes to make the desired connection, a switch must be opened. This is accomplished by prefixing the command string with a tilde (~) character. A leading d in the command string signifies that this is the default condition for this switch contact.
The operators define the behavior of the switch. For example, the following channel-map data field outlines the possible switch connections of a single-pole single-throw (SPST) switch:
channel_map = Common: NormallyOpen ^ NormallyClosed
The expression specifies that channel labeled Common can connect to channel labeled NormallyOpen or channel labeled NormallyClosed exclusive of each other.
Each channel_map entry defines the channel names, the relationship equation, and commands for causing the switch operation. Other switch contacts in the module require subsequent unique channel_map keywords and equations.
Each unique additional channel_map keyword is constructed by appending an underscore and sequence number suffix. White space can be included in the expression for readability.
Figure 4 (below) illustrates four independent SPST switches. Examining the equation for the first channel map entry shows that Sw1_C can connect to channel Sw1_NC or channel Sw1_NO but not both.
Figure 4. Example Channel Map Entries
| channel_map = Sw1_C:Sw1_NC[d~(@1)]^Sw1_NO[(@1)] |
| channel_map_1 = Sw2_C:Sw2_NC[d~(@2)]^Sw2_NO[(@2)] |
| channel_map_2 = Sw3_C:Sw3_NC[d~(@3)]^Sw3_NO[(@3)] |
| channel_map_3 = Sw4_C:Sw4_NC[d~(@4)]^Sw4_NO[(@4)] |
The command string for channel Sw1_NC [d~(@1)] indicates that the Sw1_C to Sw1_NC channel connection is the default setting (d prefix) and it requires a switch open command (~ prefix) with the associated command string to make this connection path. To transfer the connection from channel Sw1_C to Sw1_NO requires that the command string in the Sw1_NO subscript be sent to the instrument.
The fundamental building block for the switch model is an n-channel multiplex switch with either exclusive or inclusive connections. Matrix switches are modeled by connecting a row multiplexer to a column multiplexer back-to-back.
A switch module can contain many and varied configurations of switch types. Complex switching networks are modeled by connecting the primitive building blocks together. Connectivity between switch components is accomplished by using common signal names.
Constructing multimodule switching networks may require software wires to connect one module channel to another. A software wire is nothing more than a channel-map entry with a single channel on each side of the equation with no command subscript.
Conclusion
Developing a generic switch driver whose configuration and behavior are defined by a personality file avoided the need for a unique driver for each model configuration. Extending IVI driver support for new or derivative switch products is accomplished by adding new model information to the common personality file. The implementation of the SFP in Visual Basic and the isolation of specific model behavior in an ActiveX control further simplify the development and maintenance of the product family driver.
IVI is a natural extension to the VXIplug&play Alliance specifications and provides the added benefit of instrument interchangeability, state caching, and simulated instrument operation in the absence of instrument hardware. IVI also expands the opportunity for the application tool developer. With IVI, a common application tool can service a broader category of IVI-compliant instrumentation. The end users are the prime beneficiaries of IVI because it broadens their choices of software tools and instrumentation.
Switch Module Soft Front Panel
The soft front panel provides interactive graphical control over the instrument. Functionally, the panel is a specialized stand-alone application program that supplies a surrogate front-panel control for the VXI module. It enables you to verify instrument operation without writing any software code.
The soft front panel for the Pickering Interfaces System 30 VXI family of switch modules is organized into one main panel and a collection of subordinate tabbed panels. The main panel provides a container for the subordinate panels that individually control the family of System 30 Switching Cards. The soft front panel was developed using Visual Basic with each model’s variant subordinate panel implemented as an ActiveX control.
When the panel is initiated, it scans all the VXI resources for System 30 VXI Modules. The program then builds a tabbed list of all located Pickering modules that have a VXI slot/logical address assignment.
Next, the panel reads the configuration of the located modules and updates the panel controls. If no System 30 VXI Modules are located, the program automatically reverts to a demo mode.
The design goal was to provide a familiar pictorial operating view of the representative instrument. Figure 5 shows a schematic representation of the Model 30-725 instrument as shown in the product data sheet. Figure 6 is a screen capture of the soft front panel graphic control for this model.
The graphic control is a pictorial representation of the 30-725 Matrix Switch with the contact closures shown in yellow. This control is linked to the hardware in real time. Any switch opens and closures on this graphic control are performed concurrently in the hardware.
The reset state of the 30-725 is all cross points opened and all the associated in/out connections closed. Clicking on a cross point alternately opens and closes that connection along with the appropriate switching of the out connector. Clicking on an opened out connector closes that connection and opens all the cross-point connections in that row or column.
The soft front panel can operate concurrently with other processes controlling the instrumentation. By using the panel monitor feature, instrument operational activity can be viewed or overridden using the normal soft front-panel controls.
About the Authors
Eric Sacher is president and founder of Serendipity Systems. Prior to founding the company, Mr. Sacher held several software, engineering, marketing, and technical management positions, most recently as vice president of marketing at Cirrus Computers and marketing director at GenRad Designs. He is a member of the IEEE and active in industry standardization efforts. Serendipity Systems, P.O. Box 10477, Sedona, AZ 86339, 520-282-6831, e-mail: [email protected].
David Howe joined Pickering Interfaces as a design engineer in 1985 with a background of 10 years experience in the design and deployment of automation electronics, test systems, and instrumentation. Pickering Interfaces Ltd., Stephenson Rd., Clacton-on-Sea, Essex, CO15 4NL, United Kingdom, 011 44 1255 428141, e-mail: [email protected].
Published by EE-Evaluation Engineering
All contents © 2001 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
January 2001