USB Nugget 3 of n: Unifying the multitude of USB driver Subsystems

[Intaris]

So here we are for another little USB Nugget.

A lot of time has passed since the last one and also a lot of work has gone into this post (or the VIs being attached).

During my other Nuggets I have become less than enamoured with the VISA interface to the USB bus.  I find some of the terminology rather confusing and the lack of examples doesn't help either.  There have also been an increase in questions in the forum regarding HID USB communication and the like.

Having recently (timeframe 2 years ago) goten "into" LVOOP, I thought developing a LVOOP framework for USB communications would be a beneficial thing to do.  The ability to have different classes of devices (or device requeasts) inherit from one another coupled with the ability to have "hot-swappable" USB subsystems drivers via object componsition made me want to write such a software.  Well I did, and here it is in it's completely unfinished glory.  This software has become a bit of a nightmare for me.  I see that it could very well have a use for the community but I've invested a lot into it to make it work so I'm a bit hesitant just giving it away for free (I earned my money with LV software consultancy for a few years).  But it being Christmas and all I'm showing me good will to all men (and women) by just releasing it and hoping for the best.

The software has some different layers to it.

1) USB subsystem: I have a series of VIs written to do the actual communication with the USB driver of your choice. VISA is currently implemented, others should follow.  This presents the LV programmer with a more simplified interface for USB communications.  One calling convention for a given USB request regardless of the USB subsystem involved.  All parsing of USB data is performed in LabVIEW so that the base class of this layer gets re-used for each and every driver subsystem.  The onle functionality required from a new subsystem is the ability to open a certain device, close it again and in between to read and write Control, Interrupt, Bulk and Isochronous requests (whichever are supported by the driver).  This should make the work required in writing a custom driver for say LibUSB, WinUSB, HID or whatever much easier.

2) USB Request: Each usb request can be encapsulated in it's own object.  The classes involved can inherit from each other and each one is completely independent of the driver subsystem.  I have included all standard USB commands (according to teh USB spec) and have also implemented others which don't show up here.  The idea of having this layer is to allow users to generate libraries of useful requests for whatever hardware they are using.  By making the complete set of device requests polymorphic (with drop-down selector) you have an entire device library in a single easy-to-use VI.

Without further ado, I'll attach the base class software here.  I'll follow up with some example software with the VISA subsystem later.

[Intaris]

Ok, a lot of time has passed since my last post, but here we go.  The time I have avilable for this is very limited so I do apolofgise for the very slow progress.

I realised shortly after uploading the code in my previous post that it's the wrong code.  Oops.  But that was 2011.

Here is the project I am currently working from, warts and all.  It's quite a bit of code for a nugget, but It's far from finished so any input is appreciated.  Yeah I know that my documentation within the code is lacking.  I started the code thinking it was for my own use only.... Not that that's an excuse or anything.

I have a simple example of how to use a mouse (with LibUSB or VISA driver) in LabVIEW via interrupt events.  Setting up the device is an inherent part of the process (selecting configuration and so on) which is normally handled automatically by VISA but should aloways be included to guarantee USB subsystem independence.

I have set up a little forum at www.intaris.ch/phpbb3/ for anyone wishing to discuss the code or looking for help.  You'll have to register, but I suppose that's no big problem.  I'll try to keep an updated version of the software available there for download.  In the meantime, here's my project.  There may be some stray code in there, but accessing through the project (post-fix) should be OK.

There 's a wrapper DLL for LibUSB included.  It was tested with 0.1.12.2 version and seems to have some minor issues with the current version 1.2.5.0.  I can't seem to initialise a device without opening it with the LibUSB tool itself first.  Jsut a warning.  The 0.1.12.2 version is still available for download.

Shane.

[Intaris]

So here's an example of the USB code.

I'll go through the operations step-by-step.

1. Cluster with device parameters (VID, PID, Interface number and so on)

2. VISA Comms class (Changing this to a LibUSB comms class object will actually switch the entire program over to using the LibUSB Subsystem without having to change any other code).

3. Setting the values of VID, PID and so on in the VISA comms class (so that it known which device it should be communicating with).

4. We open the device (Yes, there should be some decent error handling there)

5. Our first control command (Set configuration).  This is a data packet with the corrent control transfer data (wValue, bRequest and so on) for the standard operation "Set Configuration" - See USB Spec chapter 9 for details).

6. Process control request uses our USB subsystem of choice (VISA) and does the actual communications as dictated by the input data (Set Configuration).

7. Second control command (Set alternate interface - may be the cause of problems with current LibUSB driver).

8. Communications to implement the command defined in 7.

9. An Interrupt object for sending / receiving data vie interrupt EPs.

10. Here we set the event we will be using to receive data from the device whenever it sends data (Asynchronous operation is controlled by the subsystem driver).

11. Process interrupt request.  Here we actually launch a parallel asynchronous task to monitor the device for updates and send the new data via the event we have previously defined (step 10.)

After this we simply listed to the triggered events and close the device handle when we're finished.

Just a simple example as to how this can make working with USB a bit easier (for me at least).

Shane

[Intaris]

So what are we to do with this?

Here's an example I have personally developed and implemented.  As it turns out I had the great benefit of being able to switch from VISA functions to LibUSB functions within about 20 seconds (as designed) because I was getting a wierd error with VISA after 20 odd minutes of operation.  Yes, I have filed a CAR.  The program ran flawlessly with LibUSB for more than a week.

I had access to the device development specs of course which helped tremendously.  I implemented essentially every command possible for the device as it's own control communications package class.  Any inputs for the packet could thus be accessed via an enum input on the packet creator.  Any outputs were handled similarly with range checks being pefrormed.

By grouping all of these individual classes together into one big polymorphic VI I essentially had the entire library for the instrument present in a single VI with a drop-down menu allowing me to choose the command I wanted to use at the time.

While I can't post the code (past employer) I will post a wuick picture of the intended end usage of this toolkit.  At the end of the day this driver allowed me to implement my own control scheme for a brand new instrument (Sodium analyser) while the firmware for the device was not yet developed.  It went significantly further than any other firmware (At that time) and implemented a lot of never-before-used functions but having an up-and-running LabVIEW software as reference helped tremendously.

Given the new "Accessor" VIs for classes in LV 2011, even the VIs to access the returned data become polymorphic (pre 2011 this wasn't the case).  Of course this software will then run on any platform you happen to have a USB Comms class for (I currently only have LibUSB for Windows and VISA implemented although I HAVE run my software on Linux and Mac using LibUSB).  As such with no extra effort I have written an instrument driver which is cross-platform for Windows, Linux, Mac and probably RT as well if the VISA bug has been sorted....

Shane

[Intaris]

I realise I might be too close to the trees to see the forest so I wanted to say that any questions or requests are more than welcome here.

Anything to break the silence.

[Intaris]

Ibn addition to what I have already posted, if anyone out there has a USB device which they would like to have a driver for (preferable WITH USB command specs, otherwise it takes a long time) then please let me know.  I've been dying to get a real device up and running with this software suite.

I would especially like it if someone could loan me an Ocean Optics spectrometer for a while so that I can get a driver up and running.  I've already done the footwork with a different brand (can't release it yet) but I think the Ocean Optics spectrometers have a wider installed base and a driver could come in extra useful.

I'm open to suggestions.

Shane.

[K1200LT_rider]

This looks like an interesting way to capture USB traffic:

http://wiki.wireshark.org/CaptureSetup/USB

I might have to try it someday.

[Intaris]

I'm working on a sample driver (for a cool piece of USB hardware) to illustrate what I'm trying to achieve with this software.  I think my reasoning behind the software and its impelmentation has not come accross at all.

I will return to this topic in the near future.