IOCreatePlugInInterfaceForService in attach sometimes fails before reaching the right device.
Specifically, I get kIOReturnNoResources. Better to skip here instead of failing the whole loop.
Hi,
Thanks for your very valuable feedback! I've never encountered such issue yet but I don't really like how I've built the code on this area. I'm thinking on a clever way to reenumerate the usb port once the FW has been downloaded without requesting for a new ressource.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I’ve not been able to do a lot today but could you please try this version? I’ve just changed the way the object is destroyed, but I’ve not been able to test yet. I’ll definitely have more time tomorrow.
In order to compile the code, xcode needs to have command tools line installed.
Also ARC must be activated. I'll add a project file soone in the project.
Thank you. I’m not seeing a difference with that dylib (except for the version number):
$ python gpibtest.py
macosx_gpib_lib version 1.0.4a Copyright (C) 2018 by Guilhem Vavelin
This program comes with ABSOLUTELY NO WARRANTY;
This is free software, and you are welcome to redistribute it under the
terms of the GNU General Public License as published by the Free Software
Foundation version 2; email:guileukow@users.sourceforge.net
Assertion failed: (kr == kIOReturnSuccess), function -[agilent_82357_ab attach], file /Users/guilhem/Tech/macosx_gpib_lib/macosx_gpib_lib/Agilent_82357_AB.m, line 1152.
Abort trap: 6
Here is (part of) the output of a quick test program I whipped together for doing the enumeration:
$ ./x
vid = 0x05ac pid = 0x8007 [success]
vid = 0x05ac pid = 0x8007
vid = 0x05ac pid = 0x8007
vid = 0x05ac pid = 0x8007
vid = 0x05ac pid = 0x8007
Plugin -536870210 [kIOReturnNoResources]
vid = 0x0bc2 pid = 0xab28 [success again…]
vid = 0x1e91 pid = 0x4001
vid = 0x2109 pid = 0x0812
vid = 0x2109 pid = 0x2812
vid = 0x043e pid = 0x9a46
vid = 0x14cd pid = 0x8601
vid = 0x1a40 pid = 0x0101
vid = 0x0957 pid = 0x0518
(It goes on after that — I have some 25 devices on USB, but the last line in the excerpt here is the Agilent 82357B.)
So I don’t think your code causes the kIOReturnNoResources. If that assumption is true, you don’t need to try fixing that from happening — you just have to be robust against that happening. (Probably with some unrelated device, anyway.)
Just to check the USB connection, I tried loading the firmware. This seems to work (with the usual two attempts), except that I seem to need wait several seconds between (!?) attempts. Trying too quickly:
I’ve not been able to do a lot today but could you please try this version? I’ve just changed the way the object is destroyed, but I’ve not been able to test yet. I’ll definitely have more time tomorrow.
In order to compile the code, xcode needs to have command tools line installed.
Also ARC must be activated. I'll add a project file soone in the project.
Thanks
Attachments:
• libmacosx_gpib_lib.dylib (288.3 kB; application/octet-stream) [tickets:#2] IOCreatePlugInInterfaceForService sometimes fails
Status: open
Milestone: 1.0
Created: Sat May 12, 2018 03:33 PM UTC by Carsten Bormann
Last Updated: Sun May 13, 2018 11:35 AM UTC
Owner: nobody
IOCreatePlugInInterfaceForService in attach sometimes fails before reaching the right device.
Specifically, I get kIOReturnNoResources. Better to skip here instead of failing the whole loop.
Hi,
Thanks for these details! Indeed, I've never tested my code with such number of usb devices connected (I probably have 2 or 3 usb devices, not 25, that's really impressive).
As you said, I don't think my code is causing the error, but I'm a bit puzzled as it should release the ressources before opening it again, and thus one ressource should always be available. That means that there is a case when the ressource is not released in time.
As you suggested I can try to not exit the loop when the error is happening and continue to check.
Regarding to the time needed to load the 82357B I'm not sure to follow. In my code I'm waiting 4 seconds each timeto ensure the FW is loaded correctly.
Cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Carsten,
I was wondering if you managed to find time to try out the latest version I did or if you had a code to propose? Maybe I'll role this release out then.
Thank you!
Guilhem
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your feedback Carsten! I didn't realize that it wasn't working at all for you.
The time needed for me to test and I'll submit this release then!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Thanks for your very valuable feedback! I've never encountered such issue yet but I don't really like how I've built the code on this area. I'm thinking on a clever way to reenumerate the usb port once the FW has been downloaded without requesting for a new ressource.
Great! Since I can't compile the dylib yet (no xcodeproj), maybe you can push a workaround before doing the greater changes?
Hi,
I’ve not been able to do a lot today but could you please try this version? I’ve just changed the way the object is destroyed, but I’ve not been able to test yet. I’ll definitely have more time tomorrow.
In order to compile the code, xcode needs to have command tools line installed.
Also ARC must be activated. I'll add a project file soone in the project.
Thanks
Thank you. I’m not seeing a difference with that dylib (except for the version number):
$ python gpibtest.py
macosx_gpib_lib version 1.0.4a Copyright (C) 2018 by Guilhem Vavelin
This program comes with ABSOLUTELY NO WARRANTY;
This is free software, and you are welcome to redistribute it under the
terms of the GNU General Public License as published by the Free Software
Foundation version 2; email:guileukow@users.sourceforge.net
Assertion failed: (kr == kIOReturnSuccess), function -[agilent_82357_ab attach], file /Users/guilhem/Tech/macosx_gpib_lib/macosx_gpib_lib/Agilent_82357_AB.m, line 1152.
Abort trap: 6
Here is (part of) the output of a quick test program I whipped together for doing the enumeration:
$ ./x
vid = 0x05ac pid = 0x8007 [success]
vid = 0x05ac pid = 0x8007
vid = 0x05ac pid = 0x8007
vid = 0x05ac pid = 0x8007
vid = 0x05ac pid = 0x8007
Plugin -536870210 [kIOReturnNoResources]
vid = 0x0bc2 pid = 0xab28 [success again…]
vid = 0x1e91 pid = 0x4001
vid = 0x2109 pid = 0x0812
vid = 0x2109 pid = 0x2812
vid = 0x043e pid = 0x9a46
vid = 0x14cd pid = 0x8601
vid = 0x1a40 pid = 0x0101
vid = 0x0957 pid = 0x0518
(It goes on after that — I have some 25 devices on USB, but the last line in the excerpt here is the Agilent 82357B.)
So I don’t think your code causes the kIOReturnNoResources. If that assumption is true, you don’t need to try fixing that from happening — you just have to be robust against that happening. (Probably with some unrelated device, anyway.)
Just to check the USB connection, I tried loading the firmware. This seems to work (with the usual two attempts), except that I seem to need wait several seconds between (!?) attempts. Trying too quickly:
$ fxload-osx -t fx2 -I measat_releaseX1.8.hex -D 0x0957:0x0518
$ fxload-osx -t fx2 -I measat_releaseX1.8.hex -D 0x0957:0x0518
2018-05-13 20:44:14.787 fxload-osx[29224:3748733] Couldn't find USB device with 957:518
$ fxload-osx -t fx2 -I measat_releaseX1.8.hex -D 0x0957:0x0518
(Here the additional LEDs turn on, and any further attempts lead to:)
$ fxload-osx -t fx2 -I measat_releaseX1.8.hex -D 0x0957:0x0518
2018-05-13 20:44:17.597 fxload-osx[29235:3748794] Couldn't find USB device with 957:518
$ fxload-osx -t fx2 -I measat_releaseX1.8.hex -D 0x0957:0x0518
2018-05-13 20:44:22.286 fxload-osx[29251:3749054] Couldn’t find USB device with 957:518
Visualizing this some more:
$ fxload-osx -t fx2 -I /Users/cabo/Downloads/macosx_gpib_lib_1/measat_releaseX1.8.hex -D 0x0957:0x0518; ./x | grep 957
vid = 0x0957 pid = 0x0518
$ fxload-osx -t fx2 -I /Users/cabo/Downloads/macosx_gpib_lib_1/measat_releaseX1.8.hex -D 0x0957:0x0518; ./x | grep 957
2018-05-13 20:48:46.831 fxload-osx[29330:3755300] Couldn’t find USB device with 957:518
[note that the device doesn’t seem to enumerate at all? Probably while reloading…]
$ fxload-osx -t fx2 -I /Users/cabo/Downloads/macosx_gpib_lib_1/measat_releaseX1.8.hex -D 0x0957:0x0518; ./x | grep 957
vid = 0x0957 pid = 0x0518
$ fxload-osx -t fx2 -I /Users/cabo/Downloads/macosx_gpib_lib_1/measat_releaseX1.8.hex -D 0x0957:0x0518; ./x | grep 957
2018-05-13 20:48:58.986 fxload-osx[29354:3755852] Couldn't find USB device with 957:518
vid = 0x0957 pid = 0x0718
[finally…]
Doing this very leisurely, two attempts suffice:
$ fxload-osx -t fx2 -I /Users/cabo/Downloads/macosx_gpib_lib_1/measat_releaseX1.8.hex -D 0x0957:0x0518; ./x | grep 957
vid = 0x0957 pid = 0x0518
$ ./x | grep 957
vid = 0x0957 pid = 0x0518
[stays 518]
$ fxload-osx -t fx2 -I /Users/cabo/Downloads/macosx_gpib_lib_1/measat_releaseX1.8.hex -D 0x0957:0x0518; ./x | grep 957
vid = 0x0957 pid = 0x0518
[still 518]
$ ./x | grep 957
vid = 0x0957 pid = 0x0718
[after a short while, 718]
Grüße, Carsten
Related
Tickets: #2
Hi,
Thanks for these details! Indeed, I've never tested my code with such number of usb devices connected (I probably have 2 or 3 usb devices, not 25, that's really impressive).
As you said, I don't think my code is causing the error, but I'm a bit puzzled as it should release the ressources before opening it again, and thus one ressource should always be available. That means that there is a case when the ressource is not released in time.
As you suggested I can try to not exit the loop when the error is happening and continue to check.
Regarding to the time needed to load the 82357B I'm not sure to follow. In my code I'm waiting 4 seconds each timeto ensure the FW is loaded correctly.
Cheers
Hello,
I've implemented a quick workaround, could you test it please?
Thank you
Hi Carsten,
I was wondering if you managed to find time to try out the latest version I did or if you had a code to propose? Maybe I'll role this release out then.
Thank you!
Guilhem
Yes, that workaround gets much further. I haven't actually tested talking to my device yet, but at least things are not erroring out right away.
Indeed, got a
*IDN
from my device. Now need to do some actual testing.Thanks for your feedback Carsten! I didn't realize that it wasn't working at all for you.
The time needed for me to test and I'll submit this release then!