Instrument Control

VISA

VISA (Virtual Instrument System Architecture) is an attempt to create a standard I/O software package for VXI equipment. It also includes GPIB and serial interfaces. It was created as part of the VXIplug&play System Alliance.

VISA is an API (application programmers interface) that provides a uniform interface from a program to GPIB, VXI, GPIB-VXI and serial interfaces. Instead of using separate API's for each interface the VISA API can be used. This allows the programmer to generate code that can be easily ported to the different interfaces. (ie interface independent drivers). VISA can be incorporated into LabVIEW, LabWindows/CVI, Visual Basic or any ANSI C compiler.

Do I need one? Probably. Most new drivers from NI are based on VISA and all IVI drivers require VISA. Drivers that do not use any of these interfaces will not need VISA, but others will benefit. Developing drivers is difficult enough, if you have to develop drivers for each of the different interfaces it becomes a real challenge. It is possible with VISA to develop one set of drivers that will work for, say, both GPIB and serial. Once this is done either interface can be used with no change to the higher level software.

National Instruments' viewpoint on VISA

Several users have recently expressed disappointment at using National Instruments VISA driver in LabVIEW. While we realize that VISA (or any API) can't be all things for all people, it is our goal to make VISA suitable for all T&M development -- instrument drivers and applications alike.

For those of you who don't know me, I am the lead VISA designer/engineer at National Instruments. I have been involved with both the VISA specification and its implementation here at NI for a number of years. Since this posting is rather long, here's a summary of what follows:

- Initial reasons why NI created VISA - Benefits that certain customers see in VISA - Features of past/new versions of VISA - Request for feedback

Initially, we set out to make an API that users of multiple T&M interfaces could find commonality in. The best example of interface independence that we could think of is where you have an instrument that supports, for example, both GPIB and Serial connections. With a common API (VISA) you need only one instrument driver, and that driver does not care which connection you are using (except during initialization). Now as a couple of you have pointed out, a device with multiple ports is not a very common scenario. But most users do have more than just one device that they are using -- at least one of them has a GPIB connection and at least one of them has a Serial connection. Why is that important? Well, consider a new user (who doesn't have ready-made drivers for his instruments) that can now program his entire application with just one API. And for those of you familiar with (and content with) NI-488 and the LabVIEW Serial VI's, consider what might happen in several years when you need to replace an instrument. Suppose that the manufacturer of your GPIB/Serial instrument no longer uses that interface, but makes that same type of instrument for some other interface (such as PXI). NI will ensure that VISA can access all major interfaces for T&M instrumentation in the future.

VISA provides other benefits, too. Comments from certain users indicate that they prefer the refnum-oriented session-based nature of passing VISA handles from one VI to the next. Although this does complicate using VISA-based drivers interactively, the program flow is easier to read, especially in cases where you have more than one of a given instrument -- for example, production test. In addition, the attribute node introduced with VISA (now called the property node) allows you to set multiple configuration parameters such as timeout, EOS character, etc., in one place. Both of these technologies are becoming omnipresent in LabVIEW -- for example, VI server and ActiveX. As the recent postings to info-labview indicate, however, there is another group of users that would prefer a more traditional approach. We would like to please both camps, and that is why we introduced Easy VISA VI's in LabVIEW 5. We are interested as to whether this approach is beneficial.

Based on some of your posted comments, we acknowledge that we do still have some work to do -- otherwise, I wouldn't be writing this. However, we do feel that VISA is a mature product, and we are committed to continue improving it, as we have done since its inception. The initial VISA implementation (called VTL) had far less functionality than it does today. Since that time, VISA 1.0 added serial support, asynchronous I/O, and advanced features such as locking. Our VISA 1.2 release for Windows 95/NT added new tools for configuration (T&M Explorer) and debugging (NI Spy). Our next version of VISA (2.0 will be available later this year -- exactly when depends on which platform) adds remote/local control for GPIB devices and miscellaneous commands/queries for VXI devices. Our hope is that this release should remove 'performance' from the NI-488 vs. NI-VISA decision. In addition, we are adding serial support for all features that LabVIEW has that VISA currently lacks. This is important because in a future version, LabVIEW would like to provide all serial support through VISA. So rather than ignore and toss out the VISA serial functionality, please let us know if you have problems trying it. (Although this is not a call for VISA 2.0 beta users, let us know if you would like to help test it. If you have the time, your lab provides testing vectors that we'd never even dream of.)

If you've read this far, you're probably ready to respond. We do appreciate your feedback and will truly evaluate it for inclusion in future releases. Believe me, we'd like everyone to be happy with our VISA implementation. We know it can be easier to use, but we need you to tell us EXACTLY what you do and don't like about it now. Whether you have ideas for improvement, or just want to let us know (if applicable) why you chose not to use VISA, we'd like to know.

Troubleshooting VISA sessions

Did you open VISA sessions before trying to read and write? Did you get any error messages when you opened them? Did you supply the correct session IDs to the read/write VIs? You might want to report exactly what the error message is and exactly when it is reported. Cycle instrument and PC power, then use Probes or Simple Error Handler VIs to determine where the error first appears. Try sending an example message from the instrument manual verbatim. Verify that you are terminating your messages properly. Send your message to a front panel variable with \ codes enabled to see that you are sending exactly what you expect.

Releasing control over an instrument

It depends on what you mean by release control. A few instruments incorporate commands that explicitly lock their front panels. If you are using one of those, simply send the complementary command to unlock the panel. Some other instruments automatically lock their front panels when you send a GPIB command. For those, look up the unlock command (probably Local, LCL or something similar) and send that. Most instruments however do nothing to prevent local operation so there is no real need to "release control". Also remember that if you are dependent upon some instrument-based way of locking to secure the test system, be aware that all instruments will unlock their front panels when you power cycle them. Therefore don't forget to check the instrument to see whether it has been power cycled. Many instruments have a bit in their status register that is set if the instrument has been powered-up since receiving the last command, and since you should be reading this status register to check for errors anyway, it is a low cost way of verifying the instrument state.