LabVIEW
Troubles stopping a VI
Hello everybody, I hope someone can help me.
I got a main.
Main calls a SubVi.
SubVi controls an external device using some dll's that the manufacturer provides.
Problem is: it may happend, (depending on some other external devices) that the controlled device will lock and the dll never returns.
What happend is that everything is locked: I cannot control the SubVi and even the Main.
Abort button doesn't work. Front panels doesn't refresh. Windows close buttons are not working.
But Windows do reacts to mouse and keyboards.
The only thing I can do is to open task manager and terminate Labview.
So I thought to make the SubVi as indipendent as possible, but it's harder than I thought.
I made the SubVi run by using an Invoke node, and the parameters to the SubVi are passed by a queue, but this doesn't solve the problem.
Seems that the locked up dll interfere with Labview at a deep level.
I prefer not to make it a build application, in case this might solve the problem (I don't think).
How can I quickly make the SubVi an indipendent exe software, which is launched with a DOS line ?
Or will it use the Labview engine as well so everything will lock up still ?
This is the only way to make it indipendent, IMO. The indipendet SubVi would then be killed ater some time has elapsed.
Isn't there a way to control a dll with a timer ?
Ok, too much questions for now. Thanks.
@Mark_Yedinak wrote:
@Ranjeet_Singh wrote:
Use one timeout option that will be good.
Instead of writing solution like this, why dont you post your VI (2011 format). Then debugging will be easy.
One more thing if your VI hangs that means your way of writing VI is wrong.
I suspect it is the dll itself that is causing the problem. If it is not thread safe it can create a situation where it prevents LabVIEW from being able to execute. If this is the case there isn't much that can be done in LabVIEW itself to solve this issue other than running the offending code as a separate process.
If you run the code as a separate process you would need to use TCP to communicate between your controlling process and your process running the dll. As you execute the second process you will need to do so in a manner that will allow the caller to return immediately and not wait for the process to complete. You will want to keep track of the process ID so you can terminate the process if it gets locked. I would suggest you use some sort of heartbeat message to monitor if the process is running or not.
The last suggestion would be to contact the dll supplier and see if they are aware of the problem.
I already sent a ticket to the support service ofhe device (a microcontroller programmer), althought I do not expect them to easly produce a new firmware release and/or a more robust dll. This burden, I think, falls entirely on me.
If, for example, the device doesn't see the microcontroller right from the beginning, the hardware gets locked but the dll returns and the Labview is still in control of the thread, so I am able to reset the device wtih a software command.
If the connection programmer/micro is lost during the programming step, however, the dll doesn't return and there's no way to gain control of the 3d again.
This should be quite a rare event, but it's catastrophic.
I will go down the solution you are suggesting me, althought I am not so familiar with TCP between applications and processes ID.
As a first attempt I will build an exe, using labview, which will be called with a dos line with parameters too. I am afraid that the labview engine would still be affected (but I am guessing here).
Thanks for the precious suggestions.
