This release of USB::LibUSB fixes a bug in the config descriptor data structure. Before the fix, only the first interface of a given configuration was represented. Now, the "interface" element of the config descriptor hash holds an array of interfaces, each of which consists of an array of alternate settings. Typically each interface has only one alternate setting:
my $config = $dev->get_active_config_descriptor();
my @interfaces = @{$config->{interface}};
# Get first alternate setting of first interface
my $first_interface = $interfaces[0]->[0];
Many thanks to Mike Ferrara who spotted the issue when porting code from Device::USB to USB::LibUSB.
]]>The Lab::Measurement software stack is a feature-rich solution for measurement automation and instrument control, which is both lightweight and highly portable to different operating systems. It is actively used by an increasing number of research groups, mostly for experiments in mesoscopic physics, but recently also in particle physics and quantum optics. In many cases it has completely replaced proprietary tools like LabView or Matlab!
The paper also covers the ongoing port of the stack to modern Perl techniques which lead to a considerable improvement of maintainability and extensibility.
Happy reading!
]]>The most important addition is a new high-level sweep framework written with Moose. Check out the new tutorial Lab::Moose::Sweep::Tutorial!
Comparing with the older Lab::XPRESS framework, the main new feature is support for block data. This is needed when working with instruments like spectrum analyzers or vector network analyzers which return an array of data in each measurement.
]]>So please come by on Monday, March 12, 2018, 15:00–19:00, Poster B, TT 29: Poster Session: Cryogenic Particle Detectors and Cyotechnique.
If you cannot wait until march, please consider the Perl in the Physics Lab presentation at FOSDEM by Andreas K. Hüttel, my supervisor, next weekend!
]]>The photo shows the rear panel of an Agilent 34410A digital multimeter. While it is a small and (relatively) cheap device, it supports four different automation standards (GPIB, USBTMC, VXI-11, raw TCP sockets). This is why I used it for most of my testing.
Now, let me tell you some details about the VXI-11 and USBTMC protocols and how we implement them with Perl.
Lab::VXI11
VXI-11 is a TCP/IP protocol based on the Open Network Computing (ONC) Remote Procedure Call (RPC). ONC RPC allows a client to call C-functions provided by a server and handles the serialization of the function's argument list. ONC RPC was developed by Sun Microsystems for their Network File System.
The VXI-11 specification defines several RPCs to perform read/write and control commands (like device clear) with the instrument.
To perform the RPCs, Lab::VXI11 uses Sun's ONC RPC library (sunrpc), which is part of libc on all major Unix platforms. We used the rpcgen program provided by sunrpc to parse the RPCL (remote procedure call language) contained in the VXI-11 spec. This creates C source and header files which define the client functions. XS does the rest.
USB::TMC
The USBTMC protocol is directly based on the USB 2.0 specification. For read and write operations it uses bulk transfers, which are designed to move larger blocks of data with high bandwidth. Error checking is performed in hardware.
Control operations, like device clear, are performed with control requests. Control requests are also used to access device information like the serial number, which uniquely identifies a device together with the vendor and product ids (For the Agilent DMM on the photo, the serial number is printed on the rear panel: "MY47000419").
The implementation of USB::TMC was inspired by the Python module python-ivi/python-usbtmc. Namely, it uses the libusb-1.0 library which provides cross-platform user-space access to the USB. The Perl interface to libusb-1.0 is provided by USB::LibUSB.
]]>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.
]]>