Another method is to create a server. It requires some familiarity with starting a VI programatically (via a reference). The VI copies itself and renames the copy, then makes a reference to that copy and starts the VI from the reference. After the copy of the VI is started, the calling VI returns to await the next invocation. All the proper input (and output) wires have to be properly set up. If there's no front panel, the passing in of a notifier to stop the execution is necessary to stop the server.
The copy can be uniquely renamed by tagging the file with the current time, or millisecond tick value. A way to clean up the copies should be considered once the VI is done or when the program is ending, since they have to be deleted as well. The directory where they are created will get full-ish of these.
There's a demo of this in the networking examples showing how a VI can accept an incoming request on a port, then cloning a sub-VI that processes the request, calling that clone, then returning (looping back) to listening on the port. That might be a little cleaner method for keeping track of the cloned sub-VIs. Each VI called needs to have a unique name. The performance hit for loading a server VI from the cloned file on disk seems to be minor. In this example, the cloned sub-VI returns when the network connection is closed.
HTH,
Bob Seegmiller
NG Ryan Aeronautical Center
Bob Seegmiller
NG UMS Ryan Aeronautical Center