From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
USB RAW Control IN 64 byte transfer failure
jws7793
Member
06-04-2009 12:53 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
I am using Labview 8.2.1 and VISA 4.5. I am trying to get my custom USB device to work with Labview to do simple data transfers. I am currently using a Vendor Request Type 0xC0, value 0, index 0, length of 64, and a Vendor Request of 0xFD which my firmware recognizes as a command to respond with a particular 64 byte packet of data. When I use the VISA Interactive control, everything works fine - the 64 byte packet comes back as expected. However when I try to do the same thing with the USBRawControl.vi the 64 byte packet does not get read in. Looking at the USB bus with an analyzer I see something fishy - after my device sends the 64 bytes the Host PC ACK's the packet, but then sends another IN0 which my device STALLs. When I run the scenario with VISA Interactive Control, the Host PC sends an OUT0 which my device ACK's and data shows in the read buffer on the front panel. If I try using USBRawControl.vi with any transfer requiring less than 64 bytes, things work fine. What could be going on here?
Justin_E
NI Employee (retired)
06-05-2009 03:59 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Hello,
So, basically what's happening is that the VISA Interactive control is sending the OUT0, which is what your device is expecting, and the USBRawControl.vi sends the IN0, which causes your device to stall? Would it be possible to take an NI-Spy capture of your communication, so we can take a look and see what's going on? Instructions on doing this can be found here : http://digital.ni.com/public.nsf/allkb/282C5D41E2BA04F2862574BA007803B9
So, basically what's happening is that the VISA Interactive control is sending the OUT0, which is what your device is expecting, and the USBRawControl.vi sends the IN0, which causes your device to stall? Would it be possible to take an NI-Spy capture of your communication, so we can take a look and see what's going on? Instructions on doing this can be found here : http://digital.ni.com/public.nsf/allkb/282C5D41E2BA04F2862574BA007803B9
Justin E
National Instruments R&D
National Instruments R&D
06-08-2009 08:31 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
In trying to capture this I figured out what was going on. In VISA Interactive Control the radix is decimal for the length. In USBRawControl.vi the Length radix is hexidecimal - so Labivew sent the second IN0 since it was expecting more than the 64 bytes my device sent it. My device was confused since with this extra IN0 since the firmware was set to always send out a fixed 64 byte packet for this vendor command no matter what wLength was in the SETUP command. I changed my code to look at wLength and act accordingly and things now work.
Justin_E
NI Employee (retired)
06-09-2009 10:35 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Glad to hear you were able to get this resolved! Thanks for posting your solution in case anyone else runs across this same problem 🙂
Justin E
National Instruments R&D
National Instruments R&D
