Problem getting USB interrupt data after reopening device

[MikeMcC]

Hi there,

I am working on a LabVIEW 8.5 program to read some A/D values from an instrument we built.  The instrument has a Microchip PIC18F4550 microcontroller in it, and the USB firmware supplied by Microchip configures the chip with an Interrupt OUT and an Interrupt IN endpoint.  I'm using NI-VISA 4.2 for communication, and the PC OS is Windows XP Pro.

I used NI VISA Driver Development Wizard to create a USB RAW driver, and my device shows up under MAX just as it should.  After I got my device configured, I wrote a simple VI that waits for the user to enter a device command and push a button, and after the button is pushed the VI waits for a response.  The command is sent via Interrupt OUT transfer, and the response is via Interrupt IN.

The problem I have is that I can't run my VI more than once.  If I run it once I can send a command to and get a response back from the device, but if I re-run the VI, it times out waiting for an interrupt event from the device.  I can get the VI to work again by unplugging my device from USB and plugging it back in again, but that's obviously not a good way to handle things.

My question is, am I handling all of the VISA I/O correctly?  As far as I can tell I have, but maybe I need another set of eyes.  Attached is my VI.

Thanks,
Mike

[O_Proulx]

Hello Mike,

I would suggest integrating your code into the USB RAW -Interrupt.vi  example you can find by going to Help -> Find Examples and navigating to Hardware Input Output -> VISA -> USB RAW -Interrupt.vi.  Also, you may want to use the USB RAW property node to ensure that you are using the out pipe to send your data to the PIC.  You can look at this document for more information on that.  It seems like your VISA session may not be closing properly, so using the example provided above may help.

The problem may also be in your PIC.  Do you know if you need to reset the interrupt flags after you receive an interrupt, or does the firmware take care of that? 

Let me know if this helps. 

[MikeMcC]

Thanks for your reply.  I'll try integrating into the example VI.  That should tell me something.

I think the Interrupt OUT pipe is working okay, because I can open the USB device one time just after it is plugged in, send a command, and get a response.  In fact, if I put VISA Read and VISA Write into a loop after calling VISA Open, I can send commands and get responses until I call VISA Close.  So, I think you're right about something not getting closed properly.

I don't think the problem is on the PIC side because I can communicate without problems in Visual C using an API from Microchip.  We'd like to be able to supply everything in LabVIEW, though.  Maybe there's something the Microchip API does when closing the device that I need to also do in LabVIEW.  In any case, I'll try integrating into the example VI first.

Thanks again,
Mike

[MikeMcC]

Hi O_Proulx,

I put a VISA Write into USB RAW - Interrupt.vi so that I could send a command to my device and then read back the response via Interrupt IN.  The result was the same as with my own VI.  I could open a session, send all the commands, and read back all the responses I wanted to until I closed the VISA session.  Then when I tried to re-open a session, the device would hang until I cycled power.

I tried something else that has helped, although it doesn't completely solve the problem.  I added a case structure after VISA Wait On Event.  If no error is returned by VISA Wait On Event, then I read the data using VISA Get USB Interrupt Data, but if there is an error, I call VISA Clear instead.  After calling VISA Clear, I can again communicate with my device--without closing the session that is open.  That is, when I open a second session and send the first command, VISA Wait On Event times out and so VISA Clear is called.  Then for subsequent commands I can send them and read back the responses until I close the session.  Now at least I don't have to cycle power between sessions.

Seems to me, though, like there might be some data left over in one of the endpoints, since VISA Clear resets endpoints.  In this case, maybe only the Interrupt OUT endpoint is being reset because my device doesn't have a Bulk IN endpoint.  Not sure quite what to think since I don't know exactly the VISA VI's do.

If this brings anything to mind for you, let me know.  In the meantime, I think I'll look at some firmware and API source code and see what might be different.

Thanks,
Mike