LabVIEW
file dialog blocks all asynchronous vi calls
Solved!
Hi BIN,
@BIN-Versuch wrote:
i have the problem that when the LabView file dialog is open, all asynchronous VI calls are blocked in all other program parts.
Yes. Read this for background information.
@BIN-Versuch wrote:
Is there any solution for this problem?
What are you doing in parallel to the FileDialog? Which specific async calls are blocked?
Hello GerdW,
thanks for the fast respond.
My application is divided into several modules with different tasks, each with its own loop. One module is responsible for data recording. If the file dialog is opened in this module, the asynchronous calls are blocked in all other software modules.
These other software modules are responsible for data acquisition or control the test process. Blocking the asynchronous VI calls results in delays in the test process, which must be prevented.
I understood the problem from the article you linked, but I don't quite understand how to solve it.
The asynchronous VI call is executed as shown in this picture.
Best regards,
BIN
@BIN-Versuch wrote:
I understood the problem from the article you linked, but I don't quite understand how to solve it.
Who said it can be solved?
You can try to work around it...
For instance, maybe you can open the VI reference once, and keep the reference?
If you just want to dynamically switch modules at run time, why not use static VI references? The Open VI Reference would not be needed. Static VI References solve a bunch of other problems as well (like automatically including VIs in executables).
A drastic (yet very appropriate) solution would be to use OO. It is basically polymorphism what you're reinventing here.
A module child class would follow a parent or interface class's connector pane, and VI server wouldn't be needed at all to execute the method.
You'd still be advices to load the module classes op from. I haven't tried if loading a class from disk waits for idle root loop, but it wouldn't surprise me.
Search LabVIEW like a graph! 
@BIN-Versuch wrote:
Hello,
i have the problem that when the LabView file dialog is open, all asynchronous VI calls are blocked in all other program parts.
Well your description is NOT entirely correct. It is not the asynchronous VI call that is blocking but the Open VI Reference since it needs the access to the LabVIEW UI thread for synchronization reasons as it changes global state of the LabVIEW environment
Is there any solution for this problem?
So yes there is a solution to your problem if you can do the Open VI Reference at some point during initialization of your program and then stash that reference somewhere and only perform the Asynchronous VI Call at runtime.
And the other recommendation about using static references is also a good one. It solves also the problem that you can not forget to add the VI in the Build Specification as Always Included.
A module child class would follow a parent or interface class's connector pane, and VI server wouldn't be needed at all to execute the method.
That would not really help. If the class is not already preloaded at some point LabVIEW still has to load the class and all its VIs into memory and that is done by doing something akin to Open VI Reference too, just on a lower level hidden under the class handling.
@rolfk wrote:
A module child class would follow a parent or interface class's connector pane, and VI server wouldn't be needed at all to execute the method.That would not really help. If the class is not already preloaded at some point LabVIEW still has to load the class and all its VIs into memory and that is done by doing something akin to Open VI Reference too, just on a lower level hidden under the class handling.
Well, it would help to avoid call by reference.
I never had any luck getting Call And Forget\Collect working in a way that VIs didn't lock or LabVIEW didn't crash. I avoid those functions, and prefer a call to a DD VI.
I tested, and it seems that, at least if the class is in memory, "Get LV Class Default Value.vi" is not blocked by a file dialog nor a menu. Of course, if the VIs are in memory, there's no loading. However, Open VI Reference does block if you use a path, even if the VI is in memory.
Here's my test, I run it, then trigger a menu:
Just tested this with a class that is not in memory, and it doesn't wait for the root loop.
wiebe@CARYA wrote:
Well, it would help to avoid call by reference.
I never had any luck getting Call And Forget\Collect working in a way that VIs didn't lock or LabVIEW didn't crash. I avoid those functions, and prefer a call to a DD VI.
Just wanted to give another opinion on the Call Forget/Collect method. I use it quite extensively and rarely if ever do I call the Run method. I use it often with subpanels, as well as dialogs. When calling Vis without a defined (or known) connector pane, or running VIs with mixed connector panes, I'll obviously not use this method.
But I generally use it as others have said here. In the init of the application or state machine (QMH, etc.) I'll get all the references to things I need, open them, and run them. Then as they are needed I'll insert them into subpanels or show them as needed. Then these references are closed on closing the application. There are occasions when I'm opening and closing VI references mid application, but it isn't often. I designed the application this way mostly because it follows the Open, Acquire, Close designs of DAQmx, where you open once, and close once, but there isn't anything inherently wrong with accomplishing this in a different way, as long as you can avoid root loop issues.
