Visa is Virtual Instrument Software architecture.  To understand why it is useful, think about a lab with a variety of instruments, using a variety of the busses described above. Now, to interface with them from your own software, you need to learn how to handle TCP sockets, to read and write from serial ports and so forth.  Also, some instruments have more than one connector, and if you decide to change from the GPIB port to the serial port because someone wants to borrow the expensive GPIB converter, you have to change your software.  VISA wraps all these different hardware busses and provides a simple, uniform interface.  You can swap from serial to Ethernet by just changing the VISA address. Most VISA implementations also offer some handy extras, such as the ability to list all connected instruments and test sending and receiving messages with them, and the ability to log all messages sent and received by any instrument, which can be helpful for debugging. Several manufacturers of instruments provide VISA implementations, but they are designed to be interchangeable (except for some small caveats around GPIB).  You can use anyone’s instruments with any VISA implementation, and you can pick one based on features and cost. Most are free if you have hardware from that manufacturer.  Two in particular are worth mentioning:

• NI VISA from national instruments is the most common. It has lots of nice features, but it is a large and slightly frustrating install, especially if you don’t already have other NI software. It is also rather expensive if you don’t have it included with other NI hardware or software.
• R&S VISA from Rohde & Schwarz is compact, simple, and appears to be available for free to anyone at the time of writing.

Other manufacturers, including Tektronix, Keysight, Anritsu, Bustec, and Kikusui also offer VISA implementations.

Instrument commands and SCPI

Once you have the hardware set up, and VISA (if you want it), you can communicate with your instruments. But what do you actually send to them? The vast majority of instruments use short strings of ASCII characters and use newline characters to indicate the end of a command. There is a mix of Windows and Linux style newlines used, but CRLF is the most common. Hopefully the instrument manual will have a list of commands and their effects, but if not, check if it mentions SCPI or IVI, it may be that it supports exactly the commands defined in a standard somewhere. Standard Commands for Programmable Instruments (SCPI) is useful standard which is worth discussing at this point. It contains three useful things:

• A particular style of writing commands and responses which a lot of instruments use. Even instruments which don’t comply with the standard often use the same format. An example: SOUR:VOLT 2 to set a voltage, or SOUR:VOLT? To read it.
• A short list of commands every instrument should have, and a huge list of commands supported by Interchangeable Virtual Instruments.
• Several extensions which are not commands, such as status registers, which allow you to get the status of an instrument at a glance. Some of these can also be used to trigger actions on the PC outside of the usual command-response pattern, but only over GPIB or USBTMC with the USB488 subclass.

One of the useful commands many instruments support is *IDN?\n, which makes the instrument tell you what it is. Very useful if you have a lot of COM ports and don’t know which is which. Not everything uses SCPI-like commands though, we have several items in our lab where all commands are just a letter and 3 digit number.

Programming and scripting

But how do you actually run your experiment? The final piece of the puzzle is writing a script.  There are three main programming languages people use for this:

• NI LabVIEW. This is a graphical programming language, where you have functions as little blocks and join them with wires which carry values about. Some people find this intuitive but I’m not a fan personally.
• MATLAB is a programming language designed to work nicely with maths and arrays of data.
• Python is a general purpose programming language with huge numbers of modules for all sorts of tasks, and it is available for free. This one is my personal preference, so I’ll use it for examples below.

Both of the latter two can also be useful for analysing large data sets and drawing graphs, but that is a whole other topic. Here is an example then of how you might use Python to ramp the voltage in one of our power supplies:

import serial
import time
with serial.Serial('COM1') as rp100:
      rp100.write(b'OUTP1 1\n')
      rp100.write(b'SOUR1:VOLT 1\n')
      time.sleep(0.1)
      rp100.write(b'SOUR1:VOLT:SLEW 0.1\n')
      rp100.write(b'SOUR1:VOLT 20\n')
      time.sleep(200)

In this example, I’m using serial directly (not VISA) and I’m writing a series of text commands to the instrument, then waiting for the instrument to do its thing.  The 200 second wait at the end is because that is how long the ramp will take. One could write an entire experiment like this, but that would be frustrating and error prone.  It would be better to use the programming language’s features to automate and simplify repetitive tasks by writing functions and (depending on the language) creating objects to represent instruments.  Fortunately, in the age of the internet, many other scientists have written helper code for a huge number of instruments, and made them available. Some interesting frameworks for communicating with instruments are:

• Qcodes
• Pymeasure
• Pyinstrumentkit
• We have uploaded the one we wrote and use here at Razorbill.

You can find links to the above and other customers pre-written scripts here. And many more almost certainly exist.  There are also many little snippets of code out there for specific instruments, and we list some of the ones which have been written for our instruments on the page for those instruments.

Interprocess communication

There is one more oddity which is worth mentioning, though I won’t go into detail here.  Sometimes, a computer program has already been written, and it does lots of useful things but not quite everything you need.  And you can’t edit it.  A common case where this crops up for our customers is PPMS users.  Quantum Design produce a piece of software called MultiVu, and it handles many things that the PPMS does such as pumping out the sample chamber, reading and controlling the temperature etc. But it is difficult to make MultiVu handle other instruments. The solution here is to let MultiVu control the PPMS, and use your script to control MultiVu. If you need to control another piece of software, look to see if that software has an Application Programming Interface  (API) or a scripting interface. It is often the case that it will not be in the programming language you are using, but the languages listed above are all able to wrap APIs designed for common languages like C++.

Final tips

Hopefully if you are still reading at this point, this blog post has been useful.  I’ll close with some extra tips from my experience:

• Log everything because hard drive space is cheap. If you are getting a parameter from an instrument, think if there are any more you could record. Even if they aren’t useful now, they might be useful for debugging.
• You will probably end up with a selection of classes/functions/modules you use, and a separate script for each experiment. Save that script in case you need to work out exactly how you acquired certain data.
• Once you have a system that works, and you are confident it is safe to do so, you can script data collection in advance and walk away. We routinely gather data 24 hours a day in some of our experimental and quality control systems.