Interfacing with multiple unknown USB devices; all producing NMEA strings

[ljaeggi]

Hi all,

Question about interfacing USB devices and their associated drivers.

I have the requirement to build an application that interfaces with USB devices that produce NMEA strings. I have the library to parse the NMEA strings but I am struggling with interfacing with multiple unknown USB devices. At the time of application deployment, I will not know all of the possible USB devices to be used.

Is there a way of producing a single driver that will accept strings out of any USB device?

Or, more likely, is there a way of getting LV to recognise a USB device connected and automatically find / install the driver like windows does and is this possible to do in a deployable application?

I've had a trawl of the forums but I haven't found anything this specific.

Thanks, I really appreciate the help.

[Sam_Sharp]

Any USB device? No. USB is a fairly complicated communications standard with lots of different device classes and options for communication.

If all of the USB devices are some type of USB-to-serial converter, then once the drivers are installed they will appear as a COM port and you can read the strings in LabVIEW using NI-VISA.

If that's not the case, then you can use NI VISA with USB RAW devices - you install a special NI-VISA driver for the USB device and you can then use NI-VISA to communicate with it at a much lower level - but it is not for the faint-hearted and you will need to implement different NI-VISA code to talk to each device at a low-level. There's an excellent guide on the forums here: http://forums.ni.com/t5/LabVIEW/Nugget-1-of-n-GEtting-started-with-USB-communication-via-VISA/m-p/74...

The main difficulty in doing it in a deployable application is that installing drivers/hardware usually requires admin rights / UAC prompt - which your program won't have if a user is running it. You can distribute the drivers during the installation process and probably use a batch file to install them to the system as part of the installer - but actually installing/selecting that driver for the device (if it's not the default) will require admin rights.

[ljaeggi]

Hi Sam,

Appreciate the reply.

Admin rights will not be an issue but nice if we could limit the users interactions in some way.

The device I am currently working with has a driver that has been installed and works well. The only issue I have found is that the device needs to be recognised in MAX before it can be used in my application. Is it possible to remove the interaction with MAX from the user? Another feature of MAX that would be useful for debugging would be the VISA Test Panel. I have not found this as a separate VI, is it available?

It is possible that later in development there will be devices that will not have specific drivers available. I suppose VISA can only make the programmers life so easy!

Regarding your second suggestion to use USB RAW, it looks at first glance to require an in-depth knowledge of the USB standard. Mammoth task I know but, will this also require knowledge of LV programming to create the driver or could a GUI be applied to guide a novice user?

[Sam_Sharp]

How does the device appear in MAX? As a VISA resource with a COM port? If so - then it's essentially got a USB to Serial converter inside it. Any device that enumrates as a COM port can be used with the same LabVIEW code (assuming they all output data in the same format) with NI-VISA.

What are you using MAX for? It's just a configuration / hardware discovery tool and pretty much everything you can do in MAX you can do in LabVIEW.

No - the VISA test panels are built into MAX and are not available as standalone VIs as far as I know - it would be relatively straight forward to make your own though - look at the VISA examples in LabVIEW as a starting point.

The VISA RAW is essentially a very low-level driver...you can use it to write a LabVIEW driver to ANY (specific) USB device but it requires in-depth knowledge about the USB protocol the device is using and general knowledge about how USB itself works.

If I were you, I would stick to serial-port based USB devices (that appear as a COM port when plugged in). The user just needs to install the driver for the USB to Serial part and then it will work with your software (assuming they all output the same format). I would never be able to say that I could write software that would work with any USB device - but I could write code or a plugin for each type of device.

[ljaeggi]

MAX is being used to discover which COM port the device is linked to / debugging the device.

The device I am using has two ports, one serial and another USB. I can communicate to the devices via either port using a serial port / USB port. I know both are seen as serial devices but can LV detect the port connection type? This will allow different types of configuration depending on the port type.

I believe it will be rare to come across a device that does not operate as a serial device but it will be possible to come across devices without drivers. I will look further into the development of a USB RAW driver as this may be the only way for LV to communicate with these devices.

Really appreciate the help.

[Sam_Sharp]

Yeah, you don't need MAX to find/select a COM port. Creating a VISA control from the 'configure serial port' and clicking in it will display a list of all attached COM ports and there are property nodes which can return the available COM ports.

LabVIEW/VISA doesn't care if the COM port is a USB-to-Serial, on-board serial, PCI/PCIe serial card etc. etc. - it just needs to be a COM port and VISA can use it. You just select the port (e.g. COM3) and the appropriate baud rate settings (which, again, the user could enter or you could the information from a configuration file) and it will work. Again - if you must differentiate between them, you can get properties/information about the VISA device.

If the device is a USB-to-serial port, don't use the USB RAW driver - you will have to write separate code to interface to each device - get the customer to install the appropriate driver which allows the device to emulate a COM port or distribute the drivers with your application. Many USB to Serial adapters can just download/install the driver from Windows Update automatically. Most of them fall under a common driver in any way (e.g. they are usually based on FTDI or Prolific chips).

[Dennis_Knutson]

LabVIEW does not detect anything. It is MAX that detects serial, USBTMC, and USB RAW. If it's detected by MAX, LabVIEW can use it. If they are seen as serial devices, then that is all that you need. Your comment about port connection type makes little sense.

The only time you need to worry about USB RAW is when the vendor doors not provide a Windows driver for the instrument and since each device would require a different USB RAW driver, I don't see how this would solve anything. The user of a device without a Windows driver would be the one who would have to write it. It's that what you want? It's also difficult to get the low level information from vendors. While a vendor may not provide a virtual serial port, they almost always provide some api for their USB connection.

I'm still a bit confused on your actual requirements. If you want a universal solution for an end user to be able to plug in any device that they wish and have it seamlessly work with your device specific code, that's quite unrealistic.

[Intaris]

---

@ljaeggi wrote:

 it will be possible to come across devices without drivers. I will look further into the development of a USB RAW driver as this may be the only way for LV to communicate with these devices.

---

Abandon this idea.  It's not practical.  Why are these devices so special that you need to go to such lengths to communicate with them?

[ljaeggi · Accepted solution]

Regarding the "configure serial port" VI, my issue is that the COM port selection is in a seperate menu (not directly linked to the VI) and there allows all possible COM ports to be selected. That can be addressed.

I'm not expecting an all -in-one solution but was asking the question in case this was possible. 

What I have grasped is that for my specific requirement to read strings from a USB device; it's likely to be sent via a serial connection. LV can handle that well and easily assuming the device has the driver installed / settings are available.

LV (and for that matter any other program) will not work without a device driver / settings. In this case, serial settings will need to be found (trial and error) / a USB RAW driver would need to be developed. Devices requirng a USB RAW driver would need serious consideration to persue due to the time and effort required. All of this effort falls under legacy work for navigational aids

I really appreciate all the help and I think I've got the answer I was looking for! Thanks very much