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

[zorro349]

I'm building a pretty complex HMI that will be used on a 17" touchscreen.  Should I use one VI or multiple VI's, one for every screen?  If I should use 1 VI how would I switch between the different front panel views, and how would I keep the block diagram from looking messy?  If I should use multiple VI's, what's the best way to programatically load the VI's and go between one front panel to the next?

[Evan]

In general I prefer a single main VI rather than a large amount of separate, dynamic VIs.  If you are launching and switching between a lot of VIs you have to work pretty hard to pass the data around efficiently and debugging the areas can be messy.  If you already have separate VIs that you want to use, look into subpanels.

If you are starting from scratch, I would suggest a big tab control.  You can remove the tabs, so that the user has no idea that you are using a tab control.  To change "screens" you just set the tab to a different view, and there you go.

[zorro349]

I'll try looking into subpanels as I have already started writing the VI's.  Thank you.

[Ben]

I am sorry Evan but I must disagree.

I debug and modify LV applications developed by "others" for a living and our worst nightmares are applications that use a huge top-level VI. It ends up costing my customer double what a proper LV app would have cost.

A well impemented VI should resemble an organized tool box. If you open one of those fancy palleted tool boxes you can quickly find the tool you are after (provided its in there ). If you are after a 3-mm socket, you do have to check the bottoms of the screwdriver pockets.

This is not the case if you keep all of you tools in a plastic bag. It's only a matter of time before you will end up dumping the conttents of the bag on the floor to try and find what you are after.

I have been known to dump out the code of a previously devloped application and re-packed it an appropriate structure.

Another way to look at it is that the help for the VI should give you a good idea of what you will find in the VI itself. Sure your VI help could say "After starting this VI runs the world before it exits." and have a state machine with the following structure

Start >>> Run >>> Exit

In this case, you would have sub-VI for Start, Run and Exit each of which would have their own documentation.

e.g.

Start - This VI will instanciate all background proccesses and establish connections with remote entities....

Run - THis VI will monitor the state of all background processes and provide mechanisms by which the user can interact with ....

...

So in the interest of those that follow you and the reputation of LV as a "real programming language" PLEASE think about your applications architecture before you start coding.

Next: Moving data around

I'll admit that dealing with large data sets in LV does require takling a steep learning curve, but once you have a handle on it, it works great! I will not go into that subject here but the key using large data sets in LV is to NOT move it!

If you have not already read the LV style guide please do so (not you Evan )

It indicates that a diagram should only be "one screen" and if this rule needs to be broken, then the screen must only be expaned in either the horizontal OR the vertical but NOT BOTH!

Sorry about the rambling,

Ben

[zorro349]

Thank you for the tips.  I had the same misgivings about using one huge VI.  So I have separate VI's for each screen and I am using a subpanel to load them from one interface.  It has worked great so far and I am happy with the results.

[Ray.R]

Glad to read that you used the multiple vi approach and that you are happy with the results.

I fully agree with Ben. 

I also debug and modify LV applications developed by "others" for a living and our worst nightmares are applications that use a huge top-level VI. Moreso are thaose awful Sequence Structures with embedded Sequence Structures (Try 30 frames containing up to 55 frames).  It is almost impossible to maintain and you end you re-doing everything to add more functionality to the program... And you will add new functionality in the future...  This is both expensive and not exactly a lot of fun..

I agree with Ben that "A well impemented VI should resemble an organized tool box."

I create vi's based on functionality.  Similar to "Functions" or "SubRoutines" in text-based programming languages.  This approach is much cleaner and allows "room" to grow in the future.  As Ben said "If you have not already read the LV style guide please do so".  It doesn't matter how much experience you have with LV, it is a good read, and you understand things differently as you gain experience.  I fully endorse the "diagram should only be "one screen" rule".  As well as expanding the screen in either the horizontal OR the vertical but NOT BOTH!

Ben,

You should not be sorry about the rambling.  It is excellent advice.  I tried to find the 10 star button but could not find it.. 😉

RayR

Message Edited by JoeLabView on 12-07-2006 09:20 AM

[SamboNI]

And for anyone who is interested in checking them out, the LabVIEW Style Guidelines can be found here or in the LabVIEW help.

[Evan]

I think I should have given a more full answer rather than typing in a quick reply during a build.

I completely agree that you should follow the guidelines, the single screen VI being a prime example.  We have all tried to work on someones code that is 10x10 screens and you have no idea whats going on.

I think the key is making sure the design was well thought out and applies to the specific application.  Its hard to give a blanket statement about dynamic versus single VI architectures.  However, I want to stress I do not mean that you have 1 VI and no subVIs.  No application I can think of should not use subVIs.

But back to my original post.  I have multiple applications where I am using an OO type approach in a producer consumer architecture.  I have some dynamic VIs that handle dialogs etc, but the main app is nicely bundled together, fits in one screen and has over a 1000 VIs.  I have learned the organization of the diagram and the objects and its perfectly clean and easy to maintain. 

At the same time I have seen several applications where there are a bunch of dynamic handlers that are waiting for events to be fired and the handle them outside the main VI.  For me, that always confuses me and I have a really hard time tracking down why something happened, because I didn't realize there is a dynamic VI out there that handled the event, or who fired the original event.  In addition, this application needs good planning to ensure that you don't introduce a large number of race conditions.  Any app can have them, but when you are working with a large number of dynamic VIs you are now outside of dataflow, so you need to ensure that you are careful.

So I guess what I am saying is that I think both can be good approaches depending on the application, but more importantly depending on the programmer and the planning that went into the application.  Either approach can lead to a lot of trouble or to a great application.

Back to Ben's tool analogy, what is important is that you have the tools well defined and use them correctly.  In addition Document what the tool is for, and I find that especially important with a dynamic VI application.  All apps should be documented, but if you have dynamic VIs you are depending on acting, you better make sure they are well documented in both the calling VI and the actual VI.  I believe you can make a well organized tool box in a single VI, or in dynamic VIs; it just takes thought and planning.  Most apps start nice and clean but as more features are needed they go downhill quick, unless designed with growth in mind.

In either application I would suggest investigating functional globals.  They are a great way of moving data and settings between dynamic VIs or VIs within an application.  They also help to solve some of the issues you encounter, like race conditions and data copies.

[Ray.R]

---

@Evan wrote:

But back to my original post.  I have multiple applications where I am using an OO type approach in a producer consumer architecture.  I have some dynamic VIs that handle dialogs etc, but the main app is nicely bundled together, fits in one screen and has over a 1000 VIs.  I have learned the organization of the diagram and the objects and its perfectly clean and easy to maintain. 

---

Thanks Evan for clarifying your first post..  You got me worried for a minute.. 😄

Ever since taking the LV Intermediate course, I have also adopted the OO approach in a producer-consumer architecture.  By-the-way, taking the courses are well worth it.  Wish I had done it sooner.  But then again, I might have spent less time in this forum..  😉

My Main screen now consist of 2 or 3 while loops with an Event structure at the top loop which feeds queue in the other loop(s).  This is an excellent way to keep the block diagram clean.  🙂

RayR

[Ben]

Ray wrote;

"

Thanks Evan for clarifying your first post..  You got me worried for a minute..

"

 Ditto that!

Ben

PS: You have to experience fighting with a user who is quoting post by blue bars as gospel  to understand why I had to respond.