The Agilent 34461A has several connectivity options - LAN and USB, by default, with GPIB available as an option. This blog post will detail my experience with using both LAN and USB. Unfortunately, I do not have any equipment that uses GPIB, however, the use of GPIB is decreasing, partly due to the cost of the equipment and cables, and partly because both LAN and USB are much more readily available. For example, it is much easier to connect two devices to a LAN than run GPIB cables in between them, and it is considerably easier to connect a device directly to a computer using USB rather than using GPIB and a costly adapter or interface card.
Agilent provides drivers, available on their website, for both LabVIEW and MATLAB, which will allow those familiar with those software packages to interface with the multimeter. As I have no experience with either of these, I will not be reviewing how the 34461A works with them.
LAN
There are several possible methods to communicate with the 34461A over a LAN. The simplest is using the web interface, which is okay for basic use, such as in a situation where you can’t physically access the multimeter. But it is limited in its functionality. The other available methods are VXI-11 and sockets.
VXI-11 is a TCP/IP protocol that is standardised across manufactures, allowing the control of multimeters, oscilloscopes, logic analysers and other test equipment over a LAN interface. Due to this, it is quite complicated and normally requires using the manufacturer’s, or a third party's, driver. Additionally, the successor to VXI-11, HiSLIP, was announced in 2011, with the main advantages being IPv6 support and better performance.
The alternative to VXI-11 is to use the sockets interface, which is significantly simpler and has slightly better performance, due to the reduced overhead. This is also a TCP connection, but the SCPI commands are issued directly to the multimeter in plain text - essentially, it is a networked version of a serial interface. Due to its simplicity, this is the interface that I have been using.
Agilent, in both the datasheet and user manual, do not give the port numbers for the socket interface. However, after some searching on their website, I came across http://www.home.agilent.com/agilent/editorial.jspx?cc=GB&lc=eng&ckey=687300-1-eng&nid=-11143.0.00&id=687300-1-eng and in particular http://cp.literature.agilent.com/litweb/pdf/5989-6717EN.pdf which states that the port is 5025. There is also an additional port that can be used, primarily to receive interrupts from the device, which the application note discusses. However, I found that there was no need to use it in the tests that I did.
For simplicity, I used python to communicate with the sockets interface. It also has the advantage of producing easy to read code, with is quite useful. The code below, shows how to connect to the 34461A (with an ip address of 192.168.0.19) and ask it to send back its identifier.
import socket
s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('192.168.0.19', 5025))
s.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
s.settimeout(2)
s.send('*IDN?\n')
print 'ID: ' + s.recv(1000)
s.close()The python code first creates a TCP socket, which it then uses to connect to the multimeter. It then disables the Nagle algorithm on the socket (this is an algorithm that groups small packets of data together, but increases latency) and then sets the socket timeout to 2 seconds. It then sends the identifier request, ‘*IDN?’, followed by a newline character and prints out the returned string. The output of the above code using my 34461A is,
ID: Agilent Technologies,34461A,MY53200217,A.01.09-02.25-01.09-00.35-01-01
which, according to the manual, is the expected response - showing the model number, the serial number and the current firmware and board revisions.
For the creation of the histograms in my second blog post on the 34461A (Practical use of the Agilent 34461A), I used the sockets interface to fetch the histogram data, along with the readings’ statistics, with the following commands,
*IDN? SYST:TEMP? SYST:UPT? CALC:AVER:AVER? CALC:AVER:COUN? CALC:AVER:MAX? CALC:AVER:MIN? CALC:AVER:PTP? CALC:AVER:SDEV? CALC:TRAN:HIST:POIN? CALC:TRAN:HIST:ALL?
This, for the resistor characterisation in the second blog post, produced the following output,
Manufacturer: Agilent Technologies, product: 34461A, serial: MY53200217 ID: Agilent Technologies,34461A,MY53200217,A.01.09-02.25-01.09-00.35-01-01 Temperature: 27.1000004 Uptime: +0,+1,+55,+58 average +5.08478991E+03 count +9.60000000E+01 max +5.10537517E+03 min +5.07358317E+03 peak to peak +3.17919968E+01 STDDEV +5.30244622E+00 +100 +5.07000000E+003,+5.11000000E+003,+96,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0+0,+0,+0,+0,+0,+0,+0,+0,+0,+1,+0,+0,+0,+0,+0,+1,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+1,+0,+0,+0,+1,+0,+0,+0,+0,+0,+1,+0,+0,+0,+0,+0,+0,+1,+2,+1,+1,+0,+0,+0,+0,+0,+0,+0,+1,+0,+1,+1,+0,+0,+1,+1,+0,+0,+0,+0,+0,+0,+0,+2,+1,+0,+0,+1,+0,+1,+1,+1,+0,+0,+0,+0,+1,+2,+0,+0,+0,+1,+1,+2,+0,+1,+0,+0,+3,+1,+2,+2,+2,+0,+0,+0,+0,+4,+1,+0,+0,+1,+1,+0,+1,+2,+0,+3,+1,+1,+0,+0,+0,+3,+0,+1,+1,+2,+2,+0,+1,+0,+0,+1,+0,+0,+0,+1,+1,+0,+0,+0,+1,+0,+1,+1,+1,+0,+0,+0,+0,+1,+1,+0,+0,+1,+0,+0,+1,+1,+2,+1,+0,+0,+0,+2,+0,+0,+0,+0,+1,+0,+0,+0,+1,+2,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+2,+1,+0,+1,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+1,+0,+0,+0,+0,+0,+1,+0,+0,+0,+0,+0,+0,+0,+1,+0,+1,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+1,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+1,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0,+0
from which I was able to plot the histogram.
The histogram data above shows how the data is internally stored on the multimeter - despite the multimeter choosing to use 100 bins for the histogram, the data is actually stored in 400. Which explains why the number of bins can increase when the multimeter is left in automatic mode, but why the data is cleared when the number of bins is changed manually. Essentially, in automatic mode, the 34461A uses 400 bins internally, and combines adjacent bins when there are not enough readings.
The outputted statistics is also of a higher resolution, showing between 2 and 3 extra digits than what the multimeter’s display shows. While these extra digits are not particularly useful, as they are likely to be mainly noise, it is still a nice extra, that might be useful under certain circumstances. It is also worth pointing out that this extra resolution is for all numerical data obtained over any of the remote interfaces and also the exported CSV files, which can be saved to a USB flash drive from the 34461A’s front panel.
USB
The 34461A has a USB device interface on the rear of the unit, which can be directly connected to a computer. This interface uses the USBTMC (USB Test and Measurement Class). As I use Linux as my main operating system, I decided to use Python and libusb to talk directly with the multimeter, which isn’t too complicated to achieve. Overall, the USBTMC is fairly similar to the sockets interface, where commands and responses are communicated in text, however, this is wrapped in a more USB way. The Python class that I have written is attached to this blog post, and has 3 main functions when connected to an instrument - write, read and ask. Write outputs the text command to the multimeter, read reads the responses and ask combines the two, to make the code more readable. The text commands are the same SCPI commands that are used with the ethernet and GPIB interfaces.
Remote measurements
Often, the remote measurements are of a device that is being remotely controlled. As an example of this, I have written a program for the STM32F4 microcontroller that sets the value of 4 pulse-width modulation (PWM) channels via the UART interface. With the 4 PWM channels outputting to the 4 LEDs on the STM32F4 discovery board. This provides a way of changing the current consumption of the device in a fairly predictable way, that can be easily measured remotely.
The program for the microcontroller (split into main.c and uart.c/h) uses an interrupt to receive the UART data and update the PWM channels, with the PWM channels being part of the STM32F4’s timer peripheral. As the UART is a byte interface and the commands are two bytes long, I have added a synchronisation command so that the test program on the computer can ensure it is correctly controlling the microcontroller.
The test program (pwr_led_test.py) on the computer first sets the multimeter to the correct mode, then synchronises with the microcontroller, before running through the test. The test consists of setting all the PWM channels to zero (so that all the LEDs are off), then incrementing a channel at a time until it reaches its maximum, so at the end of the test all of the LEDs are fully on. After every change to the PWM channels, the current consumption is measured three times.
The duty cycle of the PWM channels has been set up to be a single byte for ease of control, with 0% duty cycle at 0 and 100% at 255.
The following graph is of the results for measuring the current consumption in two different ways - measuring the total current consumption of the board and measuring the current consumption of just the MCU (through the STM32F4 discovery board’s current measuring jumper).
The combined PWM value (the x-axis), is the addition of all the PWM channel’s values. The blue lines mark when each of the LEDs becomes fully on, with the finally LED being fully on at the right hand axis.
Each of the test runs took around 15 minutes when using an integration time of 100 PLC. Which is considerably quicker than if the measurements were to be made by hand. Whilst this might seem to be a bit of a contrived example, it is similar to tests I have done with microcontrollers and FPGAs, and, overall, is fairly representative of simple automated tests.
