Implementing the VISA specification
Introduction
This document discusses the VXI Plug and Play Alliance VISA specification and its implementation for Test & Measurement equipment, and outlines the essential elements of such an implementation.
This Virtual Instrument System Architecture (VISA) specification defined by the VXI Plug-n-Play Alliance is an important step in the direction of plug and play interoperability between test and measurement software, instruments and controllers. The VISA framework standardizes the I/O layer between instrument drivers and controllers and supports GPIB, GPIB-VXI, VXI, MXI, Ethernet TCP/IP and Serial bus controllers and interfaces.
The VISA Specification
The VISA specification, currently at version 2.2, is a moderately complex spec from an implementation point of view. The specification documentation is quite good and covers some recent additions brought forth due to earlier ambiguities. The specification describes an abstraction layer and a set of interface functions, as found in most layered architectures (e.g. the TCP/IP stack).
Figure 1 describes the context for a VISA implementation. The salient features of the specification (in terms of implementation) follow.
Resource Virtualization
VISA virtualizes instruments, interfaces, backplanes, and low-level access to devices. A Resource Manager is defined that handles these resource types. Different transport/bus types are abstracted out.
VISA defines the following mandatory resource types for GPIB and GPIB-VXI:
INSTR (Instrument), INTFC (Interface), MEMACC (for GPIB-VXI).
The optional/recommended resource types are: BACKPLANE and SERVANT
Each resource has attributes, events and operations defined.
VISA Resource Manager
A default resource manager must be implemented, in charge of identifying and registering resources, managing sessions, access control, addressing, and search operations.
Sessions
Resources are accessed through sessions. Sessions are managed by VISA, and carry state information. Multiple sessions may be initiated with the same VISA resource. Both shared and exclusive locking of resources must be supported. Keys to shared locks can be passed across sessions. Nested locking must be allowed, and lock timeouts implemented. Concurrent operations must be safely allowed wherever possible.
The session model hierarchy is as follows. Multiple sessions may be initiated with the default VISA Resource Manager. For each such resource manager session, multiple sessions may be initiated for each type of resource under its control. Resource sessions under one resource manager session are independent of those under another resource manager session.
Search
The implementation must support search and navigation through a resource list of available resources. The technique of regular expressions matching and subsequent attributes evaluation within a logical expression is to be supported as criterion for searching. For regular expressions, syntax and operator precedence are provided by the specification. For logical expressions a BNF grammar defining valid statements has been provided for implementation.
Addressing
14 types of resource strings has been defined for addressing devices on various interfaces. These are for GPIB, VXI, GPIB-VXI, ASRL (Asynchronous Serial) and TCP/IP interfaces. Translations between these and interface-specific formats is a function of the VISA implementation. Routines for parsing these strings to separate out the interface type and number also need to be implemented.
Attributes
Each resource type has defined attributes, that may be read, written or both. These attributes are defined for the generic resource, with extra attributes for specific types of interfaces. The attributes usually map to settings for a resource.
However, some attributes are complex, in the sense that they deal with the behavior of interface functions. Big and little-endian byte ordering, buffer management control like: flush on CRLF, flush at the end of a formatted write, END assertion after a write etc. are some examples.
The specification gives provision for an external configuration utility that may be used to set system level parameters. The same configuration utility may be used to load attribute values into resources, instead of using defaults.
Events
The specification defines a somewhat sophisticated event model, used for asynchronous operations, queuing and call-backs. The event model defines event queues per event type per resource session. Delayed and immediate callbacks into the calling thread's context must be supported. Both queuing and callbacks may be operational simultaneously. Multiple handlers may be defined for the same event, and must be invoked in LIFO order. Handlers are to be invoked with an event context. User-specific parameters can be passed when calling a handler.
Exceptions
Exception handling follows the event model, except that queuing is not performed. Exceptions may nest and may be implemented by applications in constructs like C++ throw/catch. Exception handlers must be invoked in the context of the thread that caused the exception. Exception handlers may define return codes based on which the operation in question may be aborted. Asynchronous operations may throw exception when the operation results arrive. Applications may also terminate execution from the exception handler.
INSTR Resource
The instrument resource type is a basic resource and virtualizes an instrument, providing attributes, events and operations. The basic operations relate to clearing, status reporting, read and write and trigger operations.
The read/write operations also support a moderately complex formatted buffered I/O. This is in similar lines to the standard C library printf() and scanf() functions, but extended to include special modifiers. For example, the specification defines additional modifiers like comma, @1, @2, @2, @H, @Q, @B, *, z, Z, h, b etc. A BNF grammar for the expressions has been given for implementing a parser. The formatted I/O functions share the buffers with other functions like ViBufRead/Write. There are also functions defined for memory I/O through peek/poke/mmap operations.
The INSTR resource definition includes about 50 functions, 40 attributes (GPIB and GPIB-VXI) and 5 event types.
MEMACC Resource
This resource must be supported if GPIB-VXI or VXI interfaces are to be supported. This resource type abstracts memory access, through register based/DMA and defines peek, poke, move, asynchronous move and memory mapping operations.
The MEMACC resource definition includes about 25 functions, 20 attributes and 1 event type.
INTFC (Interface) Resource
This resource abstracts an interface, and must be supported for GPIB interfaces.
A number of attributes defined here are in relation to buffer management. These include features like: flush on buffer full, flush on CRLF, flush on end of formatted I/O, termination character usage control, END assertion after a write, file i/o control etc.
Some special functions have been define for GPIB specific controls and commands.
The INTFC resource definition includes about 25 functions, 22 attributes and 6 event types.
BACKPLANE Resource
This resource allows manipulation of a specific mainframe on VXI or GPIB-VXI-based systems. Multiple mainframes/chassis may be controlled under a single BACKPLANE resource, but there should be at least one BACKPLANE resource per system.
Attributes include board number, interface type, logical address of slot-0 controller etc. Events and operations relate to triggers (VXI hardware triggers).
The BACKPLANE resource definition includes 5 functions, 10 attributes and 4 event types.
SERVANT Resource
This resource is meant for advanced users. The specification maintains that most VISA users will not need this level of functionality (intended for firmware coders) and should not therefore use the SERVANT resource in their applications.
Miscellaneous
Other considerations include startup, termination, reentrancy, memory management and system configuration management.
Implementation
Design & Coding
Under the WIN framework, implementation of the VISA spec calls for a Win32 DLL that runs under the Windows 32-bit operating system (WIN95, WINNT etc. frameworks are not distinguished in this document. Instead, WIN32 is implied).
The implementation needs to use native DLLs or libraries for interfacing with controllers on the bottom edge. On the upper edge it will expose VISA functions.
To allow multiple applications on the same computer to use the same VISA DLL and still have VISA exercise centralized control, the DLL instances will need to share state by explicit memory mapping/sharing, or by using features of COM on Windows. In the latter case, VISA may be implemented as an out-process singleton object COM server with a client DLL, and with call-backs or events implemented using COM connection points or messaging mechanisms (shim layer).
Overall, the implementation calls for a well designed framework involving multithreading and concurrency, shared resources, queuing and state management, buffer and session management, locks and timers, events and scheduling, protocol translations, and also implementing about 100+ functions, 100 attributes and 16 event types for GPIB and VXI/GPIB-VXI support.
Considerations as described in the California Software Labs white paper, "Issues in concurrent programming" should be applied to the design (see References). This is a popular white paper, prescribed for reference by advanced university courses.
It is also important that the architecture be flexible enough to support other lower-edge libraries (like GPIB32.DLL) in the future, so that new controllers/interfaces may be incorporated without much effort.
Testing
VISA32.DLL needs to be tested in both the WIN and GWIN frameworks. Availability of instruments and instrument drivers can be a bottleneck here. This also limits the amount of testing that is possible. For the GWIN framework, G source code based instrument drivers can be assumed to be available. Otherwise instrument drivers from the WIN framework imported into LabView as VIs may be used for testing.
References
- VPP-2 - System Frameworks Specification
- VPP-4.3 - The VISA Library
- VPP-4.3.2 - The VISA implementation specification for Textual Languages
- VPP-4.3.3 - The VISA implementation specification for the "G" Language