Wisely Manage GUI's in LabVIEW

[arnold_w]

I would like some recommendations on how to manage GUI controls and indicators wisely in LabVIEW. The Front Panel in my application is fairly simple:

Depending on which device the user chooses, only certain tests and the corresponding controls and indicators should be enabled. However, my Front Panel to control this got somewhat complicated:

 

LabVIEW crashes frequently when I edit my VI and sometimes the application terminates right after I start to execute it. I am starting to think that there must be a much better approach (I can't create a sub-VI because it is limited to 28 connector pane connections) and would greatly appreciate any advice on how to make my software development easier and less frustrating.

 

[GerdW]

Hi Arnold,

recommendations:
-make arrays from your huge amount of booleans and properties
-use a for-loop for setting all those properties (works with 1st recommendation)
-avoid race conditions using terminals and locals in the same loop (cluster_out)
-do you really need to change all those settings in the gui from within a dll-call? (you should provide the link to your other thread to avoid double postings!)

[parthabe]

GerW,

Just a while before, I ve provided a link in that post pointing to this one for our convinience.

[parthabe]

---

@GerdW wrote:
-do you really need to change all those settings in the gui from within a dll-call?

---

GerdW,

Is that not a CIN he mentioned ?

[Graziano]

I Arnold,
   I should confess that I've never seen something like that! Wonderful LabVIEW-ART!

   The only remark I'd like to post here, is that the lower part of your diagram is outside the while loop, and (in principle) you does not know whether it is executed before or after the while loop, acording to the dataflow execution model...  You can't rely on the rule of thumb of execution from left to right, top to bottom. Maybe it is not important in your application, but most of times it matters!

   Have a nice day!

graziano

[Graziano]

For Parthabe: sorry, I noticed your post before I was writing mine....

[GerdW]

Hi Partha,

yes, it's a CIN.
But the main point is the same: I would do changes to GUI/front panel only inside LabView. Any external code is ok for processing data, but to move all those GUI settings in a big cluster, move the cluster to external code (dll or CIN), move back to cluster, write back to property nodes - why that complicated?

Why not like this:
for every kind of test you could make a small structure like cluster of (enabled-state, led-color, help-text, etc). This is easy to maintain even/especially in LabView...
Make an array of those clusters to provide informations on more than one test...

[arnold_w]

Thanks for all your comments and suggestions. First, I don't think this is issue related to the issue I posted yesterday. The issue yesterday was about the GUI not being updated, which was solved by moving a part of the code inside the while-loop. Thus, I consider that issue closed. The issue today is that my GUI approach does not seem to suit LabVIEW well and I would like suggestions for better approaches. I come from a programming background and it seems to be much easier to make a simple state machine in C-code than to place tons of LabVIEW boxes in nested case structures to do the simplest things. I need something that is scalable and flexible (for example, I also would like to be able to move and resize components). Can I somehow make part of the Front Panel in C++ and the rest in LabVIEW?

[GerdW]

Hi Arnold,

state machines are one of the nicest/easiest structures programmable in LV And they are quite scalable and flexible - if you create them properly
And in LV8.5 you find also a "State chart" module allowing you to create LV-code by drawing state charts (I haven't worked with LV8.5 so far, I guess you need a little bit more work than just drawing a chart).

Well, would you mix C(#) with Pascal/Basic/Fortran to create a GUI? I would stick to LV to control the GUI provided by LV...

Message Edited by GerdW on 09-24-2007 02:13 PM

[tst]

It would seem to me that your C background is hurting you in this case, since it looks like you're using controls and indicators as variables, which is possible, but is not particularly good style and increases greatly the danger of race conditions.

In any case, making the GUI code in two separate languages sounds like a bad idea. I suggest you take a step back and consider why you're using LabVIEW.
The answer to that can help determine what you should do. Maybe you should do everything in C. Maybe you should do the GUI in LV and the logic in C or maybe the other way around or maybe you should do everything in LV.

As for your options, as mentioned, you can create arrays of your controls to simplify the diagram and you can bundle references together to pass into subVIs (you can see a simplistic example here).

State machines in LV don't have to be in nested structures if they're done right. There are a lot of examples online.