Separate VI for GUI and Main programs: Using global variables to share data

[Curious_Mal]

Hi,

I'm newish to labview (only done core 1+2 courses) and have recently been assigned the project of writing labview programs for our engineering test labs. 

The common format used there is to separate the 'Main' program (which performs the computation, calls subvi's etc), from the GUI.vi user interface (which only displays data, does not include any loops, calculations etc).

Global variables listed in the project window are used to share data between Main.vi and GUI.vi; for example booleans (start stop), numeric data etc.

The issue is that as the complexity of the GUI grows the list of global variables increases, adding what may be unnecessary complexity to the program setup.

1. Is this a common layout, or can anyone advise why it has been done this way for several years by previous employees here?

2. Is there an alternative to using global variables which might reduce the size of the list that needs to be shared? Perhaps clusters of elements, or arrays of data?

3. Would you recommend an alternative structure: perhaps just using the front panel of Main.vi to display all the data? Are there disadvantages to not separating GUI and Main, or is using the front panel of main a common layout for larger more complicated program structures?

Interested to receive your feedback.

Thanks in advance

[GerdW]

Hi Mal,

1. It might be "common", but isn't recommended.

why it has been done this way for several years by previous employees here?

You should ask them, not us…

2. Yes, clusters and arrays will help.

3. You can use producer-consumer schemes to send data from one loop the another loop…

the GUI.vi user interface (which only displays data, does not include any loops, calculations etc).

There is no loop in the GUI VI? How do you react on user input?

[crossrulz]

1. It is very common and useful to separate the GUI from the rest of the application.  If you have time you can look into the Model View Controller (MVC).  It is also common to break up the tasks even more into different loops, the basis of the Actor Framework.

2.

Look into the Queued Message Handler (often incorrectly called a Queued State Machine).  The idea is to use a Queue to send messages to the model (what you called "main").  The common data type in the queue will be a cluster of String and Variant.  The string tells you what the message is (Stop, New Set Value, etc) and the variant can hold any data needed for that message.  The model can do whatever it wants with the message data including updating variables stored in Shift Registers.

For sending data to the GUI, I really like to use User Events.  There is a slight learning curve to them, but they are extremely useful since they work with the Event Structure, which you should be using already for a GUI.

So to summarize: you are abusing Global Variables.

[Yamaeda]

1. No, it sounds they they got stuck in bad design choices.

2. Sure, you can use both clusters and arrays as globals. I'd look into OOP for data encapsulation and sharing instead.

3. Most of my programs are relatively small, so i generally use a Producer/Consumer with all needed data in the consumer. The downside of not separating is ofc. that many changes to the UI will affect the data part and the opposite. With OOP this is reduced and i can switch between emulated and real hardware easily.

/Y

[Curious_Mal]

Hi Gerd,

1. Although only implicitly stated, I can't ask 'previous employees', as they no longer work here.

3. My bad: They are generally just a massive while loop passing data between user inputs/outputs and global variables.

Thanks

[Curious_Mal]

@ Crossrulz,

Your solution is very interesting, thanks.

Do you have any vi examples of UIs and Models you would be willing to help me get my mind around implementing it.

Thanks,

[Yamaeda]

For Gerds #2 (and my #3) you can use File -> New ... -> From Template -> Producer/Consumer (Events) as a good start.

/Y

[crossrulz]

Queued Message Handler using Variants

[billko]

I guess one important question here is:

What is the scope of the project?  Are they expecting you to redesign the application, or do they expect you to use the existing code as a template?  I suppose that by the time the project got handed to you, the dollars were already allocated, so you don't have any input here, but it will determine the approach to use.

[JÞB]

---

@Curious_Mal wrote:

Hi Gerd,

1. Although only implicitly stated, I can't ask 'previous employees', as they no longer work here.

 Would you like to hazard a guess as to "Why they no longer work there?"  It might be that they chose an architecture that caused severe problems with race conditions and scalability leaving them incapable of making minor changes in a timely manner without introducing new BUGs caused by race conditions.

If they had fired a User Event like "Change Value Array K" with event data type of Array K and Data of K'  Well, you might still be looking for a job.  Easy enough change to fix those Global Variables quickly - just replace the write globals with Generate User Event_Variable and limit the event queue to 1 occurrence. (The UI doesn't need EVERY change it needs to show the most recent data)

---

---

---

3. My bad: They are generally just a massive while loop passing data between user inputs/outputs and global variables.

No, the last user's bad. Fix it!

Thanks

---

Yup, you are welcome.