Design Problem with GUI sub vi

[Johannes Eble]

Hello community,

in general, I would like to separate the GUI from the data, but I get
a problem with this design approach in LabView:

I often have sub VIs that are supposed to control something.
Therefore, these VIs consist of a control loop. A GUI window should
show the regulation process (showing how the tracking error is
hopefully approaching zero etc.). As I said, this GUI should be a
separate VI (separate from the control loop VI). Since the GUI has to
be updated on each sample, it is clear that the GUI VI should be
inside the control loop, and therefore, it should be a sub VI of the
control loop VI.
Now, the problem is that the control loop VI itsself is a sub VI
because the whole regulation is just a subsystem of the whole program
.
(The main VI doesn't have a GUI, but first starts a (GUI) input mask
for the same reason: separate the GUI from the rest).
But back to the GUI VI inside the control loop. I must check the 'Show
Front Panel When Called' option. But I can't check the 'Close
Afterwards if Originally Closed' option since the GUI VI would appear
and disappear in the control loop - according to the loop's sample
rate. However, if I don't check the 'Close Afterwards if Originally
Closed' option then the GUI VI will continue to show, even after the
control process is finished.
So in other words: I need the possiblity to close the GUI VI
programatically, after the control process is finished.


Any ideas?


Regards

Johannes

[BJD1613]

If you are familiar with opening a vi reference you can use the property of FP.Open. Pass a false to this property in the correct position in your dataflow and the front panel can be closed. Hope this helps.

[Tom_Hawkins]

I think you're on the wrong track trying to put your 'GUI VI' inside your control loop. It might be a better design to have the control and GUI handled by separate loops and use an appropriate method to pass data between the two, e.g. a global variable to pass the setpoint from GUI to control and a queue to pass readings from control to GUI. In fact, you could even split the GUI into two loops: one to read user input from the front panel controls and one to display data returned by the control loop. You may find it's more convenient to make the GUI the top-level VI and make the control loop a subVI of that (but outside the GUI loops).

[Johannes Eble]

Hi tmh,

thanks for your answer

On Tue, 11 Nov 2003 10:26:32 -0600 (CST), tmh wrote:

>I think you're on the wrong track trying to put your 'GUI VI' inside
>your control loop. It might be a better design to have the control and
>GUI handled by separate loops and use an appropriate method to pass
>data between the two, e.g. a global variable to pass the setpoint from
>GUI to control...

I try to avoid globals. Now, suppose I had multiple unrelated control
loops. I had to suppose a global variable for each of these
subsystems. I already use globals for the GPIB device IDs. I wouldn't
like more.

>and a queue to pass readings from control to GUI. In
>fact, you could even split the GUI into two loops: one to read user
>input from the front pa
nel controls and one to display data returned
>by the control loop.

But if I split the GUI: How can I view them simultaneously? The user
must see input and output simultaneously, in one window.


>You may find it's more convenient to make the GUI
>the top-level VI and make the control loop a subVI of that (but
>outside the GUI loops).

Your approach sounds interesting. Is there a sample for this
architecture in the examples?

Anyway, I have to point out that I have several unrelated GUI windows
in my application. There is no notion of a main GUI in my application.
The control loop is just one feature of my application, so it doesn't
make sense to use the control GUI as the top-level VI. At application
startup a user input form is displayed (it also has some sort of menu
selection). But even this window can't be toplevel since it provides
an Option radio button (that shows and hides controls, accordingly) a
CONTINUE button, and a STOP button which implies that the input
form.vi must be
in a loop.

The problem is that I can't send messages to windows in LabView as I
am used to in Win32/VC++.

Johannes

[Johannes Eble]

Hi BJD1613,

your approach seems to work and I will try it. Thanks very much.


Johannes



On Tue, 11 Nov 2003 07:45:47 -0600 (CST), BJD1613 wrote:

>If you are familiar with opening a vi reference you can use the
>property of FP.Open. Pass a false to this property in the correct
>position in your dataflow and the front panel can be closed. Hope
>this helps.

[Tom_Hawkins]

It's good that you want to avoid using too many globals - I'd only suggest them for a relatively simple application. Queues, notifiers or 'functional global' VI's could be a better option in your case.

>But if I split the GUI: How can I view them simultaneously? The user
>must see input and output simultaneously, in one window.

Use two separate loops on the diagram of one VI; one loop reads the front panel controls and the other collects data from the queue and updates the indicators. LabVIEW handles the multitasking transparently for you (one of the great advantages of LV over C++!).

>But even this window can't be toplevel since it provides
>an Option radio button (that shows and hides controls, accordingly) a
>CONTINUE button, and a STOP b
utton which implies that the input
>form.vi must be in a loop.

I don't quite understand this. If the input form must wait until the user clicks Continue or Stop, that implies that the form VI should *contain* a loop that reads those two buttons until one of them returns True. It could also contain a second (independent) loop that reads the radio buttons and shows/hides the other controls appropriately. The form VI doesn't have to be *inside* a loop in the calling VI to do these things.

I'm afraid I don't have the LabVIEW examples to hand at the moment, but maybe others can suggest examples to look at or you can find some by browsing. Hope this helps!

[BJD1613]

I would suggest you stay away from global variables. Especially in the same vi. A global variable should strickly be used for sharing information between vi's. Global variables can cause what is called a race condition or retrieving information that you are not expecting. I would suggest using an action engine architechture with a read and a write action. This will cause data dependency between both loops. On will write and the other will read. I think you original design is pefectly fine though if you just use the previous answer. Hope this helps.

[shoneill]

If the communication is one-way, launch the coltrol part using VI server to have it running parallel, and communicate with the GUI part using queues.

If it`s two-way, you can do something similar, but you might need queues going in both directions to pass data back and forth.

You can use occurrences to control the Stop/Start synchronisation.

This way you have the GUI no longer locked to the cycle frequency of your control loop, and you update whenever you need to, not when your control loop dictates.

I`m a relative newcomer to this approach, but it offers some great advantages, and I`ve really become fond of this approach. The code usually ends up looking much neater too (Which is never a bad thing).

Shane.