LXI, or LAN eXtensions for Instrumentation is a modern control standard for connecting electronics instrumentation which supports ethernet. It replaces the older GPIB standard, giving much better performance and lower cost of implementation. This is a good thing. [Martin Lund] has created the open source lxi-tools project which enables us to detach ourselves from the often bloated vendor tools usually required for talking LXI to your bench equipment. This is a partial rewrite of an earlier version of the tool, and now sports some rather nice features such as mDNS for instrument discovery, support for screen grabbing, and a LUA-based scripting backend. (API Link)
SCPI or Standard Commands for Programmable Instruments is the text-based language spoken by many instruments, allowing control and querying of an instrument. Just to be clear, SCPI is not at all a new thing, and older instruments that have GPIB or RS232 connectors, still could talk SCPI. lxi-tools is not for those. Some instruments can also be very picky about the formatting of commands, especially if they’re buggy, so the ability to interactively debug commands is very desirable. It is quite possible to make poor use of SCPI commands in your test script and end up with tests that just take far longer to execute that they need to. lxi-tools has a benchmarking tool too, which helps you to dig in and find out where all the time is going and make suitable adjustments.
A few months ago, I was discussing the control of GPIB equipment with a colleague. Based on only on my gut feeling and the briefest of research, I told him that the pricey and proprietary GPIB controller solutions could easily be replaced by open-source tools and Linux. In the many weeks that followed, I almost abandoned my stance several times out of frustration. With some perseverance, breaking the problems into bite-sized chunks, and lots of online searching to learn from other people’s experiences, my plan eventually succeeded. I haven’t abandoned my original stance entirely, I’ve taken a few steps back and added some qualifiers.
What is GPIB?
Back in the 1960s, if test equipment was interconnected at all, there weren’t any agreed-upon methods for doing so. By the late 60s, the situation was made somewhat better by card-cage controller systems. These held a number of interface cards, one per instrument, presenting a common interface on the backplane. Although this approach was workable, the HP engineers realized they could significantly improve the concept to include these “bridging circuit boards” within the instruments and replacing the card cage backplane with passive cables. Thus began the development of what became the Hewlett-Packard Interface Bus (HP-IB). The October 1972 issue of the HP Journal introduced HP-IB with two main articles: A Practical Interface System for Electronic Instruments and A Common Digital Interface for Programmable Instruments: The Evolution of a System. Continue reading “Save Money And Have Fun Using IEEE-488”→
We’ve got two hands, so it’s natural to want to use both of them while diagnosing a circuit with an oscilloscope. Trouble is, keeping both hands on the probes makes it a touch difficult to manipulate the scope. If only there were some way to put your idle lower appendages to work.
This multipurpose oscilloscope footswitch interface makes so much sense that we wonder why such a thing isn’t standard equipment on more scopes. [Paul Roukema]’s interface relies on the USB Test and Measurement Class (USBTMC) protocol that allows most modern scopes to be remotely controlled, somewhat like the General Purpose Interface Bus (GPIB) protocol of old. [Paul]’s interface uses an STM32 microcontroller to talk USBTMC to either Keysight’s Infinium scopes or the Tektronix DPO line, since those were what he had to test against. Tapping the footswitch cycles the acquisition mode on and off or triggers a single acquisition. He’s thoughtfully included the USBTMC specs in his GitHub project, so adapting it to other scopes should be straightforward. We’d even wager that older scopes with GPIB could enjoy the same handsfree control.
If you want to log voltages or resistance these days, no problem. You can buy a multimeter with Bluetooth for a hundred bucks, and if you’re really fancy you can spring for the Fluke with a graphical display that will log values automatically. Things weren’t always this cheap and easy, but there was always a way to do it.
Back in the 80s, HP had GPIB, or HP-IB, or IEEE-488 connectors on the back of their benchtop equipment. This was an 8-bit interface not unlike a parallel port that allowed for remote control of test equipment. In a great demonstration of what this was actually like, [AkBKukU] posted a video of connecting an old benchtop multimeter to a vintage computer over GPIB.
The computer used for this feat of retrotechtacularness is an HP Series 80, a footnote in the history of desktop computers, but it does have a custom CPU and BASIC in ROM. As you would expect from vintage HP gear, there are a few slots on the back of the computer for connecting interface boxes, including a modem, a speech synthesizer, and of course, an HP-IB interface that can speak IEEE-488.
With the multimeter connected to the computer over the daisy-chainable parallel interface, it was a simple matter of writing a little bit of BASIC to read a potentiometer and a thermistor. With a little bit more code, this computer can even produce a graph of the resistance over time. This is data logging like it’s 1982, and it’s a fantastic example of exactly how far we’ve come.
If you still use old test equipment on a regular basis, you probably have been frustrated by the lack of options for pulling data off these aging devices. Many higher-end devices are equipped with GPIB ports, which are general purpose buses for communicating with a variety of obsolete peripherals. Since GPIB disk drives aren’t too common (or practical) these days, [Anders] made a GPIB adapter that emulates a disk drive and stores data to an SD card.
[Anders] designed a PCB with a PIC microcontroller that plugs into a GPIB port. The PIC emulates a disk drive using the AMIGO protocol or the SS/80 protocol, which can be selected in a configuration file on the SD card. Most test equipment supports one of these two protocols, so his adapter should work with pretty much any GPIB-equipped kit.
Data is saved to a single image file on the SD card, which is encoded in a native HP disk format. The image file can be opened on Windows and Linux with some utilities that [Anders] mentioned on his project page. If you have any old test equipment withGPIB lying around and want to build your own, the schematic and source code are up on his site or [Anders] is selling bare boards.
If you’re not so daft as to think Arduino-based oscilloscopes and multimeters are actually useful for all but the simplest tests and measurements, you just might have some big iron sitting around your workbench from the likes of HP, or Tektronix. You might have noticed a strange port on the back of these machines, labeled GPIB or IEEE-488. This is the standard interface for these devices, and if you’ve ever priced out a USB to IEEE-488 converter, you can see why [Steven] thought it would be cheaper to build his own.
This build is an update to an earlier version we saw a few years ago. Since then, [Steven] has taken some advice from the community and replaced a bunch of resistors with proper GPIB line driver ICs, and generally cleaned up the firmware.
Because a USB to GPIB adapter is only one small part of the tools necessary to connect these old measurement devices to a modern computer, [Steven] has also been working on InstrumentKit. It’s a Python library that takes all the standardized instrument commands and wraps them up in an easy to use API. You can check out the docs for InstrumentKit here, or just look through the board files and firmware on the Github
Dust off that old GPIB hardware and hook it up to your modern computing platform using either of these two solutions. If you haven’t a clue what we’re talking about you probably don’t own any fifty-year-old test equipment. But the General Purpose Interface Bus (aka IEEE-488) was fairly common on 1960’s era test equipment like multimeters and logic analyzers.