inst.write("*IDN?")
works (the Keithley 2400 switches to remote controlled mode), and the python console tells me statusCode.success:0
inst.read()
takes a long time to complete (~10-20s) and the result is a string of the form u'KKKKK......KKK' (note the starting "u", not included in the inverted commas, similar to before)
subsequent commands all fail, with statusCode.error timeout:-1073807339
It seems to me the Keithley is sending the first letter of its identity string "K" without pause.
Changing the terminating character
inst.read_termination="\n"
inst.write_termination="\n"
did not help as well
When I do the same in ibtest (with the default read buffer: 1024), it returns the correct instrument name.
After some investigation I found that the library does something analogous to:
char = gpib.read(1)
while char is not read_termination:
char = gpib.read(1)
Sure enough, repeating this pattern in ibtest produces the same result, repeated first character of the read string. It will then finally timeout once the correct number of characters have been read.
I'm not sure if this is a bug in the instrument(s), the driver or pyVisa, but it is curious that the library uses this read pattern; presumably to catch the terminating character without consuming the buffer.
As a workaround I am using gpib.read() on its own.
The reading method has been updated in the development version (whose release is blocked by an issue on TCPIP). Could you try if you observe the same issue using the latest commit on master ?
While using PyVisa-py I found that I was having the same issue as mentioned in: https://github.com/pyvisa/pyvisa/issues/206
When I do the same in ibtest (with the default read buffer: 1024), it returns the correct instrument name. After some investigation I found that the library does something analogous to:
Sure enough, repeating this pattern in ibtest produces the same result, repeated first character of the read string. It will then finally timeout once the correct number of characters have been read. I'm not sure if this is a bug in the instrument(s), the driver or pyVisa, but it is curious that the library uses this read pattern; presumably to catch the terminating character without consuming the buffer.
As a workaround I am using gpib.read() on its own.