Simon Reinhardt

The Lab::Measurement project provides Open Source control of test & measurement devices with Perl. On our recent poster, which was presented at this year's DPG Spring Meeting of the Condensed Matter Section, we mainly discuss the high-level aspects of Lab::Measurement necessary to perform highly complex measurement tasks with simple scripts.

Now, the topic of this post is the CPAN release of Lab::Zhinst, which provides a Perl5 interface to devices from Zurich Instruments, a vendor of fast digital lock-in amplifiers, phase-locked loops, arbitrary waveform generators, impedance analyzers, digitizers, and boxcar averagers. There is no doubt about the excellent performance of their hardware. But when it comes to their approach to measurement automation it very much differs from what is commonly provided by Test & Measurement equipment. Let me explain by comparing their proprietary approach to the existing open interfaces. These open interfaces make it possible to control test & measurement equipment with general-purpose programming languages, like Perl, Python, Java, Ruby, Scala, or what have you.

Independently of the used low-level bus, most of today's test & measurement equipment is controlled by a text-based command language defined by the IEEE-488.2 and SCPI standards. At the bus level, one can choose between several different alternatives. These are the most popular connection back-ends used by Lab::Measurement:

GPIB. Invented by HP, this bus was standardized as IEEE-488 in 1975. In our labs this is the most used back-end, but this might change in the future as modern alternatives provide superior performance at lower cost. On Linux we control GPIB with the Open Source LinuxGPIB kernel drivers. I'm not aware of a Open Source GPIB driver for Windows. National Instruments' IEEE-488 driver seems to be the only option.

Lan/TCP Sockets. IMO currently the best connection type. This is actively pushed as successor to GPIB by the LXI Consortium, which is supported by most test & measurement companies. With TCP Sockets, we can directly talk to instruments on all platforms with core perl modules like IO::Socket::INET. No need for third-party software!

USBTMC. The USB Test & Measurement Class is an official part of the USB 2.0 Specification. It provides extremely low latency and does not need any existing network infrastructure, as you can connect your instruments directly to the PC. The Linux kernel's usb subsystem contains a USBTMC driver. The main issues of this driver are it's hard-coded timeout of 5 seconds (not enough for many tasks) and the lack of support for device discovery (our back-end relies on lsusb to do it). The best solution seems to be the approach taken by the python-ivi project: Use libusb instead of kernel drivers. My plan is to do the same thing with Perl.

Most new devices support each of these connection interfaces, which can come handy if you have a measurement setup with equipment from many different vendors. In our case we often depend on legacy equipment and GPIB is the lowest common denominator. The compatibility of USBTMC and LXI standards with GPIB ensures that we can continuously update our measurement setups to the newer connection backends.

Now, the automation software of Zurich Instruments does not conform to any of the aforementioned standards. Recently I was asked by Lab::Measurement users to provide a driver for their newly acquired Zurich Instruments MFIA Impedance analyzer (essentially this is a lock-in with a second demodulator to measure both voltage and current in 4-Terminal measurements). Controlling this device requires installation of the company's proprietary "LabOne" software, which then speaks to the device via a proprietary TCP-based protocol (see the LabOne Programming Manual for more details). LabOne provides APIs for C, Python, .NET, MATLAB and LabVIEW. The only supported architectures are x86 and x86_64. Clearly, there is no pure Perl solution. Lab::Zhinst is built on top of LabOne's C API.

Of course, it's not possible to bundle the required proprietary library with our CPAN modules. The user needs to install it manually. Also we cannot rely on the CPAN Testers to run the tests of the module on different Perl versions and operating systems.

There might be specialized applications which profit from the advanced functionality of the LabOne APIs. The problem arises when one needs to integrate Zhinst devices into existing measurement infrastructure. In this case, the incompatibility of LabOne with existing standards creates a challenge.