Thanks for the feedback, Joe. I tried using references to the individual clusters B1 and B2, but that did not alleviate the problem.
Though I still do not understand why I am having this problem, I have (somewhat) isolated the source of the problem to the following location: my main VI has a loop that runs every 500 ms or so. Inside the loop, I have a sub-VI that takes one of the cluster B references as a wired input. Inside this subVI, i use asynchronous property nodes to change a value inside the referred cluster. If I remove all property nodes from this sub-VI and keep everything else the same, the VI runs and quits flawlessly. But if I place a property node inside the sub-VI, then the VI takes a long time to quit. This phenomenon is the same even if that property node is not connected to anything external and refers only to a control local to the sub-VI's panel. I have reproduced this problem on multiple computers, and I'm starting to believe that, unless I am doing something really stupid, that this is a flaw in LabView 6.1's memory management. In other words, if there's some sort of small memory leak or delayed garbage colleciton associated with using property nodes, it is magnified by using them repeatedly. If someone knows if LabView 7 fixes this problem, please let me know. Below are further observations that are further evidence for my hypothesis: - the longer the main VI runs and the loop repeats, the longer LabView takes to recover responsiveness after it freezes on quit. - if other VI's are running at the same time, after a while, their loops start to become laggy. - even though all open windows of LabView freeze when i try to quit this VI, the other VI's still continue running fine in the background. I know this because a PID loop running in a separate VI was still maintaining flawless PID control, even though its front panel was frozen. anyway, if anyone knows how to fix this problem, I would be extremely grateful. - emory
