CGalvin

Nice! References and shared variables are so simple I'm disappointed I didn't think of it myself. Thanks for the tips. I've got a lot of reading and experimenting to do now!

Will do. I assume the memory buffer a queue provides gets around this data loss. As a side note, I was amused to learn of the term 'FILO queue' rather than the more widely used 'stack'. I'll get the hang of this software some day, I swear

Alright. I got a working example going. Thanks Shane! I will play around with the notifications to learn their quirks and limitations. I'm noticing that if the sub vi is particularly small, the notification solution is more complex than simply unpacking the vi's insides into the place the real-time data needs to be written to. I'll see if I can make a simplified wrapper for the notification modules to minimize this complexity in the basic cases I will be using it for, but I can see that for several sub vis I have here notifications just aren't an appropriate solution, partially due to the fact that I am a little over-zealous with packaging small circuits into their own vi's for reuse.

Hello again. I have been struggling with bringing an idea to life, and I'm not even sure it is a possibility in LabView. Maybe some of you here have some insight. I have a vi that collects data over a period of time and spits the info onto a graph. When running the vi on it's own, I can watch this graph get drawn in real time as data is collected. Now, I would like to use this vi as a module in a larger circuit, but when I use it as a sub vi the module runs all the calculations internally and only gives me the data once the entire operation is complete. I would like to continue to watch the data as it comes in rather than only being able to check the final 'report' given by the sub vi. I have played with clocks, loops, and feedback circuits in an attempt to hack together a solution, but I am beginning to think that the basic vi structure I am dealing with is incapable of running with this behaviour. Is there something I am missing? Or is this honestly a difficult or even impossible task?

Excellent. Thanks for the quick response. Often I find the hardest part of solving a problem is knowing the right terminology to describe it. I think I have enough info now to research the repercussions of concurrent VI instances. Thanks again!

Here is a simple test case describing my problem. In the first image I've attached, I have a parent VI which calls a child VI twice. The task of the child VI is trivial. It waits 10 seconds, then turns on a boolean switch. The trouble is that when the child VI is called twice at the same time, the program will run a single call at a time, putting the other call(s) on hold until the first finishes execution. This is shown in the second and third image, and the end result is shown in the fourth. If I have a subVI that performs a single task, and it is used in many locations across a large program, it seems very limiting to only allow it to run once at a time. Is there a way to enable a VI to be accessed and executed simultaneously in different areas of a circuit? This seems like a fairly basic feature to me, yet I cannot find any information on this problem.