Calling a reference from a subVI

[champ065]

I feel like the answer to this questions is no, but I have to ask it beleive this part of this code really irritates me. So, in this code it has a initiation section and it references like 50 references of items on the front panel of the main VI. They uses these references to build an array of references, and then builds the users front panel depending on which configuration the users selects. I have assumed this code was make in the early days of LabVIEW. But anyways, This 50 some references takes up a lot of space. I would to know if I could just turn this entire reference array builder into a subVI. The part I don't know is will the references still be able to reference those items on the front panel even those they are in the subVI.

[Ben]

Going on your description alone...

Yes you could create sub-VI to traverse the FP and get references to the controls, and build the array in the sub-VI.

That is the theoretical part of your question.

Where things will get tricky is when you get to the parts of the code that use teh array of references. If they are used and accessed based on teh array index, the sub-VI you creta will have to assemble teh arrays in the correct order. If the control name is used to access teh controls and the array of refs are searched... then the order may not matter.

You may also be interested in "Traverse for GObjects" that can be used to find references on the front panel of diagram.

Ben

[Bob_Schor]

Are you looking at existing code, possibly written a few (>5) years ago, possibly not well-organized (one way to tell is to see if there a Block Diagrams with lots of wires running all over the place, a Top-Level VI with >50 controls and indicators, Block Diagrams larger than 3000 by 2000 pixels (i.e. several screen sizes)?

If the answer is yes, then the design is probably bad (leading to your question of passing lots of references around).  With well-designed code, you shouldn't have to do this.

Bob Schor

[natasftw]

Are the "user's front panel" and the main VI different things?

If so, is it safe to assume you're scripting this? 

It's hard to imagine exactly what you're doing from your description.  Is there a reason that prevents you from sharing the code you're talking about? (or at least an example of what's taking place) With that, we could likely provide better advice.

[Ben]

Yes based on only the description we have to resort to filling in the blank with our own images. In my case I have developed code along the lines of what I have in My GUI Gallery found here that features images like this...

I adapt my code style as authors adapt the writing to their audiance. In the case of the code shown above, my "readers" were graduates of LV 1 & 2 and they have been able to quickly navigate and maintain the code themselves.

More advanced "readers" my have recieved code that used sub-panels to keep things cleaner but that would have required more interaction between the instaciated sub-panels which may have put the code beyond their "reading level".

But I will stop there since I have no idea where the original poster needs help.

Behave!

Ben 

[Alexander_Sobolev]

No, you can not move node of the reference to local element into subvi. 

To reduce diagram space and reduce mess, you can group elements by some property (measurement config elements, results elements, etc) and put these groups into case structure frames and loop through them to fill all array of references.

You can loop through top vi elements and find correct reference by label for example.

May be you can consider to change ideology. Have a number of subVIs that present or control your data the way you need. When you need to change mode, you do not rearrange elements, you load a different interface vi that works with original data. 

[champ065]

Thanks for the response Ben. I wish I could show a screenshot of the code, but I can't. However, in your third image, that I kind of what I have, but all the references go into a array builder, and the next frame searches for the references based on the screen the user chooses to see.

So, it looks like i can put those references into a subVI, and just output the array to the next frame in the sequences to help decease space.

Thanks!

And thank you everyone else for your response as well. I will see what happens.

[natasftw]

I'm assuming you can't share the code because of IP concerns.

But, that's easy to get around.  You can create a smaller example with a handful of generically named controls/indicators.

With that, it wouldn't take long to replicate what you're seeing on that VI (on a smaller scale of course) to help us see what you're working with.

The problem with trying to do what you're doing in a subVI is controls would need to pass a reference to the subVI in order to be worked on.  You're either creating the reference to pass to your "array builder" or to pass into the subVI.  In either event, you need to create a reference.

Depending on how flexible you're trying to be, I'd likely suggest taking a look at Ben's mention of subpanels.  Then, you can just load the front panel of interest into your main VI and let them use that.  If you've only got a few set configurations, this is likely a smoother way to handle the swapping GUIs

[Ben]

---

@champ065 wrote:

Thanks for the response Ben. I wish I could show a screenshot of the code, but I can't. However, in your third image, that I kind of what I have, but all the references go into a array builder, and the next frame searches for the references based on the screen the user chooses to see.

So, it looks like i can put those references into a subVI, and just output the array to the next frame in the sequences to help decease space.

Thanks!

And thank you everyone else for your response as well. I will see what happens.

---

If you are going to take the time to fix the code, let me offer some more suggestions that may make your code easier to work with, develop and maintain.

1) Use Typed-defined clusters to pack-up and access the control references.

2) Look at the mini-nugget here to learn how easily create the clusters.

Note: type defined cluster let you keep all of the controls ref in a form that you can esily sort through to find the refernce that you need. Using clusters also let you preserve the reference so that you can get at more than just the generic properties without having to explicitly cas tthe reference when it come stime to use the property/invoke nodes. If the control type changes you pdate the type def and you do not have to sort thhrough all of the code to find the palces it is use.

3) Concider using an Action Engine to both share or act on the referenced controls as a group. Operation like "set config mode" can disable all of the non-config controls in a single AE call. That will keep your code cleaner, and let you quickly find the place where adjustments are required. Example: Customer say "we need to enable this when we disable that".

Final thought...

You used the word Sequence

That scares me.

Have you larned about State Machines in LabVIEW?

Fogive me if you did!

Take care,

Ben