Problem using LV 8.0.x with Delcom USB Visual Signal Indicator

[Kevin Valentine]

This could end up being more of a general question about USB and LabVIEW 8.0.x.  I have a USB Visual Signal Indicator from Delcom that doesn't function properly under either LV 8.0 or 8.0.1.  I've had to revert back to LV 7.1 where it works fine.

Please see the attached VI and dll.  This is the primary VI that doesn't work properly after the upgrade.  It should vary the intensity of the LED.  No error number is returned.  It just seems to ignore the command.  I contacted the vendor.  He says it must either be a problem with LabVIEW 8.0.x or the way I initialize the variables within the Call Library Function.

Have any of you noticed any problems with USB devices when transitioning from LV7.1 to LV8.0.x?

Message Edited by Kevin Valentine on 03-22-2006 12:32 PM

[Andy F.]

Hey Kevin!

I took a look at your VI and I don't see anything that would cause you problems calling the DLL.  Calling a DLL should be pretty much the same for all versions of LabVIEW so that shouldn't be causing the problem.  The first thing I would try is to make sure that the DLL's path is correctly specified.  It is possible that when moving from LabVIEW 7.1 to 8 the paths can become mixed up.  You might even try to put a copy of the DLL into the system32 folder so that the VI can find it.  If that doesn't work take a look at one of the shipping examples called Call DLL.vi and see if you have any problems running that.  If you open the Example Finder (Help >> Find Examples) and search for DLL you should be able to find it. 

Please repost if you have any questions!
Andy F.

[Kevin Valentine]

Finding the dll can't be the problem.  I keep it local to the VI and in a data folder for the build.  If LV couldn't find the dll, I wouldn't be able to use the other functions like toggling the LED on/off.

-kevin

[JLS]

Hi Kevin,

That's interesting - so that particular VI works in 7.1 but not in 8.0 currently on the same machine?  I wish there was a way I could try this on my machine!  Anyway, give the following a try (admittedly I'm reaching for straws here):

1. Dropping a new call library function node on a new block diagram and see if the problem persists.

2. Hold down shift and control and click the run button to mass compile that VI - any changes in behavior?

3. Try deleting the inputs and running it, then replacing them and running it again - any changes for either run?

4. Try saving the 8.0 VI for previous to version 7.1... does that VI work in 7.1?

I don't know what's happening, but playing things like that may give us some clues as to what's happening - if this is a problem with LabVIEW, I am very interested in getting to the bottom of it and formally alerting R&D of the problem.

Best Regards,

JLS

[Kevin Valentine]

Sorry for the delay.  Had to work on some other projects for a while...

I tried what you have suggested but didn't notice any change.  Because I was seeing the problem primarily with the LED controller, I intentionally didn't mention the Newport Optical Power Meter (model 1930C) also attached to the same USB hub.  Now I'm thinking it's the Newport DLL conflicting with the Delcom DLL.

To test this I made two different interfaces: one that allows me to intialize and control the LED and OPM; the other just controls the LED.  I opened them in two separate instances of LabVIEW 8.0.1.  The first one consistently cannot control the intensity of the LED and sometimes will even produce a read error from the OPM and then lock up communications with the OPM.  Requires an OPM power cycle.  The second one shows no issues with controlling the LED intensity.  Based on this simple test the problem seems to point to the Newport DLL... but maybe I shouldn't jump to conclusions.

Still, very strange that this doesn't cause a problem in LV 7.1.  I guess LV 8.0.1 is just more "sensitive" to something that the Newport DLL is doing.

As a quick fix, what I'll do is use the OPM's GPIB option and avoid any issues that Newport's DLL may be causing.  Since the client has expressed interest in continued use of the USB port, I may just dump LabVIEW for this project and go with Python or similar.  That should be a fun change 😉  Of course the other option is to just use a USB to GPIB adapter...

Thanks for you're help!

[JLS]

Hello,

No problem on the delay.  If you have time, can you post a screenshot of the output from a USB View program?  This should show the status of your usb ports, and specifically information such as vendor and manufacturer IDs for connected devices to your USB ports.  USB View is shareware and you should be able to download it from http://www.srigc.com/PeakSimple.htm (search the page for usbview and you'll find it quickly).

I'm just interested in seeing if there's anything unique (or at least apparently so) about how Windows sees those ports and devices.

Looking forward to your repost!

Best Regards,

JLS

[Kevin Valentine]

Hi JLS,

Things are working now.  Looks like I made a mistake in the Call Library Function Nodes of the two VIs.  I misread the documentation and used U8 instead of U32 for the input parameters.  I also found that one of the VIs provided by Delcom wasn't initializing the a string input for 512 characters.  This seemed to create some problems but it's hard to verify.  Still kinda strange that it worked fine on LV7.1...  Oh well, I'll have to be more careful next time.

You mentioned usbview, which I'm familiar with on Linux.  Do you know of any other tools available for monitoring data on the USB bus?

[unclebump]

Try this one.

http://www.aggsoft.com/usb-port-monitor.htm

[Kevin Valentine]

Thank unclebump!

[JLS]

Hello,

Great to hear that it's working, and those oversights happen to all of us sometimes.  I am not aware of utilities that actually monitor the USB bus data.  Windows handles USB access usually by recognizing the connected device, correlating it with a driver by scanning inf files while searching for matching vender and manufacturer ID (as well as other information I think - see the C:\Windows\INF directory for examples of INF files - they are ascii files so you can open them in notepad, but I DO NOT recommend modifying them; this directory may be invisible unless you have checked the folder options to show hidden OS files).  Now, the USB View program is catching that information when the device is plugged in, so it must be possible to silently monitor the USB port.  The only way I know to get data from it outside of using an existing driver (and without searching the web first) would be to basically write your own.  Now, it wouldn't be a full blown device driver since you could theoretically use the VISA driver development wizard to make VISA the driver for the device you would be plugging into the USB port (you specify vendor ID etc for the device in that wizard, and it writes an INF file and tells windows to go refresh it's knowledge of those files).  Then you could write a program in LabVIEW using the VISA API to simply read data from the port.  This process, however, would make VISA the driver for that device on your machine until you deleted the inf file from that Windows directory, and you want to be using the driver shipped with the device.  Also, even if you did get the raw data, unless you knew how the firmware on your device was interpreting that data, it would likely look quite random.  A better option might be to look for a function in your dll which will "passively" return that data to you in a readable format.  But, the function may not exist and we would still have the trouble of interpreting the data.

Probably best to stick to your manufacturer driver and troubleshoot at a level of abstraction above interpreting the raw usb transfer data.

Best Regards,

JLS