Thanks for your insight, Greg. I was surprised to learn that global references each contain a copy of the data. This implies that each time data is written to a global, each copy of that global must get updated. The process sounds amazingly inefficient. Now I know why globals are taboo in LabVIEW.
I was also surprised to learn that control "references" are not like data pointers, or object pointers, in this case. Thanks for pointing out this error in thinking. This knowledge is sure to help me in future projects. I have noticed that most of the NI code for interfacing with registers and managing memory have a dll at the core. The function details are handled outside of the LabVIEW development toolbox, precompiled and self contained. It sounds to me that the only way to efficiently and effectively get control over the memory is to write the code block (in c or something) to manage the data the old fashioned way. It appears, as I have anxiously suspected, there's no substitute for knowing how to manage memory at the lowest level. Since I am a slave to LV, I have only done this on rare occasions where the hardware I was controlling came with only a c app dev kit. I just deal with what NI gives me. :)
