HP/Agilent/Keysight 34401A DMM driver (beta)

The 34401A is the counterpart of the Keithley 2000 DMM. It has been in production for over a decade and sold under the HP brand as well as its successor Agilent and lastly, todays Keysight brand. It is an ubiquitous device of which either it or its Keithley equivalent can be found numerous times in companies which focus on electronics. As such, it would be highly desired to get it included in SweepMe for logging purposed.

Therefore, I created an appropiate driver based on the existing Keithley 2000 driver. Both instruments are sufficiently new to be based on standard SCPI commands. The modifications are therefore mainly restricted to adjusting the driver to the different capabilities and behaviours, e.g. how the RANGE command is applied for functions other than DC voltage and current or how the DISPLAY command is handled in terms of parameters.

The current driver supports Voltage/Current DC/AC, Resistance 2W/4W (Kelvin), Frequency, Period, Diode and Continuity. It has recently been discovered that the 34401A could be special ordered with a temperature capability and other options by US goverment/military institutions and that these features could be unlocked afterwards. Hoewever, as these are officially not supported by Keysight and I am not inclined to modify my own or one we have at work, I am not able to test this mode and therefore decided to exclude it from the driver for the time being.

As these units are often used to measure small but constant values, an 100 NPLC setting has been added in a way not to interfere with current terminology for the 0.1, 1 and 10 NPLC settings. I find the new terminology a great fitting but boring alternatives like “very slow” would also be OK :smile:

My tests seem to suggest that the driver works flawless and might even deserve a higher than “beta” status. However, additional features could still be added to finetune some measurement behaviours plus I cannot check for the COM port functionallity as SweepMe just detects my internal COM1, neglecting my COM2 and COM3 ports on my PCI-e addon card but fails to get access even on said internal COM1, so the COM port option has to be checked later (maybe add this restriction into the driver description until it is taken care of?).

Best wishes,
Christian


# This Device Class is published under the terms of the MIT License.
# Required Third Party Libraries, which are included in the Device Class
# package for convenience purposes, may have a different license. You can
# find those in the corresponding folders or contact the maintainer.
#
# MIT License
# 
# Copyright (c) 2020 Axel Fischer (sweep-me.net)
# 
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
# 
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
# 
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.


# SweepMe! device class
# Type: Logger
# Device: Keysight 34401A


from EmptyDeviceClass import EmptyDevice

class Device(EmptyDevice):

    description = """<p><strong>Keysight 34401A</strong></p>
                     <p>DMM: Digital Multimeter</p>
                     <p>&nbsp;</p>
                     <p>The 34401A is a 6.5 digit DMM that supports measurement of voltage, current, resistance and frequency.</p>
                     <p>Two-wire as well as four-wire measurements are possible.</p>
                     <p>Temperature measurement was special order option and while there are ways to enable it, this driver does not currently support it.</p>
                    """

    def __init__(self):
        
        EmptyDevice.__init__(self)
        
        self.shortname = "Keysight34401A"
        
        self.port_manager = True
        self.port_types = ["COM", "GPIB"]
        
        self.port_properties = { 
                                    "timeout": 10, #needed for 100 NPLC setting as it needs ~5s to compute
                                    "EOL": "\r", 
                                    "baudrate": 9600, # factory default
                                }
                                 
        
        # this dictionary connects modes to commands. The modes will be displayed to the user in the field 'Mode'
        self.modes = {
                        "Voltage DC":   "VOLT:DC",   
                        "Voltage AC":   "VOLT:AC",  
                        "Current DC":   "CURR:DC",  
                        "Current AC":   "CURR:AC", 
                        "2W-Resistance":   "RES",
                        "4W-Resistance":  "FRES",         
                        "Frequency":    "FREQ",    
                        "Period":       "PER",         
                        "Diode":        "DIOD",
                        "Continuity":   "CONT",    
                        
                        }
                     
        # this dictionary sets the unit of each mode
        self.mode_units = {
                        "Voltage DC":   "V", 
                        "Voltage AC":   "V", 
                        "Current DC":   "A", 
                        "Current AC":   "A", 
                        "2W-Resistance":   "Ohm", 
                        "4W-Resistance":   "Ohm", 
                        "Frequency":    "Hz",
                        "Period":       "s",
                        "Continuity":   "", 
                        "Diode":        "",
                        }
          
        # a list of available resolutions as they can be sent to the instrument
        self.resolutions = [
                            "0.1",      # i.e., 100.0 V (3½ digits)
                            "0.01",     # i.e., 10.00 V (3½ digits)
                            "0.001",    # i.e., 1.000 V (3½ digits)
                            "0.0001",   # i.e., 1.0000 V (4½ digits)
                            "0.00001",  # i.e., 1.00000 V (5½ digits)
                            "0.000001", # i.e., 1.000000 V (6½ digits)
                            ]
                 
        # a dictionary of trigger types and their corresponding commands. The trigger types will be shown in the GUI field 'Trigger'
        self.trigger_types =    {
                                "Immediate": "IMM",
                                # "Timer":     "TIM",
                                # "Manual":    "MAN", 
                                "Internal":  "BUS",
                                # "External":  "EXT",
                                }
                                
        self.nplc_types = {
                                "Fast (0.1)"  : 0.1,
                                "Medium (1.0)": 1.0,
                                "Slow (10.0)" : 10.0,
                                "Glacial (100.0)": 100.0,
                            }   
                            
                                
                                                                 
    def set_GUIparameter(self):
        
        GUIparameter = {
                        "Mode" : list(self.modes.keys()),
                        #"Resolution": self.resolutions,
                        # "Range": ["1", "2"],
                        #"Channel": ["%i-%02d" % (S, CH) for S in range(1,3,1) for CH in range(1,11,1)],
                        #"Trigger": list(self.trigger_types.keys()),
                        #"Average": "1",
                        
                        "NPLC": list(self.nplc_types.keys()),
                        "Range": ["Auto"],
                        "Display": ["On", "Off"],
                        }
                        
        return GUIparameter
                                 
    def get_GUIparameter(self, parameter = {}):
    
        #print()
        #print(parameter)
    
        self.mode = parameter['Mode']
        #self.resolution = parameter['Resolution']
        #self.clist = parameter['Channel'].replace(" ", "").replace("-", "").split(",")
        #self.trigger_type = parameter['Trigger']
            
        self.range = parameter['Range']
        self.nplc = parameter['NPLC'].replace("(", "").replace(")", "").split()[-1]
        self.display = parameter['Display']
        
        self.port_string = parameter["Port"]
        
        #average = int(parameter['Average'])            

        # here, the variables and units are defined, based on the selection of the user
        # we have as many variables as channels are selected
        self.variables = [self.mode]  # we add the channel name to each variable, e.g "Voltage DC@1-03"
        
        self.units = [self.mode_units[self.mode]]
            
        self.plottype =  [True]  # True to plot data
        self.savetype =  [True]  # True to save data

                
    def initialize(self):
    
        self.port.write("*IDN?")
        print(self.port.read())
    
        # once at the beginning of the measurement
        self.port.write("*RST")
        
        self.port.write("*CLS") # reset all values
        
        self.port.write("SYST:BEEP:STAT OFF")     # control-Beep off

        ## does not seem to work although it should: results in error -113 undefined header
        #if self.port_string.startswith("COM"):
        #     self.port.write(":SYST:RWL")

    def deinitialize(self):
            
        self.port.write("SYST:BEEP:STAT ON")     # control-Beep on

        ## does not seem to work although it should: results in error -113 undefined header
        #if self.port_string.startswith("COM"):
        #    self.port.write("SYST:LOC")  # RS-232/COM-port only

    def configure(self):
        
        # range = "0"
        # channels = "(@" + ",".join(self.clist) + ")"        
        # print("Channels:", channels)
        
        ## Mode
        self.port.write(":SENS:FUNC \"%s\"" % self.modes[self.mode])
            
        ## Speed
        if not self.mode in ["Voltage AC", "Current AC", "Frequency", "Period", "Diode", "Continuity"]:
            self.port.write(":SENS:%s:NPLC %s" % (self.modes[self.mode], str(self.nplc))) #NPLC only supported in DC Volts, DC Current, 2W- and 4W-Resistance
        
        ## Range
        if not self.mode in ["Frequency", "Period", "Continuity", "Diode"]:
            self.port.write(":SENS:%s:RANG:AUTO ON" % (self.modes[self.mode]))

        ## Display
        if self.display == "Off":
            self.port.write(":DISP 0")
     
    def unconfigure(self):
        if self.display == "Off":
            self.port.write(":DISP 1")  # We switch Display on again if it was switched off
     
            
    def measure(self): 
        self.port.write("READ?")  # triggers a new measurement                      

    def call(self):
        answer = self.port.read()  # here we read the response from the "READ?" request in 'measure'
        #print("Response to READ? command:", answer)

        return [float(answer)] 
        
        
    """
    """

Christian, thanks a lot for this valuable contribution!

I will go through the driver in the next days and upload an official version.

Regarding the state of the driver, we are happy about every driver that works. It is not necessary that a driver fulfills all features the instrument offers as longs as it works and returns reliable data for the supported modes.

Drivers that just implement a minor part of the instrument functionality can still be a big help for others to continue with adding more features later.

So, once the driver works we can definitely make it available as “live” version.

“Glacial” is indeed funny, but I will probably change it to something more boring to not confuse anybody :wink:

I guess I will come back to you on Monday.

Maybe you can start a new topic regarding the COM port issue and we check why the COM ports do not work.

1 Like

Hi Christian,

the server version of the driver “Logger-Keysight_34401A” is now ready for testing. You can download it after login in SweepMe!.

The code can be found here:

I used Keysight as manufacturer name because it was the last one producing this instrument.

Regarding the Speed/NPLC, I used “Very slow”. Currently, the Dropdown menu in the Logger module cannot be configured to be editable. In future, we might change this and then one could evalaute the number in the brackets. I think for now it is a good solution for most users.

Thanks and looking forward to get your ok to make the driver available to everyone.

Axel

1 Like

Hello Axel.

the suggested version seems to work great, thanks a lot. I’ve used it to record the warm-up drift of my Keithley 236 and it tracked flawless over more than one hour. I can use all available functions as well without a fail, so I would call it good enough for a final release.

One thing I noticed: if one happens to use the STOP button just the moment after the READ command was issued over GPIB, the BEEP:ON command of the “de-initialize” procedure will suppress the READ-output of the device which will have it throwing an appropriate error together with a beep (because it receives a new command before the requested measurement result was received). What do you think weights more, the immediate abortion of the running sequence or taking care of any error? If last case, one would have to make sure that STOP is only acting after a measure-procedure is fully completed, including the READ command.

Best wishes,
Christian

1 Like

Thanks for the feedback. I guess you combined it with the Keithley 236 driver and sounds like a nice measurement to track both instruments.

Regarding the STOP issue, I would say that it is always better if SweepMe! stops as fast as possible, e.g. because of safety reasons.

I still need to check and understand better why this is a problem. Normally we don’t see this problem on other instruments when a requested message is not read from the buffer. This could also be specific to the 34401A.

A solution to make sure that reading is done always after requesting data is to move both calls into the same semantic function call in the driver. SweepMe! stops as soon as one of the semantic functions in the driver returns. Thus, it would not return if the driver is still busy with reading.

Splitting the request for data and reading the buffer still has some advantages. With this scheme, you could use a lot of 34401As in parallel and they would be asked for data almost at the same time while reading the data can happen later. If all instrument drivers comply to the same style, one can save a lot of time when using multiple instruments.

Normally, it is rather difficult to exactly match the point between both function calls. However, if you have a Keithley 236 which might take a bit more time to measrure/read the data, it could promote this issue.

1 Like

Thanks a lot Axel for the background informatuon.

In this case, having the option to operate multiple DMM with measurements in consequtive order as fast as possible is vastly more inportant than to provoke an error in the communication protocol. In the end, the chance to hit the protocoll right between the READ command and the retrival of the measurement value is decreased considerably anyway if one chooses more NPLCs per reading as this decreased the time of the forementioned commands with respect to a total measurement cycle. It happend to me only using 0.1NPLCs while trying things out, in which a chance to hit the “sweet spot” appears multiple times per second. Normally, I do not got for less than 1NPLC, usually more like 10 or even 100.

Best wishes,
Christian

1 Like

Hi Christian,

I have now switched the driver version 2024-06-10 to live.

We can maybe solve the remaining issue in future, but at the moment it is not clear to me whether it is a problem of our implementation of the GPIB communication or whether the instrument simply dislikes accepting further comannds if there is still something in the buffer.

If you figure out something we can continue in this direction. For now, I think the driver is in a reasonable good condition to use it productively.

Thanks for making the driver available!

1 Like