visa wizard to implement USB

[DeOdderKeith]

I thought that this was a more "standard" approach to using USB in LabView?

The assumption is that, as more applications are written with this device, it would be easier to

manage the USB Port. Perhaps I just -ass-u-me- 'd.

If not, are there any other ways to "properly" open a USB Port?

I think I would like to verify that the device is connected to the PC before starting the application.

Is there a simple way to do this?

[Mark_Yedinak]

---

DeOdderKeith wrote:

I'm using the dll in my LabView application only.

I would like to use the VISA calls directly, however, the USB Port does not show up in MAX, until I use the VISA wizard.

Is there some other way to let MAX know that there is a USB Port out there and point to the OEM-supplied inf file ?

---

No, there isn't. You probably need to do the final association using the simple program I mentioned. See if this may help.

[Mark_Yedinak]

---

Dennis Knutson wrote:

You use one or the other driver, not both. In other words, if you want to use VISA, then you cannot load the original inf/sys file and your dll. The VISA functions for USB are on the Instrument I/O>VISA>VISA Advanced>Bus/Interface Specific>VISA USB.

If you go the VISA route, search out all of the Nuggets from Intaris.

Message Edited by Dennis Knutson on 10-27-2009 03:32 PM

---

You may not need to use the USB specific VISA VIs. It is possible, depending on the exact device, to use the staright VISA Read and Write VIs. I have been using them for quite some time to communicate with printers.

[Song_D]

Mark,

When used with USB, VISA Read and Write nodes are used for *bulk* communication. If the device is designed to communicate via control or interrupt pipe, then you'd need to use the USB specific VISA nodes.

[DeOdderKeith]

Time to step back.

I'm reviewing my project again.

I think you asked pertinent questions that I didn't spend much time on. Apologies.

Why do I need to use VISA?

Upon the call from LabView, my C++ DLL already opens the port, and responds if it isn't opened properly.

I guess I was just following the request from my current client to look into the VISA path.

My application had a couple of timing issues which would cause it to NOT close properly, which

would mean that the USB port would remain open, and, I guess, inaccessible to any additional

Open Port requests.

This meant that the USB device had to be disconnected from the PC, and re-attached, which would

re-load the drivers, and all would be good again.

I'll test my theory tomorrow with another PC.

Thanx enormously !

[rolfk]

---

DeOdderKeith wrote:

Time to step back.

I'm reviewing my project again.

I think you asked pertinent questions that I didn't spend much time on. Apologies.

Why do I need to use VISA?

Upon the call from LabView, my C++ DLL already opens the port, and responds if it isn't opened properly.

I guess I was just following the request from my current client to look into the VISA path.

My application had a couple of timing issues which would cause it to NOT close properly, which

would mean that the USB port would remain open, and, I guess, inaccessible to any additional

Open Port requests.

This meant that the USB device had to be disconnected from the PC, and re-attached, which would

re-load the drivers, and all would be good again.

I'll test my theory tomorrow with another PC.

Thanx enormously !

---

Good move! If things start to look overwhelming you probably messed up some things and sure enough you did.

First the manufacturer of the device provides an *.inf file and a *.sys file and apparently even a DLL file to access that *.sys kernel driver. So there is really no need to try to access the USB device directly through VISA.

In fact this is at best a painful option, often even a hopeless one. In order to access the USB device directly through VISA you need to know the exact raw USB protocol and most manufacturers rather drop dead than give out such information.

Your best bet is to access the DLL that came with your device and which seems to already provide everything. If your problems are caused by your application not properly releasing the port before exiting then you should and can fix that. If they seem to be caused by troubles in the driver (DLL or SYS) then you need to take it up with the manufacturer of that driver software.

USB Raw communication over VISA is IMHO really just a last resort when everything else fails and that even requires the device manufacturer to cooperate in that he needs to give you the USB Raw protocol documentation. Reverse engineering such a driver through USB protocol analyzers is not only a very frustrating experience but also a very expensive one. And the worst about it is that you can not really be sure if you have captured all possible incantenations of protocol elements and your driver may suddenly start causing problems in unforeseen situations.

Message Edited by rolfk on 10-28-2009 08:53 AM

[Intaris]

I agree with Rolf in questioning the need for VISA at all.

One problem with USB in Windows is that it REQUIRES a driver to work, unlike Mac and Linux where it is far easier to gain access to a USB device.

If you don't have a specific reason to go with VISA (Porting a Windows app to Mac for example - the DLL won't work then) I would leave it alone.

I'm currently working on a LV wrapper for the Libusb driver which essentially allows access to USB ports via a filter driver (Kernel driver) parallel to any vendor-specific device driver you may have installed.

I don't have a release date yet but I can only say that I'm working on it and making progress.

Shane (Intaris)

PS Libusb also has the ability to reset a device, something not possible with VISA.

Message Edited by Intaris on 10-28-2009 05:54 AM

[DeOdderKeith]

As a follow-up, I've tested the theory this morning and it seems to work.

As an aside, the manufacturer provided the inf and sys files, however I wrote the C++ DLL, and even getting info from the manu to get THIS done was like pulling teeth, so I cannot even begin to fathom the pains for getting the raw USB protocol (unless I agre to offer them ca$h. This seems to be the driving force for this particular manu!)

An issue that came up this AM was the following (and I may need to open a new thread for this, but I'm sure someone will let me know) :

I ran my app on a laptop and all was well. Then I HAD to go get coffee! When I returned the laptop had gone into standby mode. I logged back into the laptop and tried running the app. It error-ed on opening the port. I exited LabView, unplugged the USB device, plugged it back in, and re-started LabView. Ran the app and all was well again.

Apparently, when the laptop went into standby, something stopped the USB from communicating.

I had used this DEVCON (DOS-based) app to make sure the USB driver was loaded, but I don't know if this is the right approach.

Any suggestions?