Bad USB driver or no interrupt channel?

[Akello]

Hello all,

I am trying to control a USB Tachometer (http://www.shimpoinstruments.com/tachometer/shimpo_dt-209x.htm) via LabVIEW/VISA and I am beginning to suspect there may be something wrong with the driver I created.

I've been using a USB Sniffer called USBPcap (http://desowin.org/usbpcap/index.html) and analyzer called Wireshark (http://www.wireshark.org/) to monitor a computer running the instrument's software on Windows XP (software does not work on later OSs). From that, I've isolated basic USB commands like asking the device to identify itself but when I try to run a simple VISA Open, Write, Read, Close VI with that command, I get a timeout error at VISA Read. Through the debugging stage, I came across a thread about USB communication with VISA (http://forums.ni.com/t5/LabVIEW/Nugget-1-of-n-GEtting-started-with-USB-communication-via-VISA/m-p/74... thank linked to the interruptusb.vi (http://zone.ni.com/devzone/cda/epd/p/id/4516).

When I try to run the interruptusb.vi, I keep get the same timeout error. I created the device's driver with VISA's Driver Wizard and MAX recognizes it when I plug it in.  The interruptusb.vi says that everything should work so long as the device has an interrupt channel. Is it possible that the tachometer could be missing this channel? As a control, I ran through the same steps with an old webcam (Creative VF 0400) and it works fine albeit returning all zeroes since nothing is happening with it. My question is could there be something wrong with the driver I created or can there really be no interrupt channel on this device?

Any and all help is greatly appreciated as I am still pretty green in dealing with USB communication.

Thanks,
Yusif Nurizade 

[Mockingbird]

Hi,

if you've managed to get a VISA driver up and running for other USB devices with the interruptusb.vi it's quite possible that the USB Tachometer does not have an interrupt channel. The best people to check that with would be the manufacturers of your particular USB Tachometer. Another thing of note to ask is if the USB device is a VISA device. Specifically, if the USB device responds to VISA commands. WHen you said you got the device to identify itself what did you mean by that? Was it the "*IDN?" you used in identifying?

[Akello]

Mockingbird,

Thank you for the response.

As per your advice, I've contacted the manufacturer to ask about the interrupt channel.

In the meantime, I should clarify; I did not get the device to identify itself. With the driver I created in VISA Driver Wizard, I got NI-MAX to recognize the device and I tried sending a USB command that I believe asks the device to identify itself. I am basing the command meaning based on having captured and analyzed the USB channel on a computer running an older OS that can support the instrument's software. I just got the USB 2.0 specification manual so there will be a more methodical approach to the commands I am sending in the future. Unfortunately, the manual is 650 pages so this may take some time to get through.

Finally, regarding the device responding to VISA commands. When I go into the VISA Test Panel through NI-MAX and press Write on the *IDN?\n in the Input/Output tab, the window reads:

1. Write Operation (*IDN?\n)

Return Count: 6 bytes.

Unfortunately, when I press Query or Read, I get

Read Operation

Error

VISA: (Hex 0xBFFF0015) Timeout expired before operation completed.

Similarly, when I try to put the *IDN?\n in the VISA Write string of my VI, I get the same error message. What this mean for my attempts to control the instrument this way?


Thanks for your help,
Yusif Nurizade

[Dennis_Knutson]

What it means is issuing the *IDN? query is absolutely silly. The command is a GPIB standard and your device is certainly not anything close to GPIB.

If you are capturing the USB commands to the dll, then sending those same commands with VISA is also silly but I've already told you that.

Get the source code for the obsolete driver or the low level RAW commands from the vendor but I think I've already told you that as well.

[Akello]

Always happy when you contribute to one of my threads Dennis

I didn't put much stock in the *IDN?\n command. I tried it off NI-MAX just in case and redid that as well as sending it as a string command in my VI as per a previous suggestion on this thread. My main approach has been the USB low-level commands fed in as a VISA Write string in hex ever since you explained to me why sending the .dll's commands would get me nowhere.

What I've been doing is capturing USB traffic between a laptop running and older version of Windows, and therefore able to use the company's drivers and software, and the tachometer. I then sent the relevant USB commands, 8 out of 36 bytes, to the device and waited for a response before getting a timeout error. I know you suggested deciphering the .dll file but I'm a little rusty on my C/C++, which I believe it is written in, and your comments on my last thread led me to believe the USB sniffer was a possible alternative. In the post I am refferring to you said:

"If you can install the driver on another pc, a usb sniffer should be able to tell you the low level protocol you need for a VISA driver. I don't know of a sniffer program offhand, sorry."

Did I misunderstand your meaning?

I will be writing to the company to ask for the source code, though I am not confident I will be successful, and in the meantime I have the USB 2.0 specification to look through.

Thanks for weighing in,
Yusif Nurizade

[Dennis_Knutson]

No, you did not misunderstand me but I have no idea what your sniffer is actually capturing - the transmission from the application program to the dll or from the dll to USB.

[Akello]

I can see how that would convolute the issue.

I can post the capture data if you're willing to take a look but I'm not sure how much you would be able to get out of it. I was actually under the impression that whoever is doing the communication, the 8-bytes USB command would stay the same. I'll be looking at the USB 2.0 specification to see if I can figure it out.

I'll also ask the company for the .dll source code. Any suggestions while I wait for the reply and wade through the 650 page manual?

Thanks again,

Yusif Nurizade

[Dennis_Knutson]

You can post the capture (at least a portion of it) and your VI. It has been several years since I've had the unpleasant job of working with USB RAW so I can't promise anything.

[Akello]

Dennis that would be greatly appreciated. That's not an adequate phrase but, having dealt with this thing for the past couple of months, words can't describe how grateful I will be.

The website won't let me attach the files due to format but I am including a link to my Public Dropbox folder that has all the relevant files (I used Wireshark to read them):

https://www.dropbox.com/sh/gqvwwa890r7w426/WJZiXbLYj7

On_Not_Run_7_2_2013 is a capture of the device conntected to the computer with XP where the company's driver works, the software is not run.
Ran_Program_8_16_2013 is like the previous capture but this time I ran the software and waves my hand in front of the device so it thought it was taking rpm readings.

interruptusbVI_test_8_5_2013 is the interruptusb.vi run on the Windows 7 computer with the driver created in VISA Driver Wizard

Watching_LabVIEW_Short_Command_7_10c_2012 is my VI run on the Windows computer with the same driver created VISA Driver Wizard

I took the command I sent to the device from the first command sent to it in On_Not_Run_7_2_2013. My VI is attached, please let me know what you think.

Thanks again,

Yusif

[Dennis_Knutson]

Aren't you able to save the capture files in some text format? They have no extension. I really do not want to have to install another big program in order to read them,