LV Dialog box holds Open VI Reference

[eberaud]

Hi,

 

I am facing a weird situation and would like to get your insights. My application is quite large (>1000 VIs). When I run it, an initialization phase takes place, and around 10 or 20 objects are created (LVOOP). Most of these objects start their engine using the Open VI Reference and then the Run method. If they encounter any warning during that phase, they enqueue a message to display, and a dedicated VI keeps checking this queue and opens a LV Dialog (with just a OK button) when it finds an element. The purpose is to allow the initialization phase to continue instead of waiting for the user to acknowledge the window. Then when the init phase is complete, the user can just acknowledge all the dialogs one after another. (usually there is like 1 or 2, not much more).

 

I ran my code this morning and was surprised to see that the init phase would still wait for me to acknowledge the dialog. A few probes showed me that the application was stuck in one of the Open VI Reference call. After I acknowledge the window, it would process normally.

 

I am wondering what is causing this behavior and whether it is a known issue. Could it be related to the fact that the Dialog is modal and somehow holds the thread in which the Open VI Reference executes? This is weird, because other complex operations (connecting to a database,...) manage to execute while the dialog is open...

 

Thank you very much for your help

 

Emmanuel

[drjdpowell]

I would suspect it is a “Root Loop” issue.  I know that Open VI Ref can require LabVIEW’s Root Loop, and this loop is blocked by the User opening a menu.  Perhaps a LV dialog also blocks root loop?  

BTW, if it is Root Loop, then a method used to get around this problem is to use a single reference to a pool of clones to do all asynchronous running of VIs.  Then the ref is only acquired once, before any action that blocks root loop can happen.  The latest Actor Framework’s “Actor.vi” is an example of this.

[eberaud]

A quick google search led me to this article: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Change-one-and-two-button-dialog-windows-do-they-do-not-block/idi-p/983941

 

You're right, the 1-button and 2-button dialog box uses the root loop, but the 3-button does not, so I could work around the issue by replacing my dialogs with the 3-button version. It works great now.

 

Thank you for pointing me to this "root loop", I had never heard of it before, and wouldn't have found that article that easily without this keyword!

 

Regards

Emmanuel

[drjdpowell]

As a word of warning to anyone reading this, be aware of the issue of Root Loop blocking by things such as the User opening a menu.  Safety-critical code must never be dependent on Root-Loop blocking functions, such as “Open VI ref” or “Run VI”; the User can open a menu then walk away.  If in doubt, test it by opening a menu and leaving it open just before your critical code executes.  If it doesn’t execute until you dismiss the menu then you have the problem.  The simplest fix is to open necessary references once at the start of the program, and use the ACBR node instead of the “Run VI” method.

[Aristos Queue]

An example of how to safely set up the ACBR call is in

  vi.libActorFrameworkActorLaunch Actor.vi

in LV 2013 and later. Thanks to drjdpowell for catching that one -- myself and the rest of the AF community missed it.

[Mads]

That is an interesting tidbit. I've so far thought that the only way to avoid getting blocked by the root loop was to populate the asynchronous call pool (and hope that the pool is large enough to meet the demand during a blocking event...).  Populating the call pool is only required for a speed gain then, or?

[Aristos Queue]

Populating the call pool is required if you're making synchronous subVI calls and not going through the asynch call by reference node. The synchronous subVI call has better performance (because LV knows ahead of time exactly what subVI to prepare to call and all it needs is the memory instance, whereas there's a lot more unknowns around any of the call by ref nodes).

[drjdpowell]

 I've so far thought that the only way to avoid getting blocked by the root loop was to populate the asynchronous call pool (and hope that the pool is large enough to meet the demand during a blocking event...).  Populating the call pool is only required for a speed gain then, or?

Getting the ref with “Open VI Ref” is blocking, but increasing the size of the pool when needed does not, so there isn’t a need to prepopulate the clone pool.  

 

On my benchmarks adding an extra clone is about 1000us, while reuse of a clone in the pool is about 100us (LabVIEW 2011).  

[Mads]

Populating the call pool is required if you're making synchronous subVI calls and not going through the asynch call by reference node. The synchronous subVI call has better performance (because LV knows ahead of time exactly what subVI to prepare to call and all it needs is the memory instance, whereas there's a lot more unknowns around any of the call by ref nodes).

 

The *asynchronous* call pool is only required for synchronous calls? Was it not introduced with the async call by reference node in the first place?

[Aristos Queue]

The *asynchronous* call pool is only required for synchronous calls? Was it not introduced with the async call by reference node in the first place?

Oh, that... sorry... I was thinking about the shared clones reentrancy pool for subVIs.

 

The prepopulation of the async pool just helps with performance -- you get all the allocation out of the way early and then start making calls. But if you run out of the pool, there's no danger of not being able to allocate more because of root loop, whereas there is with other types of allocations.

Edited May 28, 2014 by Aristos Queue