PyVISA-Py: USB backend issue value error operation timed out #256
Comments
|
Did you properly set the write_termination and read_termination ? To check that the write_termination is correct try sending a command modifying the state of the instrument and check visially that it worked. |
|
can you elaborate on how that can be done |
this is what i get:
|
|
Even write commands are not working. |
|
The manual of the instrument should specify what is the expected termination of a message when writing and reading (line feed \n, carriage return \r, both, something else...). keysight.write_termination = '\r\n'
keysight.read_termination = '\r\n |
|
I tried all possible combinations : \n, \r, \r\n, \f |
|
Can you communicate using NIMax ? I noticed you are using the py backend which is not yet super stable, so if you can try first to use the ni backend. |
|
actually NI VISA library is not available for my Linux version |
|
Has this issue been solved. I am trying to connect a raspberry pi to a keysight 33511B function generator. I have tried writing a udev rule (as explained here: #3) and that didn't work. Seems like there is a common trend with Keysight (Agilent) instruments as it is here as well: #71. Trying to change the termination character also didn't work for me. You said the teledyne lecroy waveform generator worked quite well? |
|
Not to my knowledge but apparrently python-ivi usbtmc works so it might be worth giving it a look and use it to update the current implementation. Do you want to try ? Otherwise I might have some time this week but I cannot make any promise. |
|
I have tried today and the instrument now receives commands. part of the problem may have been the an incorrect group/user for the udev rules which i made sure to follow the instructions on the usbtmc repo: https://github.com/python-ivi/python-usbtmc However I get errors for some of the scpi commands i send. But that could be due to sending incorrect commands. i am gonna try and check the error messages in the function generator to see whats going on. Thank you for pointing me in the right direction 👍 |
|
It may be worth adding a note in the docs about the configuration of the udev. At least a note pointing to python-usbtmc. Could you do a PR updating the docs ? |
|
Yup. I can provide a link to usbtmc and another link to explain creating user groups etc. with a small explanation of what information is where. Would it be best to create a new doc just for explaining udev rules? |
|
To be clear only the usbtmc library worked. Not pyvisa. I still get a timeout error |
|
Interesting in that case it is still worth investigating on the Pyvisa side. I may have some time to give a look tomorrow but in the meantime a PR about udev would still be meaningful so please go ahead with the doc PR. |
|
Ideally the PR should be against pyvisa-py. I had no time to actually dive into the differences between pyvisa and python-usbtmc but it looks like python-usbtmc has a number of safeguards against instruments not behaving as expected, so it is probably really worth trying to adapt it here. |
|
I am also experiencing this issue with the Tektronix MSO3014 oscilloscope using the pyvisa library. Have you investigated any further on this end? |
MatthieuDartiailh
changed the title
|
I'm new to this so take my answer with a grain of salt, but I also had a problem with the "Operation timed out" error when using the Tektronix MSO3014 with pyvisa. I fixed it by installing the MSO3000(etc.) IVI driver v1.4 from the Tektronix website: https://www.tek.com/oscilloscope/dpo2002-software and following the installation instructions. Hopefully, that will help? If you need more information, please let me know what I should provide - I'm a novice. |
|
Same problem with Keysight B2911A SMU on Linux and these versions: Any attempt to write to the device would result in What worked for me: installing the full Keysight IO Libraries Suite 2020 (for Linux) (bit of a hassle, requires a specific kernel version) and explicitly instantiating |
|
Having the same issue with an Agilent (Keysight) 33521A but only after updating the firmware from v1.14 to v5.02, so that may be a clue. Times out on write and query operations for all combinations of termination characters ('\r', '\r\n', '\n') Edited to add: everything still works fine from my windows device using the NI backend. My pyvisa info:
|
|
Hi, same issue with Agilent u3606a. |
|
Please update to the latest pyvisa and pyvisa-py versions and report the exact error you see (since sometimes there are slight variations between systems). |
|
Min example with latest version of system (clean environment): Minimal example code Output/Error: |
|
Can you try to read just a single byte of the answer ? I would like to know if reading fail altogether or if we have a termination issue. import pyvisa as visa
rm = visa.ResourceManager()
m = rm.open_resource('USB0::2391::19736::MY50099047::0::INSTR')
m.write_termination = '\n'
m.read_termination = '\n'
m.write('*IDN?')
while True:
print(m.read_bytes(1)) |
|
This is the output to your code: |
|
Nothing printed before the error message ? |
|
No, that is all the output |
|
Can you try a command that would produce a visible change in the instrument state ? We need to figure out if we cannot read the answer or if the instrument is not answering because it did not properly receive the message. |
|
Do you see the mode changing on the instrument ? If you send |
|
Unfortunately I am not at the lab. Will check it tomorrow. (Sorry about the inconvenience) |
|
No problem. Debugging those kind of issues is always a pain and I would really like to make pyvisa-py better but I do not have that much open-source time those days. |
|
Hi @MatthieuDartiailh , After a few hard-resets on the device: write works (I can see it controlling the instrument, though the ERROR REMOTE appears in the display. Also, query works but the same ERROR Remote message appears in the display. |
Produces: |
|
This is the point where things get really complicated... I am still confused by how some USB devices works flawlessly while some other like your cannot behave properly. If you want to keep digging, try to use Wireshark to spy on the transferred data using PyVISA-py and possibly using NI or Keysight implementation if you can install it. There must be something different. I will try to go again through the code and the USBTMC specification and see if we missed anything but it may take me some time. |
|
I will try to sniff it, though due to the actual circumstances I will not be able to access physically the instrument everyday. In any case, thanks a lot for your support and all the work you put on the project. |
|
You are welcome and I am sorry I cannot offer you a better solution. |
|
Hi @MatthieuDartiailh can you tell me what traces you need from wireshark? thanks! |
|
Ideally I would like to see everything from the opening of the instrument till the error. And if you can get the same in a working environment that would be great since I could compare both. |
|
Hi Matthieu,
I am not sure if the attachment will help with this issue. I captured
some traces, that I think were for this issue in November 2019.
However, I did not get to discuss it before the contract that was using
the Signal Generator ended in January 2020.
The traces might be too old with an old version of pyvisa-py.
I think there are traces of the error with pyvisa-py and no problems
with usbtmc.
Hope it helps and is not a distraction with it simply being too old,
Michael Wilkinson
Compute Thing Limited
…On Mon, 2021-03-01 at 05:41 -0800, Matthieu Dartiailh wrote:
Ideally I would like to see everything from the opening of the
instrument till the error. And if you can get the same in a working
environment that would be great since I could compare both.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Hi Matthieu, just send you an email with the traces. |
|
Thanks. However I cannot give you a timeline for this. I am a bit overwhelmed at the moment. |
|
Of course, and thanks again for your time! |
|
Maybe this helps: python-ivi/python-usbtmc#50 |
|
Thanks for sharing @ferdymercury .I honestly do not remember of I did such changes for pyvisa-py I have a vague recollection but I am not sure. Could you make a PR ? I am a bit under water at the moment. |
|
We are also running into this issue with a Keysight 33500B Series waveform generator. Has there been farther work on this? Is there anything we can do to help. Using python-usbtmc has no problems. I took a look at the python-usbtmc fix but have no idea what the heck they are doing. |
|
The problem seems to lie with these two lines: C/P here for clarity: Commenting out both of them and the timeout error disappears with the 33500B. We tested with a Keysight DMM and don't see a problem there either. If you comment out just the reset, then you get a resource busy error. If you comment out just set_configuration, you get the time out error again. You must comment out both. I have no idea what this impacts, but from reading some libusb docs, they say: I am not sure if this has anything to do with it? Maybe resetting and then trying to set configuration is going out of order. You don't reset, but set_configuration is already called once in the USBRAW class init, which USBTMC class calls I am going to test with a non-Keysight device and see if anything weird happens |
|
I must say I have no time for PyVISA beyond answering to people issues. If you can figure out how to at least mitigate this issue I will happily review a PR. It is perfectly possible that the logic got messed up at one point when refactoring those two classes and that a lack of deep enough understanding of libusb caused the issue. If you do make a PR, please add that kind of information as comment so that we do not regress in the future. |
|
Ok, let me do some additional testing with non-Keysight devices and see if any weird problems occur with commenting out those two lines. If things look good, I will create a PR for this problem. |
|
Sorry to barge in this issue, but if it helps, I was having a very similar issue with a Tektronix oscilloscope (TBS1062). Just commenting out those two lines did not work, but if I also comment lines 216 and 221 (actually, the entire try/except blocks), it worked fine, and no problem was observed with other instruments from other manufacturers. Line 221 was: It seems there is some kind of issue with the configuration settings and some very specific instruments. |
|
Thanks for your input @pfjarschel . More feedback is always welcome. Looking a bit at different things related libusb, it looks like we could avoid the situation you describe by calling set altsetting only if the interface has multiple settings which we can check. Since you have hardware available to test, could you make a PR or alternatively test one if I can find some time to make one ? |
|
Sorry for the silence, we have been swamped at work and couldn't work on this any further. Some added testing revealed this:
This works for the Keysight/Agilent Function generators, but won't work on our Tektronix MSO44 scope. Will cause a timeout error, but if we uncomment and revert the code back to the original, the timeout error goes away, but the Keysight timeout problem returns. When we get time we can look into @pfjarschel 's fix as well when we have time. |
|
Sorry, I didn't mean to blame you. I have often seen cases of people disappearing, so I just took the opportunity to have more people on board. I think that setting the alt setting only when relevant as done here https://github.com/google/gousb/pull/38/files may really help. It is great you have two instruments to test this way; we may get a good fix rather than moving the issue around some more. |
|
Hi, sorry for "disappearing" as well! Edit: Turns out the oscilloscope in question was moved to another lab, and I won't have access to it for a while. |
|
Hi all. I'm seeing the same issue (ubuntu 20.04, 5.17.1-t2, with pyvisa version 1.10.1, keysight 33500B function generator, shows up as 'USB0::2391::11271::MY52815099::0::INSTR' in list_resources. "ValueError: [Errno 110] Operation timed out" on write, regardless of which write_termination is used). Is there a fix or at least a workaround to this yet?
2022-08-05 edit: re-download the zip, re-edit lines 291/292 (and adding a unique "print" so i can see if we're running the new or old code), running "sudo python3 setup.py install", it looks like some of the issues before were warnings (not critical errors), and it appears to be working. This doesn't resolve the "some devices need these lines commented, others need them uncommented" issue, but at least I was able to get it installed. |
My software details for VISA are:
Machine Details:
Platform ID: Linux-4.4.0-28-generic-x86_64-with-Ubuntu-16.04-xenial
Processor: x86_64
Python:
Implementation: CPython
Executable: /usr/bin/python
Version: 2.7.11+
Compiler: GCC 5.3.1 20160413
Bits: 64bit
Build: Apr 17 2016 14:00:29 (#default)
Unicode: UCS4
PyVISA Version: 1.8
Backends:
ni:
Version: 1.8 (bundled with PyVISA)
Binary library: Not found
py:
Version: 0.3.dev0
ASRL INSTR:
Please install PySerial to use this resource type.
No module named serial
TCPIP INSTR: Available
USB RAW: Available via PyUSB (1.0.0). Backend: libusb1
USB INSTR: Available via PyUSB (1.0.0). Backend: libusb1
GPIB INSTR:
Please install linux-gpib to use this resource type.
No module named gpib
TCPIP SOCKET: Available
I am using py visa to connect to a Keysight 33500B Series waveform generator.I have already successfully used python VISA to connect to Tektronix oscilloscope as well as Teledyne LeCroy Waveform generator..But with Keysight I get an operation time out error on any query or write function..This is the what my input output session looks like:
The text was updated successfully, but these errors were encountered: