NI-VISA Overview

Publish Date: Apr 05, 2019 | 67 Ratings | 3.28 out of 5 | Print

Overview

This document gives an overview of National Instruments' implementation of the Virtual Instrument Software Architecture API, commonly referred to as NI-VISA. You can use NI-VISA to communicate with most instrumentation buses including GPIB, USB, Serial, and Ethernet. It provides a consistent and easy to use command set to communicate with a variety of instruments.

Table of Contents

  1. History
  2. Advantages of VISA
  3. VISA Terminology
  4. A Typical VISA Application
  5. Additional Resources

1. History

For years industry has moved towards purchasing instrumentation from a variety of vendors. This allows engineers to choose the best instruments for their application without being constrained to a specific vendor. This caused the invention of hardware standards like SCPI that were designed to allow interoperability between instruments of different vendors.

Even with these standards in place, it was still a difficult task to build a test system with instruments from different vendors. In 1993 National Instruments, along with several companies including GenRad, Racal Instruments, and Tektronix, formed the VXIplug&play Systems Alliance. VXI was the standard at the time for modular instrumentation. The goal of the alliance was to ensure multi-vendor interoperability for VXI systems and to reduce the development time for a fully working system including multi-vendor instrumentation. VISA was deseverveloped through this alliance with hopes of increasing productivity through a decrease in system setup time.

 

Back to Top

2. Advantages of VISA

One of VISA's advantages is that it uses many of the same operations to communicate with instruments regardless of the interface type. For example, the VISA command to write an ASCII string to a message-based instrument is the same whether the instrument is Serial, GPIB, or USB. Thus, VISA provides interface independence. This can make it easy to switch interfaces and also gives the users who must program instruments for different interfaces a single language they can learn.




VISA is also designed so that programs written using VISA function calls are easily portable from one platform to another. VISA does this by defining its own data types. This prevents problems like, for example, possible problems caused by moving from one platform to another where the size of an integer may be different. In other words, a LabVIEW application written with VISA calls can be easily ported to another platform that supports LabVIEW. NI-VISA supports several operating systems, including currently supported Windows OS versions, MAC OS versions, and Linux distributions.

VISA's greatest advantage is that it is an extremely easy language to learn. VISA provides a very simple-to-use API that has bus independent functions for most of its I/O functionality. VISA provides the most commonly used functionality for instrumentation in a very compact command set, eliminating the need to learn low level communication protocals for multiple bus types.

 

Back to Top

3. VISA Terminology

Before you start using NI-VISA it helps to learn a little terminology commonly used throughout the development process. The most important objects in the VISA language are known as resources. A VISA Resource is any instrument in your system (this includes serial and parallel ports). If you have multiple resources connected to one GPIB controller, each of those instruments is considered a VISA Resource.

An Instrument Descriptor is the exact name of a resource. It specifies the interface type (GPIB, serial, USB), the address of the device (logical address or primary address) and the VISA Session type (INSTR, Event, or INTFC). A VISA session is a path of communication to a VISA Resource, so you must open a VISA Session any time you want to do VISA communication to an instrument. A VISA Alias is basically a nickname for a VISA Resource. You could give an instrument located on [GPIB0::3::INSTR] a visa alias of "Function Generator". Then, in your application you could make calls to "Function Generator" instead of having to use the instrument descriptor.

 

Back to Top

4. A Typical VISA Application

A typical VISA application would go through the following steps.

1) Open a Session to a given Resource.
2) Do any configuration on the given resource (setting baud rates, termination character, etc...).
3) Perform writes and reads to the device.
4) Close the Session to the Resource.
5) Handle any errors that may have occurred.

The following is a LabVIEW application that opens a session to a GPIB Instrument, performs a write of "*IDN?\n" and then queries the device for its response.


This exact same format would be used in a text based language like C++ or Basic. You would also follow this exact same format if the instrument was Serial, USB, Ethernet, IEEE-1394, or any of the other buses VISA supports. All you would have to change is the Instrument Descriptor connected to the VISA Open. This code would run on any operating system that supports LabVIEW and NI-VISA.

 

Back to Top

5. Additional Resources

Back to Top

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit