LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why do I get a blue screen using USB communication?

Well the bytes at port just adds more issues.....Even using the minimal code, sometimes it works, sometimes it does not (as in the queue fills). However no BSOD. I have contacted the creator of the Teensy, so waiting to hear back on what he thinks. Thanks again for the help.

0 Kudos
Message 21 of 25
(1,686 Views)

A solution that worked for me was to change the VISA read/write VI's to synchronous. This setting is found by right-clicking on those VI's.  Apparently this is a known issue with USBSER.sys.

Message 22 of 25
(1,568 Views)

I had a very similar problem when using serial communication through a USB port for an agilent U1733C LCR meter. I would get a BSOD at random intervals between 5 minutes and 4 hours. After pulling my hair out for a few days, I came across this post. I found it had nothing to do with the drivers, but everything to do with using synchronous read/write VIs. Thanks for the suggestion Mark.

Message 23 of 25
(1,469 Views)

I tried to connect a Fluke 2638 to labview and also got BSOD after 30-300 minutes, with error related to usbser.sys ( Driver_irql_not_less_or_equal ). I looked at all VISA read instances and it turned out one was set to asynchronous communication, I changed it to synchoronous and now it works!

 

From labview:

 

Whether the data is read synchronously or asynchronously is platform-dependent. Right-click the node and select Synchronous I/O Mode»Synchronous from the shortcut menu to read data synchronously.

When you transfer data from or to a hardware driver synchronously, the calling thread is locked for the duration of the data transfer. Depending on the speed of the transfer, this can hinder other processes that require the calling thread. However, if an application requires that the data transfer as quickly as possible, performing the operation synchronously dedicates the calling thread exclusively to this operation.

Note  In most applications, synchronous calls are slightly faster when you are communicating with 4 or fewer instruments. Asynchronous operations result in a significantly faster application when you are communicating with 5 or more instruments. The LabVIEW default is asynchronous I/O.

 

Thanks Mark!

 

BR, Oscar

0 Kudos
Message 24 of 25
(1,372 Views)

@TMorgan wrote:

I had a very similar problem when using serial communication through a USB port for an agilent U1733C LCR meter. I would get a BSOD at random intervals between 5 minutes and 4 hours. After pulling my hair out for a few days, I came across this post. I found it had nothing to do with the drivers, but everything to do with using synchronous read/write VIs. Thanks for the suggestion Mark.


Actually it has all to do with the driver or more precisely with the USB COMM implementation on your device. usbser.sys is the standard Windows driver for USB devices that claim to be USB COMM compliant. When you use asynchronous VISA the driver gets send the asynchonrous command and then regularly checked if it is ready. In synchronous mode VISA just invokes the synchronous driver function and waits until it returns.

The difference being that in asynchronous mode LabVEW has an opportunity to do other things on that thread while waiting for the driver to complete its thing, but the driver being hit regularly to check that it has finished. In synchronous mode the LabVIEW thread is blocked and is simply waiting for the driver to do its thing. This does not hit the driver with asynchonous calls during the operation to check its status so it seems that somehow with some USB COMM devices the usbser.sys driver is not really thread safe and goes into nirvana.

 

VISA synchronous mode is a workaround for this problem but the error is really in the usbser.sys driver and/or the USB COMM implementation of your device.

Rolf Kalbermatter
My Blog
Message 25 of 25
(1,344 Views)