Showing results for 
Search instead for 
Did you mean: 

Call Library Function node timeout


I'm using an external DLL that freezes sometimes and blocks all my LV application. I would like to generate a timeout to stop the DLL if it takes too long to send an answer to LV. I do not have access to the DLL code, so I would have to implement this in the caller VI. I cannot simply abort the execution because I need to alert the user that something gone wrong.

The unique solution I could imagine is:

1)      Generate timeout;

2)      Start error procedure (close files, send email alert, etc);

3)      Abort execution.

Aborting execution can generate several errors and let the system unstable so it would be really nice to stop only the Call Library node or just the subVI that calls the DLL. Is it possible? Does anyone have other suggestion?



Message Edité par Rasputin le 10-13-2006 08:51 AM

LV7.1 <> W2K
0 Kudos
Message 1 of 8
Forgot to say: I'm using LV 7.1 under W2K
LV7.1 <> W2K
0 Kudos
Message 2 of 8
There was a similar discussion some times ago. The result was that the DLL call should be done in a separate process.
This means the main program would need to load an external EXE and control it some way (VI server should be OK, I guess).
The external EXE should wait for an input, upon which it should call the library and return the output; it should also abort itself in case of failure.
Not so easy and not very efficient, indeed.
LV 7.1, 2011, 2017, 2019
0 Kudos
Message 3 of 8
Thanks, Paolo.
Since the freezing is very rare, I'll try to run a parallel loop to generate the timeout, send alerts and abort the execution. Smiley Indifferent
If I find out a better way, I post it here.

LV7.1 <> W2K
0 Kudos
Message 4 of 8
Unless the DLL has code to accept an abort request, this won't work. The problem is that the thread has left LabVIEW and gone into the DLL. We can't abort the VI execution until it returns. If the DLL never lets go of it, the VI will never stop. This is the reason that the seperate process is recommended - you can simply have the OS kill the process, no matter what the DLL is up to.
As you say, however, this is not very efficient, but it's the only way to ensure it works.
fyi, just killing the thread also is not an option - the OS provides no way to clean up any resources used by the thread (any semaphores taken, etc) if it's killed...only killing a process does that.
That being said, you can use the parallel loop to at least let the user know what is happening and have them kill the's better than nothing.
Of course, if the DLL does have an abort option, and that works when it hangs (not a bug in the DLL code), then you're home free.
Message 5 of 8



I was wondering if there is a better way to do this in LabVIEW 2011.  The original post was from 2006 and LV7.1 was mentioned.  I am having the same issue and was wondering if there was another method besides creating a seperate exe to wrap the dll call.




0 Kudos
Message 6 of 8

All of the above comments are still relevant.  There have been no changes in LabVIEW that would allow you to abort a call to a DLL.

Message 7 of 8

 I've made somewhat of a workaround; using the Application Control functions, I use my main VI to run a separate VI (make sure Wait Until Done is false). The main via writes some data to a file, starts the new VI (which runs the DLL function), and waits for 3 seconds for a response file to be written. If it doesn't find the response file within that time, it force closes the separate VI. There's probably a better way to communicate data from one VI to another, but writing files was easy for me to whip together.

0 Kudos
Message 8 of 8