I think your question is actually a number of questions, all kind of wrapped together, which makes it a bit confusing.
DJDDA wrote:In the attached VI, I need a certain sub-VI to fire when the main VI closes.
you can use the event structure to capture either Panel Close? Or application close events. You can make the program ignore the close and instead run a subvi in the event before closing. Check out Event Conditional Stop.vi in the example finder under Events.
DJDDA wrote:For the sub-VI to work, it needs to know the location of a physical device, and that location can be changed by an interface in one of the main VI's sub-VI's.
In the subvi that can change the location of the device, make sure that every time the location is changed, the value is stored in a functional global (not the same thing as a global!), or even better, like Ben was saying, an action engine. Then you can read from that action engine in your close subVI, so it will always know the location of the device.
DJDDA wrote:Only one such sub-VI requires a termination condition like this right now, but there might be more later.
I really don't understand what this part means. What is the termination condition? That it needs to know where the device is? Or that it needs to execute when the panel is closed. If you need MORE termination conditions, that is easy, just add them into the event structure (Depending what they are), but if you mean that the same termination condition might apply to other subVIs, just duplicate your code.
DJDDA wrote:The inc_dec sub-VI does not seem to be receiving the data from the HV sub-VI (I set it to play a sound if a specific non-default value appeared on the brown cluster wire, and the sound isn't playing).
I doubt I can open your .vi (since I have 7.0 and no one posts in 7.0 lol) so I cant specifically help you with this, however your method of debugging seems a bit excessively complicated. Instead of playing a sound, try either
- placing a probe on the brown wire (probes let you see what the value in the wire is during execution)
- use highlight execution to debug your program (the little lightbulb by the run button on the block diagram) and step through your program to find where it fails
- set a breakpoint in the code a little bit before the brown cluster wire occurs and once your program gets to there it will pause, then you can turn on highlight execution and step through to see if your program is behaving as expected.
As to why globals are evil...you should read Ben's nugget, its quite good. I promise. haha actually all the nuggets are a good way to learn the finer points of labview (or even the bigger points). Basically with a global you can be writing and reading from it at the same time...which is not good. Other methods like functional globals and action engines prevent this from occuring.
Hope that helps a little bit to answer your initial questions