Labview stops execution of one loop when a dialog box is called in another loop

[scrook]

Hello all,

I have a multiple loop program (one loop does data acquisition, one for analysis, and another for error handling). If either the acquisition loop or the analysis loop has an error, I have it passing that error to the error handler loop by way of an array of functional global (basically it loads a FIFO buffer that the error handler loop pops errors off of one at a time).

The functional global handles writing the error to a log file when a new error is pushed into the buffer. All I need the error handler loop to do is to show a dialog to the user so that they know something has happened. I had been using the built in dialog box VIs to do this but I notice that they seem to pause the other loops as well. I would like to find a way around this as I have gotten to the point where the program can recover from most of these errors that stem from hardware communication issues automatically.

Essentially what I want to do is have a popup box that will alert the user that something has happened but not pause the data acquisition or analysis loops so that I am still getting data from the rest of my devices even if one of them has a problem that my program can't solve on it's own.

[rolfk · Accepted solution]

Create your own dialog. LabVIEW subVIs can be made to show their front panel and set to look and behave like a dialog.

[chilly_charly]

This is a classic question. You could run a "splash screen vi" programmatically, using the vi server functions. Don't forget set the Wait Until Done" input to false, and to programmatically close the front panel when finished. This way, your messenger vi will not interfere with other operations.

[scrook]

@Charly

Thanks for the info on using VI server for this. Since either of the two solutions in the replies to this thread involved me creating my own dialog VI to replace the built-in LV ones, I tried just replacing the LV dialogs in the error handling loop with the custom VI and that solved the problem.

[altenbach]

---

@scrook wrote:

The functional global handles writing the error to a log file when a new error is pushed into the buffer. All I need the error handler loop to do is to show a dialog to the user so that they know something has happened. I had been using the built in dialog box VIs to do this but I notice that they seem to pause the other loops as well. 

---

The problem is the fact that your funtional global is interactive, so the dialog will stall everything that calls the FGV. This does not sound like such a good idea.

I recommend that you re-architect the FGV and have a parallel loop in the main program query the FGV for errors a few times per second and pop up the dialog if something interesting happens.

Another alternative would be to simply have a text indicator on the front panel of the FGV, where you errors are appended (or prepended) as a new line. This way the FGV is not interactive and can complete in an instant, even if an error occurs. If an error occurs, you can pop the FP topmost and still complete the current execution right away.

[scrook]

Altenbach,

The funtional global itself does not contain the call to the dialog. Basically what I am doing is this:

At the start of the loop, the FGV is called and one error (if any exist) is popped from the stack. This is then output to a separate VI which contains the dialog.

The way I wrote the first post makes it seem like the dialog may be prompting the user as to where the log file should be written but this is not the case. All that is happening is that they are being notified that something has happened. For example:

Loop A has an error of some sort. It calls the FGV using the 'Push' command. The FGV will write the incoming data to the log file and also add the information to its stack so that it can be used by the error handler loop.

The error handler loop calls the FGV using it's 'Pop' command. The FGV releases the first item from the buffer and outputs the error to its output terminals. These output terminals feed into an error handler VI in the same while loop which determines what (if any) dialog to display to the user.

After removing the Labview built in dialog functions from the error handler VI and replacing them with a custom dialog VI the problem went away completely. The way I've been testing it is to disconnect one of the pieces of hardware from the PC running my Labview software while the VI is running. Before, I would see a hole in my data for all channels on all devices until the user dismissed the dialog. Now, all that is missing is the data from the specific device between the time the cable is disconnected until the time it has been reconnected.