SMU driver have extension

Hello,
I am developing a driver for the Keithley 248 SMU and controlling it via GPIB. However, after a few seconds, the program stops and returns an error. What would be the best approach to diagnose and resolve this issue?

Thank you!

1 Like

Hi,

this could be a very good test case for our SweepMe! Driver Writer AI where you could upload the programming pdf and also add debug messages like your timeout error:

In general, a timeout error is related to a message that is not processed or returned by the instrument. So, either the instrument does not understand your command or SweepMe! does not understand the answer. Both will lead to the fact that no message is received within the given timeout duration.

Please have a look at our Wiki and the article about the Port manager
https://wiki.sweep-me.net/wiki/Port_manager
that is used to handle the communication with standard port types like GPIB, USBTMC, COM port (virtual COM port/RS-232/RS-485), or TCPIP.

The most common problem is the correct definition of the terminator character that tells the instrument but also SweepMe! when a message ends and can be interpreted. Furthermore, the timeout duration must be long enough. If an instrument needs some seconds to acquire a result, the timeout must be adadpted accordingly.

If this does not help, try to connect to the instrument with a different tool like NI MAX that comes with the installation of the NI VISA runtime. It can be used to send single commands to an instrument and read the response. It might help to see whether your instrument works at all and whether some port properties need to be changed.

Here, it could be that the instrument also need to be configured to work with GPIB. Maybe there is a menu setting that can be used to switch to GPIB communication.

A good resource is also the troublshooting guide for GPIB that you can find here:
https://wiki.sweep-me.net/wiki/Supported_ports

If you need professional support with creating a driver, please let us know and we can help you with the creation of the driver. Otherwise, we would be also happy to hear here if you have been able to make any progress.

Best, Axel

Thank you,
I tried AI tool and got a few promising suggestions. Interestingly, the error occurs at varying times after starting Sweepme. Usually, the error occurs at the same line of code, and it is straightforward to resolve. I think will be able to fix the issue.

Cheers,
Fran Zupet

1 Like

Hi Fran,

The Keithley 248 seems to be a bit older model and they often had problems when you send commands too quickly.

Try to add a “delay” to self.port_properties of ~0.05 to 0.1 s.
SweepMe!'s port manager will then wait this time before sending the next command, giving the instrument time to interprete and handle the previous command.

Such a missing delay could explain a random hickup of the instrument.

If the driver works, consider to contribute it. We can do a final check and make it available as an official server version.

Best, Axel

Hi Alex,

It seems that was indeed the problem. I’ve been testing it for 10 minutes with the delays, as the AI bot suggested, and everything is working great now.

def measure(self):
    if self.value % 10 == 0:
        
        time.sleep(0.1)
        self.port.write("VOUT?")
        time.sleep(0.5)
        voltage = self.port.read()
        print(f"Voltage Output: {voltage}")
        
        time.sleep(0.1)
        self.port.write("IOUT?")
        time.sleep(0.5)
        current = self.port.read()
        print(f"Current Output: {current}")

Thank you,
Fran Zupet

1 Like

Great to hear that the Driver Writer AI was already able to help here. We will further fine-tune it and happy to receive any feedback during your further testing. Feel free to create new topics then.

Best, Axel

1 Like

To add the delay by default (omitting time.sleep(…)) you can use

self.port_properties = {
    "baudrate" : 9600,  
    "EOL": "\n",
    "delay": 0.1,
}

Not sure whether baudrate and EOL are correct for the Keithley 248, just to show how to add the “delay” property. It will then automatically be ensured that two consecutive self.port.write are separated by at least the given value in time.

1 Like

Thanks! I didn’t even think about the boudrate. Making it this way will definitely make the communication more stabile and prevent overloading the bus.

oops, my fault, baudrate is only relevant for COM/RS-232 communication (if it supported by the Keithley 248). It will not make a difference for GPIB.

1 Like

A ok, otherwise it runs for almost 30 minutes without problems.

1 Like

I will go to UNI now and come back at 18:00 to see if it works.