Seperating User interface from the Application

[delbertson]

I’m working with Labview 8.2 creating a control application.  I’ve been working from the bottom up designing control functions for all the equipment I’m trying to control.

Each system has a Cluster as an input which is a type-def.  This allowed each block to be written and tested.  When each of these modules was complete, I took all the type-defs and bundled them into a cluster to make my application’s complete control cluster. See FlatPanel.vi attached.  That’s worked fine and has allowed me to get things working as I learned the Labview basics.

I’m now looking for a little advice as to how to set up my final application.  I think what I’d like to do is have a main while loop which only has the user interface control and a Control.vi.  The control vi will do all the work.  This structure will allow the application to be built, debugged and tested.  After this I expect to get loads of feedback regarding the user-interface layout etc, this structure should allow me change the appearance without editing the control.vi and introducing new bugs.  That’s my plan at least.

My question is this, what method should I use to for the interaction between the Control and the user interface?  I need the control.vi to respond to the user interface but also to update it.  For example, you might start a motor, with the user interface. The control section then detects that the motor is no longer required and switches it off, but how does it update the User interface?

I suspect that I should be passing the user interface to the control.vi by either reference or using notifiers,  neither of which I’ve really used yet

Any ideas thoughts or advice would be appreciated.

Derek

[DFGray]

Typically, in a UI based application, the UI is run using an event structure.  Events from the interface trigger handler VIs.  Global data handling is an art, but there are three primary methods for doing it, listed here in what I think are the best to worst:

1. Single-element queue
2. LabVIEW 2 globals (AKA functional globals or action engines)
3. Globals (do not use unless you absolutely have to, race conditions will kill you)

There are a plethora of others, but this gives you the basic idea.  In addition, since you are using LV8.2, you also have LVObjects to consider.  You can find further information on the above methods by searching this forum.

I have attached a simple example of how to use LV2 globals and an event structure to run things.  The example uses an object-based approach, similar to what you have adopted.  This example does not show how to update the interface from a subVI.  You can do this with user events or control references.

Let us know if you need further help.

[mikeporter]

The event structure is very powerful. For example, say you create Routine A. The code for Routine A creates a user event, registers to receive that event, and pass a reference to that event to Routine B (which is running independently of Routine A). Routine B can now fire that event, effectively controlling Routine A remotely.

Alternately, say Routine A creates a user event but doesn't register to receive it. It simply passes the event on to Routines B, C, D, E, F and G. Now whenever Routine A fires the event, Routines B throough G will all see it at the same time. Very helpful of you have multiple independent processes riunning in the background and need a way to shut them all down.

You can also write subVIs that catch events generated in a seperate routine (like a GUI). All you have to do is pass a reference to the GUI VI to the subVI (or seperate process) and in that VI wire the reference to a register events node. The external code can then see the GUI's menu events, key press events, etc....

Finally, you can even use user events to pass data.

Mike...

[delbertson]

Thanks to you both for replying.

I've not had much of a look at the events structure before the last day or so and that does seem to be helping simplify things.I'm treating all the Clusters indivdually in the GUI bundling them in to my Type-def cluster in the event handler, that's certainly helped. Didn't know you could create user events I'll look into that and keep you posted as to how I get on.

Thanks again.

Derek

[nathand]

---

@Dereklogitech wrote:

I suspect that I should be passing the user interface to the control.vi by either reference or using notifiers,  neither of which I’ve really used yet.

---

I highly recommend that you pass the data to the user interface, rather than passing the user interface references to the control loop.  Let the user interface worry about keeping itself up to date, rather than forcing the control loop to do it.  This keeps your control loop readable (no references all the over the place), allows it to execute more predictably (no need to switch to the user interface thread), and makes it possible to move the control loop to a separate computer (or a real-time system) later without extensive rewrites.