Unexplained delay in Python - PyVISA - USB - GPIB - Keithley 2401 Stack

[GoMrPickles]

I am trying to run an IV sweep (sweep voltage, measure current) on a Keithley 2401. I am using Python 3.10, PyVISA, and controlling a Keithley 2401 via USB to GPIB.

This used to "run fine;" then I started seeing occasional random ~17-second delays (in the middle of measurements); now nearly every measurement has an identical ~16.7 second delay.

I am not posting code in order to avoid tripping CloudFlare warnings. I will edit this post if it succeeds.

[GoMrPickles · Accepted solution]

    # Query the identification string
    idn = ksm.query("*IDN?")
    print(f"Successfully communicated with: {idn}")

When trying code as simple as this (where `ksm` is a class corresponding to a Keithley 2401 SMU), we would see random ~17 second delays. Eventually, these delays stopped being random, and occurred with nearly every command we'd send via PyVISA to the Keithley.

I eventually tracked this down to the TNT4882 ASIC in the GPIB-USB adapter. The NI drivers (2025) were settings the bus to high speed; it needed to be normal. Downgrading to the 2020 drivers did not fix it. Setting the bus timing to 2 us in the NI MAX control panel didn't fix it.

Eventually, I (with help) looked at the Linux GPIB drivers, and found the file that talks to this ASIC:

https://github.com/greyltc/linux-gpib/blob/master/drivers/gpib/include/tnt4882_registers.h

What did eventually work was explicitly setting the hex register to the correct value, in Python, every time I instantiate the `ksm` class.

# Force T1 Delay to 2us (Value 1 = Normal/Slow)
# This ensures the ASIC doesn't 'outrun' the Keithley handshake
k.visalib.set_attribute(k.session, 0x3FFF0184, 1)

In the VISA and NI-488.2 standards, the T1 Delay (VI_ATTR_GPIB_T1_DELAY, Attribute 0x3FFF0184) usually maps to specific timing states:

• 1: Normal ($2\mu s$)

• 2: High Speed ($500ns$)

• 3: Ultra High Speed ($350ns$)

• 0: Default/Unconfigured

The Default State (0): In this state, the NI-VISA 2025 layer may allow the hardware to use its fastest possible timing (350ns), which triggers the 16.7-second hardware timer when the Keithley 2401 cannot keep up.

---

By setting the T1 delay within my KSM class in Python, I no longer see this delay.

[Iwa6]

Hello.

Where did it say that 0x3FFF0184 indicates a T1 Delay?
In typical VISA references, this hexadecimal number is assigned to VI_ATTR_GPIB_UNADDR_EN.

[GoMrPickles]

You're right, it is... and I haven't found a specific reference which says that 0x3FFF0184 corresponds to VI_ATTR_GPIB_T1_DELAY. I actually can't find any docs for "VI_ATTR_GPIB_T1_DELAY" now. Either way, setting that hex value to 1 solved a problem that took down one of our tools for a month.

Some further analysis:
I can set 0x3FFF0184 to any value between 0 and 16960; if I try a higher value than 16960, I get a silent error and it falls back to 16960. That should not be possible, if it's a Boolean:
https://www.ni.com/docs/en-US/bundle/ni-visa-api-ref/page/ni-visa-api-ref/vi_attr_gpib_unaddr_en.htm...

Setting the bus timing in NI MAX was not sufficient to fix the error; Google searches now return mostly my own post here. If the error is unrelated to that bus timing, that explains that part.

NI I/O Trace shows that 0x3FFF0184 is VI_ATTR_GPIB_UNADDR_EN. Enabling it forces the controller to unaddress after each transfer. Without it, the Keithley 2401 can leave the bus in a state that causes the TNT ASIC to hit its 2^24 µs timeout (~16.7 s) during the next write. I attached an I/O trace.

Frankly not my area of expertise...