| Using VISA.NET > API Structure > Interfaces And Classes |
One of the objectives of VISA, VISA-COM, and VISA.NET is to provide a common programming API for test system programmers across I/O protocols and vendors. In VISA.NET, .NET interfaces are used to define this API. Interfaces do not include any implementation code; they simply provide a very precise syntax for the API.
Classes provide the implementation that interfaces lack. Though there are exceptions, for the most part the IVI Foundation provides the interfaces, which are defined in the Ivi.Visa namespace, and vendors provide the classes that implement the interfaces. For Keysight VISA.NET, these classes are defined in the Keysight.Visa namespace.
Although the consistency of a common VISA.NET API provides important advantages in ease of learning and ease of use, consistent behavior does not necessarily mean identical behavior. Users always need to validate required behavior when qualifying test systems with a different VISA.NET implementation.
Implementations of VISA.NET from different vendors may behave differently for several reasons. Ambiguities in the specifications may lead to slight differences. I/O hardware (GPIB cards, for example) from different vendors may have different physical capabilities that affect VISA.NET behavior slightly. Different PC configurations may account for different performance. Be aware of the potential for these slight differences in VISA.NET behavior, and test appropriately!
The VISA.NET standard defines session interfaces that define the API for VISA.NET's I/O sessions.
VISA.NET vendors create one or more session classes to implement the session interfaces.
A session is a connection to a unique resource connected to the computer. Resources are categorized into resource classes. The most common resource class is a straightforward connection to an instrument. Other resource classes include hardware interfaces, VXI or PXI card cage backplanes, direct access to device memory, or, for LAN, connections to a device using a TCPIP socket. Each unique resource is identified by a unique (to the PC) resource ID called a resource descriptor.
![]() |
The word "interface" has two meanings in discussion of VISA.NET. On the one hand, "interface" refers to .NET interfaces, which are part of the VISA.NET software API. On the other hand, it refers to a hardware interface that can be used to connect a PC to test and measurement equipment. Usually context will make the meaning clear, but in cases where the meaning could be ambiguous, this documentation uses "hardware interface" when the second meaning is intended. |
An interface in .NET is similar to a class, but does not provide an implementation. Instead, each interface specifies the syntax of a set of methods, properties, events, and so on. An interface may be implemented by multiple classes, each of which implements the methods, properties, and other elements in the interface. The core of the VISA.NET API is a set of interfaces.
An interface definition defines both the syntax and a loose semantic description of the elements in the interface, and thus of the interface as a whole. This semantic describes the observable behavior of an interface's implementation; different implementations may vary internally as long as the observable behavior conforms to the semantic. In other words, the semantic description of the interface is tight enough to provide reliable behavior across multiple implementations but not so tight that only one implementation is possible.
Using the VISA.NET standard, many vendors can create vendor-specific implementations of the VISA.NET standard interfaces. These vendor-specific implementations conform to the semantic description of each implemented interface, so that there is a consistent user experience from one vendor's VISA.NET to the next. A user who becomes familiar with Keysight VISA.NET will find an easy transition to other VISA.NET implementations.
To illustrate the value of this approach, consider the following examples.
Many box instruments use SCPI message-based command sets for remote communication. SCPI may be used with a variety of I/O protocols, including GPIB, LAN, USB, and I/O vendor specific protocols. Instead of having to learn multiple ways of communicating with SCPI-based instruments, depending on the vendor and I/O protocol being used, you can use VISA.NET, which provides interfaces (IMessageBasedSession, IMessageBasedRawIO, and IMessageBasedFormattedIO) geared to message-based communication. Because the semantics are carefully defined, implementations of these interfaces will exhibit relatively consistent behavior across vendors and I/O protocols.
Consider the case where vendors provide I/O hardware for a specific I/O protocol. There are several vendors, for instance, that provide GPIB plug-in cards or USB-to-GPIB converters, all of which support GPIB communication. Each vendor must provide a software layer that is specific to the hardware, and if the story ended there, software could be radically different depending on which vendor's I/O hardware was being used, even when using the same instrument. VISA.NET provides interfaces geared to a variety of common I/O protocols, including GPIB. By implementing these interfaces in such a way that they hide the hardware-specific code underneath a common interface definition with consistent GPIB behavior, VISA.NET provides relatively consistent behavior across vendors' GPIB I/O hardware.
Consistent with .NET naming guidelines, VISA.NET interface names all start with the letter I - for example, IVisaSession, IGpibInterfaceSession, and ITypeFormatter.
Many VISA.NET interface names end with the word "Session". In VISA.NET, a session is a connection to I/O hardware or to an instrument (or other device) via I/O hardware. IGpibSession, for example, supports a connection to a GPIB instrument. Interface inheritance is used extensively for session interfaces, so that IGpibSession derives from IMessageBasedSession, which provides common functionality for message-based instrument regardless of the I/O protocol. In turn, IMessageBasedSession derives from IVisaSession, which provides common functionality for all types of VISA.NET sessions. For more information about VISA.NET session interfaces, refer to Resources and Sessions.
There are several VISA.NET interfaces that are not session interfaces:
Keysight VISA.NET class names do not start with any particular letter, but they often are the same as the primary interface they implement, without the leading I. For example, Keysight VISA.NET uses the Keysight.Visa.GpibSession class to implement the Ivi.Visa.IGpibSession interface.
Many VISA.NET class names also end with the word "Session". In general, the session classes derive from more than one interface. GpibSession, for example, ultimately implements functionality defined in IVisaSession, IMessageBasedSession, and IGpibSession. To be more precise, GpibSession predictably derives from IGpibSession, but also inherits MessageBasedSession, an abstract class that derives from IMessageBasedSession, and MessageBasedSession in turn inherits VisaSession, another abstract class that derives from IVisaSession. For more information about VISA.NET session classes, refer to Resources and Sessions.
Keysight VISA.NET defines several classes that are not session classes: