I wouldn't quite call it useless, but it's pretty flaky. I've hacked around most of the issues and I am actually getting good captures with it on my 3458A. The driver definitely needs attention but in the absence of that these are my workarounds:
- First of all, for some reason I can't have the polling of the instrument in a python loop. I tried multiple things, like destroying objects on each iteration etc.. when you keep polling in a loop there is some residual state or a memory leak caused by the driver which causes the USB subsystem to become locked out. You basically get a USB device driver busy after a while and you are no longer able to poll. The workaround for this is to execute a system process each time you poll.. ugly and annoying but this resolved the issue, I haven't had USB device busy since I did that.
process = os.popen('/usr/bin/python ad_hoc_hp3458a.py')
list_returned = process.read().split('\n')
process.close()
return float(list_returned[-2])
That basically executes the following script and converts the second to last line into float.
from ugsimple.GPIB import UGSimpleGPIB
import time
import sys
class Delay(object):
""" introduces a delay into a while loop
with a timeout
"""
def __init__(self):
self.i = 0
self.timeout = 50
def delay(self):
self.i += 1
if self.i == 1:
# no delay on the first run
return self.i
time.sleep(0.1)
if self.i > self.timeout:
sys.exit(1)
return self.i
if __name__ == '__main__':
# Initialize the UGSimpleGPIB USB adapter
# Requires root permissions (or add the udev rule)
mygpib = UGSimpleGPIB(debug_mode=False)
# List Connected Devices
print mygpib.query_devices()
# GPIB address of the device
addy = 22
data = ''
d = Delay()
# sending the command to 3458A
mygpib.write(addy, "TARM AUTO")
# reading from device
while data == '':
print d.delay()
data = mygpib.read(addy)
print 'data: {}'.format(data)
print ('%.08f' % float(data))
The notable change from the example script the python driver ships with is that I discovered that their read() function is non blocking. Which means if the instrument doesn't respond in time the result just gets abandoned. This caused a lot of missed readings in the past, and since I implemented this hack.. I have not missed a single reading.
I do still get occasional syntax errors, but the polling never gets interrupted, and the readings aren't corrupted by it. It is definitely flakey, and your mileage may vary with other instruments I haven't yet tested it with. But it is a workable solution. I am getting useful captures from it.
For instance see an attached 20hour run: