Closed SimplicityGuy closed 8 years ago
So, what in here is actually relevant fixes? Just the hack to skip the rather important configuration set call? I have just done a bit of reworking to add open and close methods as well as only set the configuration if it isn't set to the correct one. Try out the code on my fork and see if it fixes the error you're getting.
Correct, the relevant fix is the optional configuration set call. Please see the reference issue on pyusb where skipping this call is the recommended fix.
I'll try the fork today and report back.
Sent from my iPad
On Dec 30, 2015, at 9:01 PM, Alex Forencich notifications@github.com wrote:
So, what in here is actually relevant fixes? Just the hack to skip the rather important configuration set call? I have just done a bit of reworking to add open and close methods as well as only set the configuration if it isn't set to the correct one. Try out the code on my fork and see if it fixes the error you're getting.
— Reply to this email directly or view it on GitHub.
Sadly the changes in https://github.com/alexforencich/python-usbtmc do not work. I still see the same issue:
[<DEVICE ID 0aad:00e2 on Bus 002 Address 068>]
Traceback (most recent call last):
File "/home/rwlodarc/Code/scratch-projects/powermeter/usbtmc_test.py", line 23, in <module>
rsnrp.open()
File "build/bdist.linux-x86_64/egg/usbtmc/usbtmc.py", line 285, in open
File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 869, in set_configuration
self._ctx.managed_set_configuration(self, configuration)
File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 102, in wrapper
return f(self, *args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 148, in managed_set_configuration
self.backend.set_configuration(self.handle, cfg.bConfigurationValue)
File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 794, in set_configuration
_check(self.lib.libusb_set_configuration(dev_handle.handle, config_value))
File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 595, in _check
raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno 16] Resource busy
FWIW, this is a Rohde & Schwarz NRP8S. Documentation states that that it is usbtmc
compliant, and in fact when I remove the call to set_configuration
, my test app works without issues.
[<DEVICE ID 0aad:00e2 on Bus 002 Address 069>]
Trying command: *IDN?
Results: ROHDE&SCHWARZ,NRP8S,<REDACTED>,15.10.27.01
Waiting 1s for next command... None
Trying command: SYSTem:INFO?
Results: "Manufacturer:Rohde & Schwarz
Type:NRP8S
Stock Number:<REDACTED>
Serial:<REDACTED>
SW Build:15.10.27.01
Sensor Name:NRP8S-<REDACTED>
Technology:3-Path Diode
Function:Power Terminating
MinPower:1e-10
MaxPower:0.2
MinFreq:1e+07
MaxFreq:8e+09
Resolution:5e-07
Impedance:50
Coupling:AC
Cal. Misc.:2015-11-23
Cal. Abs.:2015-11-23
Cal. Refl.:2015-11-23
Cal. Temp.:not applicable
Cal. Lin.:not applicable
Cal. S-Para.:not applicable
Cal. S-Para. (User):not applicable
SPD Mnemonic:
Cal. Due Date:2017-11
TestLimit:0.160 dB
TestLimit pd:0.160 dB
Uptime:22
"
Waiting 1s for next command... None
Trying command: SENSe:POWer:AVG:APERture?
Results: 2.000000E-02
Waiting 1s for next command... None
Trying command: SYSTem:LED:COLor #HA000A0
Results:
Waiting 1s for next command... None
Trying command: ['*RST', 'INIT:CONT ON']
Results:
Waiting 1s for next command... None
Trying command: FETCh?
Results: 7.859090E-12
Waiting 1s for next command... None
Alright, let's try that one more time. I think the check I had before didn't quite work right. Updated my fork; let me know if it solves this issue.
Just pushed some more updates. I'm pretty sure it won't try to set the configuration unless absolutely necessary, so give it a shot and let me know if there are any issues.
The changes look promising, but still don't produce the same results as with the changes I had:
[<DEVICE ID 0aad:00e2 on Bus 002 Address 074>]
Trying command: *IDN?
Results: ROHDE&SCHWARZ,NRP8S,<REDACTED>,15.10.27.01
Waiting 1s for next command... None
Trying command: SYSTem:INFO?
{'command': 'SYSTem:INFO?', 'type': 'q'} failed with unpack_from requires a buffer of at least 4 bytes
Trying command: SENSe:POWer:AVG:APERture?
Results: :0.160 dB
TestLimit pd:0.160 dB
Uptime:62
"
Waiting 1s for next command... None
Trying command: SYSTem:LED:COLor #HA000A0
Results:
Waiting 1s for next command... None
Trying command: ['*RST', 'INIT:CONT ON']
Results:
Waiting 1s for next command... None
Trying command: FETCh?
Results: 2.000000E-02
Waiting 1s for next command... None
Hmm. Can you post a traceback for that unpack_from error?
Yes, sorry about that.
Trying command: SYSTem:INFO?
Traceback (most recent call last):
File "/home/rwlodarc/Code/scratch-projects/powermeter/usbtmc_test.py", line 44, in <module>
results = rsnrp.ask(cmd['command'])
File "build/bdist.linux-x86_64/egg/usbtmc/usbtmc.py", line 572, in ask
File "build/bdist.linux-x86_64/egg/usbtmc/usbtmc.py", line 555, in read
File "build/bdist.linux-x86_64/egg/usbtmc/usbtmc.py", line 511, in read_raw
File "build/bdist.linux-x86_64/egg/usbtmc/usbtmc.py", line 456, in unpack_dev_dep_resp_header
File "build/bdist.linux-x86_64/egg/usbtmc/usbtmc.py", line 452, in unpack_bulk_in_header
struct.error: unpack_from requires a buffer of at least 4 bytes
Ahh, I think I might know what the problem is. Trailing zeros could be getting left in the endpoint buffer. Can you replace line 509 of usbtmc.py with
resp = self.bulk_in_ep.read(read_len+USBTMC_HEADER_SIZE+3, timeout = self.timeout)
and try again?
Perfect! That worked!
Would you mind bumping the version to 0.7 please? (with this fix in as well)
Will do. Just wanted to get this fixed first.
OK, just pushed that change. Try it one more time and let me know how it works. If it looks good, I will bump the version and push it to the main ivi repo.
Looks great! Thank you for getting this fixed!
No problem! The code definitely needed some clean-up; I think it's a lot more robust now. Anyway, the new version is now on pypi here: https://pypi.python.org/pypi/python-usbtmc/0.7 .