No response using PyVISA from instrument on GPIB

Question

I'm trying to control an instrument (very old hall measurement device) on a GPIB with PyVISA. I know it works with labview, where I've found which addresses do what and some basic commands with a tracer but to no joy. I've been asked to write a DAQ and analytical code in python 3.

So far I've been able to identify the addresses:

import visa
rm = visa.ResourceManager()
print(rm.list_resources())
>>>('ASRL1::INSTR', 'GPIB0::3::0::INSTR', 'GPIB0::3::1::INSTR', 'GPIB0::3::3::INSTR', 'GPIB0::3::4::INSTR', 'GPIB0::3::5::INSTR', 'GPIB0::3::6::INSTR', 'GPIB0::3::7::INSTR', 'GPIB0::3::8::INSTR', 'GPIB0::3::9::INSTR', 'GPIB0::3::10::INSTR')

however when I try to query with any "wave" or indeed measurement command string (found tracing labview I/O) I am always met with a timeout error.

instr3_8 = rm.open_resource('GPIB0::3::8::INSTR')
instr3_8.query("*IDN?")
>>>VisaIOError: VI_ERROR_TMO (-1073807339): Timeout expired before operation completed.

This is the result for everything I try to read from the instrument.

(PyVISA and the GPIB work with a Keithley source meter IDN query so I know the backend is working. The instrument is a bio-rad HL 5200 on the off chance that's of use to anyone, I've found no manual and next to no reference online.)

Here's an image of the labview block diagram that reads the magnet position. I've since been able to change the position by writing with pyvisa but reading still gives a timeout, similar issues on github lead me to believe the termination character is wrong but I've no fix yet.

Answer 1

The issue came down to both PyVISA and NI MAX not recognising the termination characters when reading from the instrument. After trying all the possible termination characters with .read_termination I found one that worked can finally read from my hall probe.

Answer 2

Very old GPIB instruments often have incomplete or non-standard implementation of GPIB. For example they can lack support for *IDN?, or have only one hard-coded command termination character.

Some of these old instrument also use address +1 as a 'printer' address. So the instrument reserves the address it is set to, but also the next one. This can be a cause of major confusion specially if there are more (old) instruments on the same network, so it is good idea never to use consequent addresses but go 1, 3, 5, 7 instead.

Also, even just polling the status byte too frequently can overload the processing capabilities of really old instruments, let alone reading the answer buffer.