Question about dialog pop-up windows

[spaceman_spif]

I have a program that runs two test units independently with one LV program.  It contains two separate while loops where each one will run a unit through mutliple tests and watch for any faults.  When a fault does occur, a one-button dialog window will pop up to alert the operator.

This weekend, a test stand had two units running and one of the units had a fault that occured during the night, so no one was present to reset the fault for a long time.  While that fault dialog window was up, though, the other unit seemed to "freeze" and did not cycle any further in its testing until someone came in a day or so later to clear the dialog window.

Does a dialog window cause everything running in LV to "stop" until the window is cleared?

[Gregory]

No, the dialog box will just not let things run that are waiting on it. Does the dialog box come from a VI that both loops use that is not re-entrant?

[zou]

Depands on how you programmed it.

If shared SubVIs not reentrant, then Yes, it will get locked up.

Any shared HW ?

[spaceman_spif]

This is my first time messing with "re-entrant" vs. "non re-entrant" so I'm reading over the info in the help section right now.  The two while loops do utilize several of the same subVI's, as they are almost identical programs.

Because of that and based on what I just read, it sounds like I should select "Shared clone reentrant execution" under the properties for my VI.  Does that sound right?

[mikeporter]

The dialog box will block the further execution of the process that called it. As was pointed out, depending on how your code is written this can have the effect of freezing your entire application. However, there are ways around it.

This might provide some additional questions insight...

http://www.notatamelion.com/2014/12/02/adding-a-non-blocking-dialog-box/

Mike...

[Gregory]

---

@spaceman_spif wrote:

This is my first time messing with "re-entrant" vs. "non re-entrant" so I'm reading over the info in the help section right now.  The two while loops do utilize several of the same subVI's, as they are almost identical programs.

Because of that and based on what I just read, it sounds like I should select "Shared clone reentrant execution" under the properties for my VI.  Does that sound right?

---

Yes, that will probably fix your problem. You can only run one instance of the non-reentrant VI at a time, and anywhere else it is called will be waiting on that instance to finish.

One thing you would not want to be reentrant is an action engine / functional global. If the data is manipulated each time and it is called from two places at once, it is anyone's guess which data is left in the shift register after both executions finish. This is called a race condition.

[tst]

---

@spaceman_spif wrote:

When a fault does occur, a one-button dialog window will pop up to alert the operator.

 

Does a dialog window cause everything running in LV to "stop" until the window is cleared?

---

What the others said about reentrancy, etc., is all correct, but when I hear these questions, the keyword that pops to mind is "root loop", which is a separate topic from reentrancy and more subtle. I didn't remember whether the one button dialog blocks it, but a quick search indicates it does - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Change-one-and-two-button-dialog-windows-do-they-do-no...

Read that to see what you can do.

[Sam_Sharp]

If I want a dialogue to appear that is non-blocking - I create a VI, set it to floating and then dynamically launch it from my 'call' VI using an asynchronous call by reference node. Depending on the behaviour you want, you can either make this VI appear only once (like a modal window) or multiple times (e.g. multiple windows - one for each fault?). In either case - the process that called the dialogue can continue.

The dialogue itself is usually pretty simple - an event structure with a couple of buttons. Perhaps an event/mechanism to handle someone closing the application with the window open (so your dialogue doesn't hold your application in memory after everything else has shut-down).