Reusing code within the same VI (when a sub-VI won't do)

[Branta]

My last question here got awarded a kudos point "for being a great question", which is pretty embarrassing, because at my present skill level it's hard to envisage the time when I'll ever be anything other than a "taker" from this forum !  So here goes with a "dumb" question to try to put the record straight.

My front panel has 17 groups of one button + three numeric indicators, that's quite a lot of front panel items and 8 of the groups have an enum indicator as well.  All of these items are also contolled by property nodes for visibility and/or "disabled".

My program gathers all the data for these items into a Functional Global Variable array, and at end of the main loop it refreshes the properties and the values of all of these front panel items.  It could look unruly, but because of the similarity between the 17 groups the refresh of the front panel items all happens within a neat FOR loop (albeit with a 17-way CASE structure inside it) so at least these controls aren't sprawled out all over my block diagram.

The only problem I have is that my program takes quite a few seconds to initialise and get the loop running, during which period the front panel shows garbage (well, maybe not garbage, maybe data related to the last time the program ran, which may have been a different context, so much better if not visible).

But if I also ran the same "front panel refresh code" right after initialising (wiping) the data in my Functional Global, the result would be that all of these controls would be invisible or disabled, which is a much better place to start from.

But do I have to put a completely separate copy of the loop onto my block diagram to get this effect ?

Making a sub-VI is out of the question, because it's this VI's front panel I am working on.

The word that describes (to me) what I want to do is "subroutine", but in LabVIEW "subroutine" seems to have a very specific meaning, a "stripped for speed" VI that won't touch any front panel anyway.

Is this just a problem of my mindset ?  It's true that in my life by far the most code I wrote was assembler for 8-bit embedded micros, those applications were always strapped for memory.  At this stage of my career the balance won't be tipped however much high-level code I write (yes, I'm a dinosaur).  So I tend to fret about how big my compiled code will be.  Should I just put another copy of the loop (actually it's only the 76 "visible" property nodes I need) onto my block diagram and stop worrying about it ?

[Ben · Accepted solution]

A number of comments.

1) The title of Dinosaur is still up fro grabs with many of us in the running ( I as well used to play the game of "ICan write that charceter in X lines...")

2) When you are doing a lot with the GUI, "Defer FP Updates (its a property of the FP to shut down screen updates, serach for that) may spped things up.

3) I use a GUI controller very often in my apps. I posted about it here.

4) If you chase down my tags I have a collection related to GUI performance.

I'd put the code in a VI called from my GUI controler (that called your FG to get the info).

Regarding memory

When we used to depend on someone with a crochete hook and beads to make our memory, it was justified. Today, memory is cheap and using to save yourself time is just fine. When you worry about memory is when you find the code does not fit into 2 G anymore.

Ben

[_Ian_]

---

@Branta wrote:

Making a sub-VI is out of the question, because it's this VI's front panel I am working on.

---

I may have misunderstood, but here goes... what about passing references to the controls into a sub vi? This would allow you to manipulate them in the sub-vi, and use the sub-vi in more than one place.

Ian

(And I thought your previous question was good too...)

EDIT: Having just followed Ben's link, it seems that this is probably what he was suggesting too, but with a bit more detail. I should have studied Ben's post more carefully!!

[Branta]

Very many thanks for these replies.  Passing references to front panel items (or anything) is a step beyond where I had got to in my learning curve, but now I found an example in LabVIEW 2009 and also with Ben's examples I am now prising open the door to this new topic and can see how it would help in this (and other) situations.

Indeed once I have references to all my front panel items bundled (or arrayed ?) then I think I can see that much of the code I have to serve them could become a bit less extensive and repetitive (i.e. no longer 17 CASES within my FOR loop ?).

Actually the main thrust of my present project is not the front panel (this is just a debug and maintenance tool I'm writing at the moment), but this concept of references looks too generally useful for me not to follow it up.

Thanks again

[Ben]

When you are ready to chew on something substantial try this Nugget where I talk about using control references in sub-VI's and some of the tricks that can be used (the last part of the Nugget was just me showing off to impress the frequent flyers. If the last part gets too weird, just stop reading ).

Ben

[Branta]

Well, I've rewritten it all now and it works great.

I've a FOR loop containing a 17-way CASE that defines all of these front panel items and puts references into an array of 17 clusters of 5 references.

The code that refreshes the front panel items simply indexes the array and unbundles the clusters to get the references.

But here's the irony ...

Now I wrote it this way, the code that has to repeat whenever I want to refresh the front panel items is so small that I lost interest in putting it in a sub-VI !

Thanks again for your help, this morning I had never used a reference in LabVIEW, may have vaguely realised they existed, now I don't feel scared of them at all.  Will definitely read your Nugget, Ben.

[Ben]

Congratulations!

Your testimony sounded like the phrase I learned back in the Navy "Six months ago I didn't know how to spell technician, now I is one."

Ben

[DFGray]

One tip that may not be so obvious - using control references to set the value of front panel controls is inherently very slow due to how LabVIEW works. In order of speed and preference, you should set front panel values using the following:

1. the terminal
2. a local variable
3. the VI method Ctrl Val.Set
4. the control's Value property