This widget could not be displayed.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

communication with USB Raw device


@Andrey Dmitriev wrote:

That could be great exercise...  Smiley Happy


That WOULD be a great exercise, but I don't see the *IDN? command anywhere in there, did you delete it from the document? Smiley Very Happy

 

@Dennis, I wholeheartily agree but something in my mind (the part that keeps reminding me of the limits of my knowledge) was telling me "Well, I sure don't think the *IDN? command is USB-standard and this guy seems crazy but hey, there are lots of things I'm not an expert on."  I was doubting myself, but since someone else agrees with me either I'm not crazy or we're the same amount of crazy.  My experience suggests the former may be the more likely.

 

Shane

0 Kudos
Message 11 of 24
(1,167 Views)

Shane,

 

The only place that documents the *IDN? command is IEEE-488.2 (and it's derivatives).

 

Personally, I would like to see the tutorial on creating a VISA USB driver hidden and only unlocked by users that can prove at least a minimal understanding of USB.

Message 12 of 24
(1,160 Views)

Actually all I have to do is to communicate with my device through USB port. So to just check whether I can communicate, I used Pendrive. I was trying to access data from pendrive but I am unable to do it.

0 Kudos
Message 13 of 24
(1,152 Views)

Sure, you can communicate also with pendrive, but you need to recreate full communication protocol. Is your device uses the same communication protocol as pendrive? Sure, not. There are two modes for communication. Instead of using  *IDN? command with pendrive you must use low level I/O, something like this (on given screenshot I perform communication with old USB Scanner):

 

Andrey.

0 Kudos
Message 14 of 24
(1,143 Views)

USB is a layered protocol interface much like your network interface too. You have the electrical interface which is the USB connector. On top of that the USB communication which in its lowest incarnation is just a bunch of endpoints (addresses) that can be talked to.

 

This is what you access with VISA USB Raw. On top of that you have many device classes. Such as USB COMM, for message based devices much like RS-232. Or USB Mass Storage for mass storage devices, USB HID for human interface devices such as keyboards, mice or similar, USB Test and Measurement which is similar to the Mass Storage class in the used endpoints but specifically adapted to implement also the IEEE 488.2 commands on top of that. And while it's not to difficult to implement USB T&M in a device, provided you know what you do and have created USB devices already, this interface class is only really used by T&M manufacturers and there also only by a few, usually associated with the VXI P&P consortium.

 

Each device class has specific endpoints it uses to transport data between the two ends, and specific ways to use the interrupt, bulk and control mechanismes that USB Raw provides. While a USB Mass storage implementation of a LabVIEW driver based on USB Raw could be used as underlaying component to implement USB T&M, there is no point in trying to talk with USB T&M commands (your *IDN? command) with a mass storage device, since it's about the same than if you would talk in Mandarin to someone only understanding English.

Rolf Kalbermatter
My Blog
Message 15 of 24
(1,138 Views)

How do we know what to use for request type and request inputs for both control in and control out vis when we are using a pendrive?

0 Kudos
Message 16 of 24
(1,134 Views)

@Dennis_Knutson wrote:

Personally, I would like to see the tutorial on creating a VISA USB driver hidden and only unlocked by users that can prove at least a minimal understanding of USB.




Dennis, you know, I agree.

 

I have the feeling that I've opened a can of worms with my Nuggets.  Maybe it's just my perception, but I feel the number of these types of threads has increased int eh last year or so.

0 Kudos
Message 17 of 24
(1,128 Views)

@kimhyun wrote:

How do we know what to use for request type and request inputs for both control in and control out vis when we are using a pendrive?




By reading and understanding the USB specifications! No that is not a goodnight story for children and needs quite a bit of technical background in order to be comprehensive, but such is life. You can't build a skyscraper only knowing how to put Lego bricks together.

Rolf Kalbermatter
My Blog
0 Kudos
Message 18 of 24
(1,120 Views)

@Intaris wrote:
I have the feeling that I've opened a can of worms with my Nuggets.  Maybe it's just my perception, but I feel the number of these types of threads has increased int eh last year or so.


No!  With your Nuggets I've got an idea to develop my own software for the old USB scanner (which is haven't any driver for Windows 7). And it works, I'm happy.

In general LabVIEW - is also can be calssified as "worm" - you can do lot of things with small bricks. The problem what I see - LabVIEW tends sometimes as "black magic box". With several mouse clicks you can easily get great result, but very often the engineers do it without deep understanding - how it works behind.

0 Kudos
Message 19 of 24
(1,116 Views)

Andrey,

 

Topic derailment ahead:

 

What exactly have you implemented and using which software?  I'd be very interested to hear more......

0 Kudos
Message 20 of 24
(1,112 Views)