How do I terminate a VI if it causes LV to hang?

[Josu]

While running LV, I use a third party VI that communicates with hardware through a RS-232 port.   Most of the time this VI functions fine and the hardware appears to be controlled properly. 

Typically I will be running my LV program for long periods of time without any issue (24/7), but there will be times where LV will hang and it appears to be happening while running the 3rd party VI that controls my hardware through a serial port.

What is very strange is that when I notice the program hanging, if I click the mouse a few times the program no longer hangs the last command I gave to the hardware appears to be executed  and my program will continue to run fine (it once stopped at 3am and then worked fine when I came and clicked the mouse at 9am in the morning).

One problem to debugging this issue is that it doesn't seem to happen with any regularity. 

Thus rather than try to fix the problem within this 3rd party VI (which I should say calls VIs from a dll that was given to me by the 3rd party), I would like to know the following:

I would like to know if there is a way that I can run this VI and if this VI hangs or has some internal problem, is there a way to quit this VI after a timeout, of say 5 seconds?

It seems like I would be able to do this with an event structure, but I am not really seeing how I could do this since it seems that I need to finish the 3rd party's VI to run the event structure.

I should also say that I am using a BNC-2110 & PCI-6259 to do DAQ and controlling another piece of hardware through an Ethernet control.  I don't think these are causing any conflict because the hang always happens while calling the 3rd party VI that uses the serial port to communicate.

Running LV 8.6 on WinXP SP3

[RavensFan]

You'll be able to program in something to allow the VI to stop in the event of a timeout and restart, but there is no global VI way to do it.  You'll first have to figure out exactly where the holdup is in your VI.  Is it at a serial port call?

You will need to add numerous indicators to your code with clearly identified names.  Look at thinks like a Loop counter.  If it pauses, you'll know which loop has frozen.  Perhaps some timer values  between different sections of code.  If you see a timer that doesn't seem to be getting updated and has an older value, you know the code has paused somewhere before that.  You may even want to create a subVI that writes a note to a log file every time it executes with a timer value.  That way you can review your log file later.

Once you know where your code freezes, then you can figure out the best way to work around it.

[Michelle_N]

Josu,

This is a strange issue. Obviously the best thing to do is to talk with the third party developers and have them debug their code. As far as error handling goes, well, is there any error handling in the code right now? Is the error cluster wired up inside their VIs? If so, check the settings of the error handling VI (either simple error handler or general error handler). I assume they are calling a DLL using Call Library Function node? This should throw an error if one occurs and the error handler at the end of the code will specify how this error is handled, i.e. display a dialog box, give the user the option to stop execution when an error occurs, etc.

Does this make sense?

[Coq_Rouge]

In your case i would ask the vendor for the instrument protocol. Since it is a serial instrument it shuold be an easy task to build your own instrument driver with proper error handling. Also check your cabling. Maybe somme of the data is lost. If the driver dll has no timeout functions it will hang in a loop waiting for n bytes, and block the rest of the system.