usb device times out, crashes labview

[tanimada]

I'm using a programmable spatial light modulator, communicating with my PC via usb.  the slm appears under "devices and interfaces->ports->COM3" in measurement and automation explorer.  the slm came with subvi's to use in applications, that work about 2/3 of the time.  when they don't work, i receive a timeout error, and when i stop my program, labview crashes and won't close, requiring a restart.  if i terminate labview via task manager (instead of trying to stop the program) and then check my instrument in MAX, i get a VI_ERROR_RSRC_BUSY.

first of all, i was wondering if anyone knew how to prevent this timeout error (beyond just setting the timeout to a higher value, as that doesn't seem to help; might i be somehow log-jamming the device or my com port with too many messages?).  and secondly, i was wondering if anyone knew why a timeout would crash labview.

[LuI]

Tanimada,

I think I can shed some light onto your situation, allthough it might not really help you out of your problems.

In your case, the SLM is using a virtual serial port to communicate with your app.. This involves some system drivers and maybe some DLLs.
The supplied VIs utilize those system components to initiate some actions within the SLM and to read data after the action have been finished. The actions in your SLM take some time and, in fact, do not finish within a given limit in your situation.
Your VIs return correctly with a timeout error, indicating that the SLM is still busy. In fact this might as well be caused by the device itself or by a faulty driver/DLL. In such a situation, when you received that error, you have to try to abort the action in order to free the driver/DLL. Otherwise it has locked some RAM and LabVIEW cannot proceed. Killing that process will probably lead to a bluescreen or similar.

What can you do?
1. Check the examples of the device driver VIs, if there are any supplied.
2. Try to open the VIs in order to understand their logic.
3. Read the device's manual and try to detect where the misuse is that you perform with your code. It is bad code in the driver,anyway, when you encounter such behaviour without any prior warnings. But often a develloper can not imagine that anyone would try to use the device or driver in _that_ way.
4. You might want to contact the producer, asking for examples and/or solutions to your problem.

Just my Euro 0.02!
Greetings from Germany!<br>-- <br>Uwe

[LuI]

Tanimada,

I think I can shed some light onto your situation, allthough it might not really help you out of your problems.

In your case, the SLM is using a virtual serial port to communicate with your app.. This involves some system drivers and maybe some DLLs.
The supplied VIs utilize those system components to initiate some actions within the SLM and to read data after the action have been finished. The actions in your SLM take some time and, in fact, do not finish within a given limit in your situation.
Your VIs return correctly with a timeout error, indicating that the SLM is still busy. In fact this might as well be caused by the device itself or by a faulty driver/DLL. In such a situation, when you received that error, you have to try to abort the action in order to free the driver/DLL. Otherwise it has locked some RAM and LabVIEW cannot proceed. Killing that process will probably lead to a bluescreen or similar.

What can you do?
1. Check the examples of the device driver VIs, if there are any supplied.
2. Try to open the VIs in order to understand their logic.
3. Read the device's manual and try to detect where the misuse is that you perform with your code. It is bad code in the driver,anyway, when you encounter such behaviour without any prior warnings. But often a develloper can not imagine that anyone would try to use the device or driver in _that_ way.
4. You might want to contact the producer, asking for examples and/or solutions to your problem.

Just my Euro 0.02!
Greetings from Germany!<br>-- <br>Uwe