condense property node elements

[hiNI]

Hello,

Attached is a snippet of a program in which after the program goes into a specific state, the front panel elements are made either visible or invisible or there are value changes.

In my actual VI, I have a lot more front panel elements, and in trying to keep my code consistent and easy to follow, if I line up the propery nodes of the elements in the block diagram, the block diagram can extend to over 2 screens. 

I would like to know if there is a procedure that I can adopt where I can condense the activation of the property nodes of elements from the front panel so that the property nodes do not extend over 2 screens as it makes it harder for my collegues with a laptop to follow.

Thanks,

hiNi.

[crossrulz]

You could make an array of references to your front panel objects and use a FOR loop to set all of them.

If you are setting and/or getting multiple properties from the same control, the property node can be extended to be able to set/read multiple properties (like setting your Visibility and Value with the same node).

[0utlaw]

I would suggest that instead of using property nodes in each state to update the values of your indicators, you could just place the indicator terminals outside of your state structure (but within the while loop) and pass whatever value is appropriate for the state out of the case structure.  Writing directly to the control instead of using property nodes will be faster and will save you a lot of space.  It also generally scales better, as you've found out.  You're already doing something like this for your status updates- why not the rest of the indicators?  For hiding/showing elements, it would be more compact to use explicit instead of implicit property nodes and for loops.  You can also use explicit property nodes within subVIs, which will go a long way towards making things smaller and neater.

Control References: Overview (Creating and using Implicit vs. Explicit nodes)

http://www.ni.com/white-paper/3159/en/#toc3

This may be oversimplifying things on account of your basic example, but in general you'll be better off grouping your indicator values into a cluster that's stored in a shift register (like your status string) and then modifiying the cluster contents as needed.  This allows you to start adding logic in subVIs much more easily. It's a lot easier to avoid race conditions caused by writing values from multiple locations as well as things get more complex.

Regards,

[altenbach]

Are these LEDs really controls or are they indicators in the actual program?

Typically LEDs are indicators and you could just place them after the big case structure and wire TRUE  to the relevant indicators from each case (use default if unwired for FALSE). It also seems that the LEDs only have two states: either ON or INVISIBLE, the FALSE state never shows. In this case you could color the FALSE state transparent and they will be invisible automatically when turned off, no property nodes needed to change visibility. If you use this transparency trick, you could even use an array of booleans, reducing a potentially long horizontal row of LEDs to a single terminal on the diagram.

If done right, the diagram could be potentially reduced to 10% and no property nodes are needed at all.