LabVIEW
Message "Resetting VI" hangs LabVIEW
I encounter a strange problem when asynchronously running multiple clones of reentrant VI.
LabVIEW shows modal dialog Resetting VI
The dialog hangs forever. I can only kill whole LabVIEW development environment from Windows side.
- The problem does not appear often but probably once per several hundred runs.
- The clones are started using VI Server, i.e. Invoke Node Run VI. Max number of clones of the same VI is 12.
- The VI does not communicate with any equipment. It sends and receives eventual messages via queues and works with HD using VI-s of Configuration File VIs pallete.
What could cause such a behavior?
Thank you.
In general code that is keeping other code from running (or makes something run very slowly) is called "blocking". In LabVIEW, it is often a driver that crashes, leaving LabVIEW hung.
I've mostly seen this happen when I am impatient with the code exiting normally and I just abort it. Then the resulting ungraceful exit causes the message and the hang. I think this is a symptom rather than a cause. I think that by the time I click the abort button, it has already hung, and that message is the last-ditch effort to unstick the program.
This link also says, "- It can also appear when LabVIEW has to wait for all processes to terminate before it shuts down. One work around is to wait longer before closing out of LabVIEW." So maybe your error handling causes the application to try to shut down gracefully, but something is still running in the background when the application terminates. In your case, maybe something crashed your app, it tries to exit gracefully, but whatever crashed your app makes it impossible to exit. Are you using dlls? Maybe a dll occasionally has an error happen inside of it and it doesn't exit gracefully, causing LabVIEW not to be able to exit gracefully. Of course, this is all a wild speculation.
You claim that you do not access hardware, but the name of that class, TrinamicMotor.lvclass really would suggest otherwise.
If you call functions that access DLLs this can happen if the DLL function keeps hanging. LabVIEW has no way of aborting a DLL call. It can just hope that the function eventually returns but if that DLL is not written 100% perfect it can keep hanging in some function, including the close or cleanup function as it waits on something else that supposedly is still busy using the resource.
For instance the DLL may be locking the resource with a mutex, and every function has to acquire the mutex to be able to access the hardware. For Motion applications this is very common as you do not want a function to get interrupted while it is handling an axis by another call trying to change the same axis under its nose. Each function is supposed to release that mutex after it finishes and before returning to the caller but sometimes it happens that such a function runs into an error and returns to the caller to report that error and forgets to release that mutex. Any other call after that trying to acquire the mutex will hang indefinitely in that attempt to get the mutex reserved and the original function that acquired it will never go and release it. LabVIEW can't abort the DLL function, and the DLL function will never return before it could get the mutex which it will never be able to get in this case. Classical Mutual Exclusion lock happened!
So why is that class called TrinamicMotor when it does not communicate with any hardware anywhere?
@_Y_ wrote:
The project calls several DLLs but this VI does not. Sub-VIs don't call DLLs too.
Could it be that blocking happens in one process but LV message shows other VI?
Only so called synchronous VIs (and the Call Library Node) can cause this dialog. Now many VIs in LabVIEW are synchronous, but they can not block for a long time so that means at worst case they will delay the closing a little.
For the Call Library Node there is no way around that, if the function doesn't return LabVIEW can't force it.
For VISA functions, which call the VISA32.DLL under the hood mainly the VISA Read can be problematic, but the VISA functions can be changed to asynchronous through a right click menu option. In that case the node will setup an asynchronous call and then regularly poll the VISA driver if the current operation has completed. This way control stays in LabVIEW and LabVIEW can abort that loop at will. Drawback is that that polling costs some extra resources and can in extreme cases make the communication end up being slower than with synchronous operation.
All the network functions that can take longer such as TCP/UDP Read/Write are fully asynchronous and LabVIEW can abort them if needed even if they are waiting in an indefinite timeout. Same about Queue, Semaphores, Notifiers and Rendevous (a Queue under the hood).
So unless you found a bug with Queues somehow, which is pretty unlikely after abot 15 years of queue implementation in the current way, you must have some synchronous function in that VI or in one of its subVIs that blocks when LabVIEW tries to abort it.
@_Y_ wrote:
@Bob_Schor wrote:
Do you maintain separate references for your clone VIs, and use them to communicate with your Clones?
Thank you Bob
No, references are terminated immediately. These clones (methods of corresponding classes) communicate with other processes via queues, update attribute of the class then disappear. As a rule, everything works well. The problem is very rare.
Sounds like you would be able to use parallel execution of a for loop in stead.
Search LabVIEW like a graph! 