In writing the LabVIEW API for a new USBTMC/488 device we've developed, I ran into what appears to be a bug in the NI-VISA USBTMC driver. If a VISA Read times out, the clean-up procedure is incorrect according to the USBTMC standard, and ends up locking up the Bulk-In endpoint.
Using an Ellisys USB protocol analyzer, I can watch the clean-up procedure in the case of a read time-out: (EP0 is my control endpoint, EP1 is the Bulk-In endpoint) EP0: Host sends InitiateAbortBulkIn EP1: Device returns short (empty) packet to flush failed IN transaction EP0: Host sends CheckAbortBulkInStatus; Device returns
Success
This all looks OK. However, according to USBTMC standard (p. 25, Table 29), the Host should
not initiate any more BulkIn transactions for the failed command. What
actually happens: EP1: Host continues to send IN transactions (forever);
Device NAKs them (forever) EP0: Host sends ClearFeature/Halt for EP1
Apparently the Host expects the IN transactions to be stalled. So I thought, what the hell, I'll stall it. I added a little error handler to my read that uses the "VISA USB Control Out" to send a SetFeature(EP1, Halt) followed by a ClearFeature(EP1, Halt). As expected, that stops the steady flow of NAKed transactions on the Bulk-IN endpoint, but it seems to really screw up the driver: the next VISA Read I try to do returns status of 0xBFFF003E (VI_ERROR_IO). Pretty succinct.
I'm using VISA 4.2 under WinXP. In the device, we're using NI-Device 1.6.0 Plus DDK, with our own USB driver. Except for this problem, all is working very solidly now. As far as I can tell, this fellow may have run into the same problem with a Tek scope, running VISA under Linux.
Any help would be appreciated. Sincerely, -- Philip
