Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Usb device fixes #205

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

Usb device fixes #205

wants to merge 7 commits into from

Conversation

jayich
Copy link
Member

@jayich jayich commented Jul 17, 2015

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.

>>> import visa
>>> visa.__version__
'1.7'
>>> rm = visa.ResourceManager()
>>> rm.list_resources()
....

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.

jayich added 2 commits July 16, 2015 16:53
…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.
instName = addr + '::INSTR'
else:
device_prefixes = ('GPIB', 'USB', 'TCPIP')
if not (addr.startswith(device_prefixes)):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

didn't know you could pass a tuple to startswith. nice.

@aransfor
Copy link

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

@aransfor
Copy link

I think the GPIB server should at least timeout instead of hanging on a bad read operation

…ss syntax returned by a specific instrument.
@maffoo
Copy link
Contributor

maffoo commented Jul 17, 2015

@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 read and read_raw methods might behave differently in this regard, however, so that could be the issue, because I see that the new USB code uses read.

jayich added 2 commits July 16, 2015 21:32
Need to increase the wait time to give the device a chance to respond.
Eliminated an unnecessary str conversion.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants