Usb device fixes#205
Usb device fixes#205jayich wants to merge 7 commits intolabrad:masterfrom CampbellGroup:USB_device_fixes
Conversation
…SB devices we have tested, a Rigol DG1022 and an Agilent DSO1024A. If other devices require adding '::INSTR' perhaps parsing addr for an ending '::INSTR' would be a solution.
…SO1024A, that we could not get proper communication without an asynchronous wait. If there is a better solution for this problem, we would be happy to implement.
There was a problem hiding this comment.
didn't know you could pass a tuple to startswith. nice.
…nchornous_wait. Works with a pair of 'USB' GPIB devices.
|
I think this is a hack, it's kind of annoying that a specific device server should have to have some write/read delay when in principle should have some standardized protocol that the GPIB server deals with. I would chalk this up to one poor device but now there is both a Rigol signal generator and some Agilent thing @jayich uses that hangs on GPIB reads |
|
I think the GPIB server should at least timeout instead of hanging on a bad read operation |
…ss syntax returned by a specific instrument.
|
@aransfor, the server is supposed to time out. By default the read timeout is just 1 second, but you can set this per context, if you want to do something for a particular device. I think the |
Need to increase the wait time to give the device a chance to respond.
Eliminated an unnecessary str conversion.
We implemented a couple of changes (described in the commits) to get our only two 'USB' GPIB devices working.
We have found that when using the latest pyvisa that '::INSTR' is included.
We also have had problems with devices needing some time between write and read. This solution looks like a hack. If you guys have a better solution that would be great.
Credit to @aransfor and @gregllong for both of these fixes.