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

Question

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.
Say hello to my little friend.
RFC 2323 FHE-Compliant

Answer 1

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
Say hello to my little friend.
RFC 2323 FHE-Compliant