Ways of Using Sub Panels to Make Scalable Applications

[JimMacD]

Hello UI Group,

I'm starting to work with sub panels and am looking for some pointers on how to use them to their full extent.

Currently, the way I manage multiple pieces of machinery on the user interface is with the Tab Control. While this works, it is a pain to manage. Each "cell", or piece of machinery is basically the same, so the user interface is the same for them. With the Tab control, I have to manual recreate and position all front panel indicators/buttons/displays. To make the situation worse, we are adding additional equipment at a fast rate, all of which need similar UIs.

What I want to do is make a generic screen layout

The Communications zone with display important error information for the User, and the navigation zone will contain buttons (Home, Login, back, next, etc...). Within the Sub Panel, I would like to display common screens to each cell (i.e. an Alarm Screen, a Graph screen, a Configuration Screen). My thought is that these screens would only be 1 VI, that is called and populated with different input values depending on which "cell" you wanted to display. For example, I could call the graph screen for cell 1, then call the graph screen for cell 2 and they would be different values, but call the same "graph.VI" front panel.

My main question is, how do I get data in/out of the subVIs loaded into the Sub Panel, while keeping the I/O to the subVIs generic so that there is minimal modifications to the overall architecture if I create a new screen to display?

Thanks for the help.

[Ravi_Beniwal]

Hi Jim,

Here is one of the million possibilities (one per programmer )

You can use a Queued Message Handler for both the host VI and the plugin VI that you want to load in the SubPanel. Load and run the plugin VI dynamically. Make the Host VI and the plugin VI "aware" of each others' message queue names. This can be done very easily if you stick to some kind of a naming scheme, like using the VI name as the message queue name. Now you can pass messages/data back and forth.

Let us know if you need illustrations/examples.

[tusharjambhekar]

if you want maximum flexibility in your ui design then you need to completly seaparate the user interface and process control logic (called business logic).

you should ideally have one(or more) thread which will have complete control logic. and other tread will have user interface. the user interface  will only send events to process control thread.

one helpful design pattern in such scenario is publisher subscriber or observer pattern. see this blog http://www.jambhekar.com/blogs/?p=48

once you have proper design then changes in UI will not be difficult. you can also see dynapanels for some creative ideas

http://forums.ni.com/t5/LabVIEW/DynaPanels-Now-we-can-place-controls-dynamically/td-p/991918

[tusharjambhekar]

if you want maximum flexibility in your ui design then you need to completly seaparate the user interface and process control logic (called business logic).

you should ideally have one(or more) thread which will have complete control logic. and other tread will have user interface. the user interface  will only send events to process control thread.

one helpful design pattern in such scenario is publisher subscriber or observer pattern. see this blog http://www.jambhekar.com/blogs/?p=48

once you have proper design then changes in UI will not be difficult. you can also see dynapanels for some creative ideas

http://forums.ni.com/t5/LabVIEW/DynaPanels-Now-we-can-place-controls-dynamically/td-p/991918

[JimMacD]

yes, examples please

[cirrusio]

Hey Jim,

We often have applications very similar to this where we want to use a single interface to display multiple data sets.  If each cell is basically the same, this seems to me to call for an OOP approach where you have several instances of a single class which all kind of do the same thing (though you could create a single parent and each instrument could extend the common parent and tweak the behavior as needed).  As far as the interface goes - I think this is going to depend on how much data you are streaming to the UI and how much processing you need.  If not a ton, then you might want to consider an xctl.  The xctl can keep track of the data for each set in the state allowing you to use simple booleans or enumerations to switch between the data sets which populate the interface.

I will try to come up with an example if I get a chance.

Cheers, Matt

[JimMacD]

I should also mention the more technically challenging part of this. I would like to also make a way of navigating to the "cells" that I want to look at, from within a Vi running in a SubPanel. An example that might help understand this would be under the DSC Module>HVAC example (C:\Program Files (x86)\National Instruments\LabVIEW 2010\examples\lvdsc\Applications\HVAC\Hvac.lvproj )

My hope was to make the navigation from cell to cell as visual as possible. Like this example shows, you can click on either the "1st Cooler" or "2nd Cooler", which brings you to another window with all relevant information about that cooler. I would like to do the same thing, except instead of being a pop-up, I was hoping to make it appear in the sub-panel. Once the operator arrives at the cell they want, they would be able to click the "show graph" button (which is running in the subpanel), which would then call up the graph.VI into the SubPanel window. (see attached drawing)

The idea is to create a look and feel similar to a internet browser (with the back/forward buttons, and where the middle part of the screen is dynamic and the top/sides are static).

if there is an easier way to do this, and make it scalable, I'm up for that too. Thanks.

[Pie56694]

This makes me think of HNE with panels instead of pages: http://zone.ni.com/devzone/cda/epd/p/id/5329.

[JimMacD]

Very interesting. I will have to look this over. Thanks!