LabVIEW
Message "Resetting VI" hangs LabVIEW
@_Y_ wrote:Could it be that blocking happens in one process but LV message shows other VI?
Queues are highly optimized, so queue interaction with a VI that hangs might make it hang (too).
I don't recall every seeing that, but doesn't rule it out.
Search LabVIEW like a graph! 
Thank you,
If I understand correctly the problem is caused by some kind of aborting command. Unsuccessful aborting of course.
The whole program does not close when the message appears. So, the only suspect left is Invoke Node Abort VI. Several such nodes are in the code, but they are called on timeout, i.e., when VI does not stop on its regular stop command.
The strategy: I shall identify which Abort VI is called, and then why. In this way, the cause of the blocking could be localised. Besides, I shall log the order of asynchronous calls.
I shall comment on results but it could take a time. The error is very rare.
wiebe@CARYA wrote:
Sounds like you would be able to use parallel execution of a for loop in stead.
This solution is simple and beautiful but is not suitable for this project. Deinitialie.vi-s are started asynchronously but not simultaneously. There are many such VI-s overriding an abstract method of a parent Interface. Some of them are started only when certain others are accomplished. F. ex. a CAN communication process cannot be deinitialised before all CAN-communicating devices report the accomplishment of their deinitialisation.
@_Y_ wrote:
Thank you,
If I understand correctly the problem is caused by some kind of aborting command. Unsuccessful aborting of course.
The whole program does not close when the message appears. So, the only suspect left is Invoke Node Abort VI. Several such nodes are in the code, but they are called on timeout, i.e., when VI does not stop on its regular stop command.
The strategy: I shall identify which Abort VI is called, and then why. In this way, the cause of the blocking could be localised. Besides, I shall log the order of asynchronous calls.
I shall comment on results but it could take a time. The error is very rare.
wiebe@CARYA wrote:
Sounds like you would be able to use parallel execution of a for loop in stead.
This solution is simple and beautiful but is not suitable for this project. Deinitialie.vi-s are started asynchronously but not simultaneously. There are many such VI-s overriding an abstract method of a parent Interface. Some of them are started only when certain others are accomplished. F. ex. a CAN communication process cannot be deinitialised before all CAN-communicating devices report the accomplishment of their deinitialisation.
I think that you might be trying to solve something that is actually unsolvable. I've found that if my app has gotten to the point where I think that only an abort is going to save things, it's probably so screwed up that that's not going to work, either. Usually it means that things have gotten so far out of hand that nothing is going to save it. I think the only thing left is to kill it with task manager.
So if possible, try to solve to root cause instead of applying the Band-Aid® to a mortal wound.
@_Y_ wrote:
@billko wrote:
So if possible, try to solve to root cause instead of applying the Band-Aid® to a mortal wound.
Yes Bill, this is what I try to do, i.e. search what could be the root of the problem. And I have a suspect now.
There is a solution that probably works as Abort:
- Clone of reentrant VI is started asynchronously.
- Method Deinitialise.vi sends command to stop the process then kill its reference.
- In some cases the process itself kills own reference when the main work is accomplished.
Killing reference of cloned VI stops execution of this VI. I suppose it works in the same way as Abort button. Is it so?
Please clarify! If you open a VI reference with option 0x80 it will actually invoke the VI as Call and Forget and you end up with a cloned VI reference in the VI itself and the original reference that Open VI Reference created. Closing the second will NOT abort the asynchronous VI.
If you use 0xC0 instead, it gets even more "messy". Each time you call the Call Asynchronous node, you create a new clone of the original VI. And each of those clones gets its own refnums but the original refnum from the Open VI Reference also remains valid. And closing this will again not close the actual clones.This is in fact a cool trick if you want to avoid lengthy delays in instantiation of multiple clone VIs of a specific asynchronous template. The Open VI Reference with either a path input or a typedef connector pane (needed for Call Asynchronous) connected, will always synchronize with the root loop in LabVIEW. This incurs a potentially lengthy delay in the execution of the Open VI Reference. If you instead use option 0xC0 and store that refnum in a shift register or something, you only incur that delay once and the actual instantiation of the clone through the Call Asynchronous node is much much faster and can be done over and over again, as often as you need such a clone!
So if you talk about killing the cloned VI reference inside the clone itself, then yes that could abort the VI. But you shouldn't pass out that reference from the clone under any circumstances as it indeed would give anyone including your greatest enemy to grab that reference and do bad things.
Instead you always should use queues, notifiers or similar to actually talk with that clone! Even a f*cking global variable would be almost better than exposing the Clones VI reference to the outside world.
@_Y_ wrote:
@rolfk wrote:
So if you talk about killing the cloned VI reference inside the clone itself, then yes that could abort the VI. But you shouldn't pass out that reference from the clone under any circumstances as it indeed would give anyone including your greatest enemy to grab that reference and do bad things.
You give very important explanation. Could you point to some article where this problem is discussed in details?
Even if you can abort the VI dynamically (I don't see why), it wouldn't solve the resetting VI problem.
The problem with the resetting VI is in fact that the VI is aborted, while the execution hangs in the dll.
If it's your own dll, you can make it monitor a VI reference, and stop looping if that VI stops running. However, the VI you monitor can't be the VI that started the dll, as this VI won't stop running until the dll stops. So, you need to dynamically start a VI that monitors the VI that starts the dll, and make the dll monitor that dynamic VI.
