LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How do I send an array over endpoint 2 and receive an array over endpoint 1?

Background:

 

I'm a device developer.  I have an HID device that interrupt transfers over endpoint 1 and endpoint 2.  The device enumerates successfully as an HID on mac, windows, and linux.  I've use a couple different .dll files to communicate with the device using visual studio and python with some success and now I'd like to get it to work in labview.

 

Status to date:

1.  Successfully installed device hijacker driver so NI MAX can see the device as USB::0x####::0x####::SerialNumber::RAW (# inserted to protect the innocent and SerialNumber is an actual number)

2.  I can see the device in MAX.  Tried to send a line of numbers and something is sent back, but it isn't useful yet.

3.  Tried interruptusb.vi and it doesn't do anything but timeout.

4.  Tried Read USB Descriptor Snippet1.vi and an 18 byte array shows up and the VID and PID are parsed out correctly if the bRequest is Get Descriptor and the Descriptor Type is Device.  None of the endpoint descriptor types return anything.  A bRequest won't trigger a device function.  It needs an array over the out endpoint.

 

The problem:

Intuitively I'm at a loss of what to do next.  The device needs to receive a command from a 16 byte array gets passed through the out endpoint (2).  Then it will respond with a 16 byte array through the IN endpoint(1).  It seems as though the interruptusb.vi should work, but the interrupt transfer is a receive only demonstration.  How should I format a 16 byte array to go through the out endpoint? Does it need to be flattened?  

0 Kudos
Message 1 of 5
(3,321 Views)

I'll respond to my own question with an answer that is partial.  The device is communicating and labview is getting data, but it isn't always consistent.  Sometimes the communication is corrupt.  I don't know why.

 

I used the interrupt transfer example VI posted on this board.  It turns out that the 16 byte array has to be input as a string of hex values. 

 

The program 1) opens the visa, 2) enables the interrupt, 3)writes the hex string using the hex display option for the text field into the visa write 4)waits for interrupt response 5) Gets USB interrupt data, 6) closes the interrupt event 7) closes the visa connection

 

The program is called repeatedly from a parent vi and when it works, it works, but sometimes it doesn't.  It stops after several reads sometimes. Sometimes it doesn't start. Sometimes it runs for a while.  I can't seem to figure out what is hanging it up.  It appears that the interrupt times out and the program doesn't know how to recover.  Any ideas?

0 Kudos
Message 2 of 5
(3,245 Views)

Here is the code block:

0 Kudos
Message 3 of 5
(3,146 Views)

have you seen Dr. O'Neals Nugets on using USB in LV?

 

Part 1

 

Part 2

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 5
(3,141 Views)

Thanks for the tip.

 

The nuggets were great for getting started and helped with installing the labview hijack driver for the HID device.  Closer examination may lead to the conclusion that the code I'm using is very very similar to the nugget with minor changes to the output.  Definitely the nuggets are useful, but for my device, there is more to it. 

 

It is not USBTMC compliant.  It requires an array of bytes be sent and received.  The problem may have to do with timing and ensuring that the byte transfer is correct.  When communicating from visual studio, a declared array of characters works fine.  I tried that with this setup and it doesn't work consistently.  Of particular concern is why with this setup the device shows up, doesn't work properly until stopped, then works fine, but when the labview VI is stopped, the device disappears and no longer available in the VISA combobox.  The Device Manager still shows the device, but Labview must have an open handle to it. 

 

I'd really like to be able to call the dll used in Visual Studio, so the user can choose to use the included software or a Labview VI without having to reinstall a driver.  Afterall, HID is great because the driver is under the hood.  Having to load one for Labview defeats the purpose of developing an HID device.  If I wanted to load a driver, I'd program the device to be a USB-Serial device and use the labview VISA serial vi's. 

 

For now I'll be happy to get a stable version in Labview that will communicate consistently even if it is the hijacked driver.

0 Kudos
Message 5 of 5
(3,133 Views)