Creating a Keithley 2000 Multimeter Software Setup: A Practical Checklist for Test Engineers

If you're setting up a Keithley 2000 multimeter for logged measurements or automated bench testing, you might be wondering what's actually required to get it talking to your PC. This isn't a deep dive into every SCPI command—it's a focused checklist based on what we do in our lab. I'm the quality compliance manager here, and I review our test setups before they go into production use. Roughly 80% of our automated test procedures involve a DMM at some point, so by now I've seen a fair amount of what goes wrong and what works.

This checklist is for engineers who're at the point where the manual is too long and the examples online are too scattered. You have the instrument on your bench, you have a PC, and you're wondering what to do first. Here's the path I use, with a few real-world notes.

Know Your Interface Options First

The Keithley 2000 has GPIB, RS-232, and—on later revisions—an optional GPIB/Ethernet combo (the Model 2000-SCAN, though that's more for scanning). For most setups, the RS-232 or GPIB interface is what you'll use. If I'm honest, I usually prefer GPIB when it's available because it's less finicky with drivers.

One thing I've learned the hard way: don't assume the rear-panel settings are correct. Check the instrument's `SYST:PRES` state and the communication parameters before hooking anything up. I remember a batch of test sequences in early 2024 that failed simply because the baud rate on the 2000 was set to 9600 while the controller expected 19200.

Step 1: Install the Right Driver (And Know Which One You Actually Need)

Keithley provides separate drivers depending on your programming environment. For a 2000, the most common route is the Keithley I/O Layer (KIO) with the VISA library, or National Instruments VISA if you're already in the NI ecosystem. The truth is, you can install the NI-VISA runtime and it'll recognize the Keithley 2000 over GPIB without extra Keithley-specific drivers, because it follows the standard SCPI command set.

But if you're using Keithley's own Test Script Builder (TSB) or need the instrument-specific LabVIEW driver, you'll want the Keithley I/O Layer. I've seen too many people install the entire Keithley Test Environment just to run a simple read command. That's like buying a machine shop to hang a picture frame.

Step 2: Configure the Communication Port

Let's say you're going RS-232 because your PC doesn't have GPIB. On the 2000, go to the front panel and set:

• 232 baud rate: 9600 or 19200 (pick one and stick with it)
• Parity: None
• Handshake: None or Xon/Xoff. I use None.

Then, on the PC side, make sure you match exactly. A common mistake is leaving flow control as “Automatic” in the terminal program, which then behaves differently than expected during long logging sessions.

One note: the 2000's RS-232 is an isolated port, which is good for reducing ground loops, but it does not receive voltage if you're using a null-modem cable with some laptops. If the instrument isn't detected, check this first. I had to learn this the expensive way.

Step 3: Use the Correct Cable and Adapter

A standard straight-through DB9 cable works for GPIB? No—this is separate. For RS-232, you generally need a null-modem cable (crossed TX/RX). The 2000's rear connector is a DB9 male. Many lab PCs still have DB9 or you use a USB-to-RS232 adapter. The cheap USB adapters can be flaky—I'm not saying you need the $200 one, but if the link drops intermittently, that's the first thing to suspect.

For GPIB, you'll use a standard IEEE-488 cable. For older Keysight/HP boxes and Keithley, they all use the same 24-pin connector, but be aware that some laptops need a GPIB-USB-HS from NI to work reliably. I've used a cheaper clone once, and it worked until I increased the transfer rate. Not a good experience.

Step 4: Verify the Connection with a Simple Read

Before writing a full program, I always verify with a simple command. Using a terminal emulator or a quick Python script with `pyvisa`:

import pyvisa
rm = pyvisa.ResourceManager()
instr = rm.open_resource('GPIB0::16::INSTR')
print(instr.query('*IDN?'))

You should see something like:

KEITHLEY INSTRUMENTS,MODEL 2000,,

If you see this, the connection is good. If not, don't adjust the code yet—check the address first. The 2000's GPIB address is normally set to 16, but it may have been changed by a previous user. On the front panel, press SHIFT then 0 to enter the configuration menu, and check `GPIB ADDR`.

Step 5: Configure the Measurement Range and Speed

The default on a fresh instrument after *RST is Auto range, and NPLC (number of power line cycles) is at 1, which gives you decent DC noise rejection but isn't the fastest. For a datalogging setup, I often set NPLC to 0.1 or 0.01 for faster readings, but you must understand the tradeoff: lower NPLC means more noise. The 2000 is a 6.5-digit multimeter, but you don't get 6.5-digit accuracy at 0.01 NPLC.

If I'm being honest, I don't have hard data on how much noise you'll see on every range; it depends on the circuit and cabling. But my experience has been that for most design validation logging, using 1 NPLC is the sweet spot. You get stable readings and it's still fast enough to capture a sweep every 200ms.

Step 6: Set Up the Buffer and Triggering (This is the Step People Miss)

You can just send `READ?` repeatedly in a loop, but for long-term logging, internal triggering with the buffer is far more efficient. The 2000 has a 1024-reading buffer in the standard model. You can easily do this:

*RST
:SYST:BEEP
:INIT
:FETCH?

But here's the step that's often ignored: clear the buffer before starting a new log. If you don't issue `:TRAC:CLE`, you'll be fetching old readings along with new ones. This may sound obvious, but I've seen experienced engineers wonder why their log has extra data points at the beginning. The buffer isn't automatically cleared on power-up.

Step 7: Think About the Data Format

When you issue `FETCH?`, the 2000 returns a comma-separated string. For example:

+1.000000E-03,+1.000000E-03

Most programming languages can parse that easily. But if you're logging directly to a CSV file from a terminal program, the comma separator can conflict with your column delimiter. I usually configure the instrument to use ASCII format and then use semicolons in the CSV file to avoid the collision, or I write a small parser. I wish I had standardized this earlier; I remember a late-night data analysis session where the parsing took longer than the actual test.

8. Things I'd Likely Do Differently: A Note on the DMM6500

I know you might be comparing the old 2000 with the newer Keithley DMM6500 (which that 6.5-digit model has a bigger touch screen, more memory, and a web interface). I don't want to write a whole comparison, because you might be using a 2000 for a reason—cost, existing rack, or simply for a simple DCV measurement where it's perfectly adequate.

But if you're just setting up a new system and don't have an existing 2000, I'd seriously consider the DMM6500. The software interface is much more modern, and the built-in digitizer and data log features save you from needing an external switch. For us, the DMM6500's higher reading rate at a given accuracy actually reduced our testing time significantly.

Still, the 2000 is a solid workhorse. Don't let anyone tell you it's obsolete.

Common Pitfalls and a Quick Reminder

• Don't use an RS-232 null-modem cable on a port that's already a straight-through—verify pinouts with a multimeter if unsure. (If you're in a hurry, just test it with loopback.)
• Don't forget that the 2000's SCPI tree is mostly IEEE-488.2 compliant. If a command doesn't work, check if you're using the instrument-specific flavor. For example, `READ?` and `FETCH?` are standard, but `:MEAS:VOLT:DC?` is straight SCPI.
• If you're in a hurry, just test a known voltage with a battery. It's a 10-minute setup and it verifies the whole path: instrument, cable, driver, code.

And one more thing related to the title I mentioned earlier: “which fluke multimeter to buy” is a completely different question. That's for handheld field work, not benchtop precision. I manage a lab and I buy a Fluke 87V for my field techs, but for a production line, I'd never choose a handheld over a Keithley 2000 or DMM6500. You need the accuracy and the automation interface.

If you remember just one thing from this article: the software for a Keithley 2000 is not really about a specific software package. It's about using the correct driver, verifying the interface, and structuring your typical SCPI commands properly. Nail that down and the instrument becomes just a tool.