LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

When building complex HMI should I have one VI or multiple VI's?

As for designing your HMI, you could use a tab control as Evan suggested, hide the tabs and create a cluster of buttons to move between screens. If you want to display to the user which screen was selected, you have to handle the logic for the buttons since they don't latch (when you click one, it releases the previous one) and you feed the proper value into the tab control (which is basically a numeric type).
 
2 key points in designing for touch screens -
  • Simplify the UI or your users will have a hard time understanding what to do. Working with a touch screen is not like a program with a mouse. You should have as few options as possible.
  • Make everything BIG and spaced properly or they will click the wrong buttons. This includes text, indicators, buttons - everything. Note that it's usually more important to make things bigger vertically than horizontally because that's the way people tend to "miss".

___________________
Try to take over the world!
Message 11 of 13
(625 Views)
Now I've run into a problem using the subpanels.  I have about 30 screens each with front panel indicators that are bound to shared variables on a PXI client.  Every time I open up a screen it takes 5 minutes or so for the indicators to bind properly.  If I exit one screen and go back in, it has to rebind all the indicators.  Is there at least a way that this 5 minutes only happens once per screen? Or is there a way to make binding quicker?
0 Kudos
Message 12 of 13
(565 Views)
WARNING - Post from blue bar which should not be taken as gospel.

You have a couple of options.
  1. Since you are using subpanels, there is no need to close a VI when you are not displaying it.  You can open all your VIs and bind all your variables when you start the program.  You will have to wait for the first one, but you can load the rest in the background.  When you need one, host it in the subpanel.  When you don't need it, don' close it, just put it in some sort of wait state (waiting on a user event or queue is great for this).
  2. Don't use shared variables.  I know they are simple and easy, but they appear to give you instantaneous communication, when in reality, they don't across a network (they are essentially globals when used locally, so this statement does not apply in that instance).  I would prefer to have a well defined messaging architecture using TCP or UDP (think producer and consumer loops on both ends).  Then the two computers only have to find each other once, provided you cache the info.  Binding essentially goes away, you get better performance, and you get full control over what is happening.
Good luck!
Message 13 of 13
(553 Views)