Two points.
To George; fine for low throughput, but don't expect to update XY graphs by reference.
Most of my apps so far have extremely low throughput... something like a two second update rate on waveform/xy graphs (if any). I have not noticed performance problems.
This is true, until someone changes the subvi but not the comment :))I have a project from perhaps a year ago where, as an experiment, I abstracted all the little indicators to sub VIs, accessing via arrays of snip One thing I should have done- I've arranged all my unused terminal nodes prettily off to one side with a comment that they're all controlled via references. Grouping them together with comments as to which sub VIs they're being controlled by would have been rather useful.
I aslo group the unwired nodes off to the side with a comment. And recently, I have considered that they should ALL be in that group. About seeing who is doing what... another technique I am considering in making one subvi per indicator/control. A write to this sub vi would be equivalent to a write to the actual node (at least in function... perhaps not speed?) and would appear in the hierarchy so it would be easy to see where any particular indicator was getting its data from.
The big motivation of this effort is to make the application scale easily... when everything is jammed in the top level VI is becomes a real pain to add new features without undermining the original design. But if different tasks can be spun off in their own loops AND in sub vis, then adding new features only mucks up part of the code, and maybe a small enough part that it isn't even so much like mucking. But for this to work really well, the loops need to be able to interact with the top level vi directly
The only non-reference way that I know is to have a huge loop on the top level that empties a queue into the indicators. But what a mess that always turns into.
George
