> On the top level vi I load references to > all of the indicators and controls into a global
I think that this would lead to a much more complicated program. References are good for batch changing properties of controls, making cleaner top level code, etc, but overuse can create some headaches. Accessing data from references is slower, and as you have already mentioned you can get race conditions. There are also caveats on closing and opening references that need to be obeyed, and probably other negatives for using refs in this way. IMHO a better way would be to investigate GOOP. IMHO designing a program in this fashion will allow for a much better design, cleaner overall code and easier debugging and implementation. For controls, use SET methods to change the value of the object data (best done in an event loop). For indicator updates have a STATUS method that returns any information, place this in a slow polling loop (~250ms is way fast enough) and wire the outputs to your indicators. Because your program is then event driven it ends up way neater. [NOTE: you can also use event driven state machines etc and although they seem "complicated", these too are really elegant solutions to application design under LV.] No globals, all locking and unlocking is handled by OOP itself. You can abstract the GUI and the underlying modules, not running in the UI thread, etc, etc, etc. There are negatives too ... more VI's, more memory usage, slightly slower execution, but that's cheap compareed with programming debugging time. AND these negatives are really really really minor and not noticed unless you're pushing tin ;-) cheers, Alex.
