I have a situation where I would like to identify and open a U6 based on where it is on the USB bus.
We use Ubuntu Linux, and with other devices (like serial ports) we identify them by where they are on the USB bus, using udev rules. This allow us to know what is connected where. The nice think about this method is we can build multipls of the same configuration of devices and the software just works. No configuration necessary.
With the U6, I can not seem to figure out if this is possible.
- Opening by serial number will not work because each device will be different (and there for require some configuration per setup),
- There is the local ID, but I can not tell if that is any way predicitable/consistant from one boot/powerup of the system and will it change when something new is introduced, like a keyboard or USB drive.
Any thoughts or suggestions on how I can accomplish this?
Thanks,
John
We do not provide software or a driver to open devices indicated by bus.
Ways to identity a specific U6 are:
1. By serial number, which is a unique value and not user defined
2. Local ID, which is user defined value (ConfigU6). Default value is 1.
Both of these identifiers are stored on the U6 flash, so U6s on the system need to be opened and identifiers checked to determine if that is the desired device. In our examples, our openUSBConnection function in u6.c returns a handle to the device based on serial number or local ID.
https://github.com/labjack/exodriver/blob/master/examples/U6/u6.c#L119
Exodriver is open source and can be customized. Our udev rules are in the 90-labjack.rules files which gets installed to the system with the install script. Looking at libusb-1.0 functions, which Exodriver uses, there is a libusb_get_bus_number function gets the bus number when going through. You can modify our rules file for a specific bus and the Exodriver LJUSB_OpenDevice function to check for the bus how you want.
Thanks for your reply,
I have suspected that this was the answer, and have started looking into what libusb provides and how I could patch both the exodriver and python to meet our needs (Thank you for choosing opensource for these drivers BTW).
I think I may be able to accomplish what I need with a combination of udev rules and and a small patch to the exodriver and python wrappers.
Are you open to pull requests if I come up with somehting that is of more general use?
Thanks
I believe we would welcome such a pull request, but we would be very unlikely to adopt anything that breaks backwards API compatibility. Do you have a API in mind?