# 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:
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.
