Reentrant VI Clone Name

Posted on Thursday 29 March 2007

MalkovichStarting in LabVIEW 8.0, LabVIEW introduced the concept of “clones” to reentrant VI instances — a pretty advanced topic. Because, spawning multiple instances of asynchronous “process” VIs will come up again, in the future, it’s good that we introduce this concept. Now, back to the point… with the introduction of “clones”, each reentrant VI instance has its own Front Panel (instead of sharing one single Front Panel between all instances). In LabVIEW 8.2, clones were taken another step further and debugging of clones was introduced — each clone has it’s own block diagram, allowing it to be debugged independently. These are really great features and along with these new features came a little gem that I didn’t even notice until today: a new VI Property called Clone Name.

Clone Name Property

The Clone Name property is the VI’s name followed by a colon and the clone number (e.g., “″ and “″), which is unique for each clone instance — the same as what would appear on the Window Title of a clone’s Front Panel. This new feature is really great, because it is a unique handle that can be used for addressing specific clone instances. Often, clones are used for spawning asynchronous processes. The way that this is done, is to open a reference to reentrant VI, passing option 0×08 (prepare for reentrant run) to the Open VI Reference function. Then parameters are passed to the clone instance using one of the the “Set Front Panel Control Value” methods, and finally, the VI is run using the Run VI method.

Create New Clone

Now that both the spawner and the clone can use the “Clone Name” as a key to uniquely identify the clone instance, other mechanisms can be used to pass data to the clone. For example, a named Queue or Notifier can be used to pass data directly to the clone of interest. This is especially useful when the Front Panel of the reentrant VI does not exist due to it being removed during an EXE build or running on a “headless” run-time system.

One parameter that you probably want to pass the clone is the new clone’s own VI reference — the one created using the Open VI Reference function. This is a very special reference, because (unlike an implicit VI Reference Implicit Reference) closing it will cause the clone to stop executing immediately — killing the VI dead in its tracks. Generally, you will want to pass this to the clone, so that the clone can be in charge of closing it, when it completes execution.

Thanks for taking the time to learn about this advanced topic. We’ll certainly make use of it, soon :)

    Vladimir Drzik
    March 30, 2007 | 3:21 am

    Hi Jim
    I don’t understand the meaning of the second-last paragraph quite well… Do you think each clone must close its own reference after completing execution? Can’t this be done simply by specifying “Auto Dispose Ref” when calling Run VI?

    March 30, 2007 | 6:49 am

    I wish I had read this article last month. I spent quite a bit of time to figure out how to implment the single executable that spawn the clone winodow and each window control different DAQ device. 0×08 option was the hardest part for me to find. I did not know about Clone Name property, either. I will use that if I have a chance in the future. Great article!

    March 31, 2007 | 1:47 am

    Hi Jim,

    Thanks for this excellent article. I’ll have to try this concept out with my ambiguous distributed supercomputing with LabVIEW project. I’m trying to use LabVIEW for data-analysis purposes in a Linux cluster supercomputer so that we wouldn’t have to maintain a separate code base in different languages for the supercomputer and workstations.

    March 31, 2007 | 7:48 am

    Vladimir: Yes, the “Auto Dispose Ref” setting will cause the reference to be garbage collected when the clone stops running. However, I’m a little bit of a fanatic about closing references, myself :)

    Zen and Tomi: I’m glad you liked the article.

    March 31, 2007 | 12:48 pm

    As always, a most advanced usage of LabVIEW. I can imagine how see technique could simplify creating object (process) instances and being able to get/set messages to them as they run independently and asynchronously.
    Is this a correct assumption?

    March 31, 2007 | 12:57 pm

    John: You\’re exactly right. If you want to see an example of process spawning in action, check out this TCP Server example on This example, dynamically spawns asynchronous TCP listeners that wait on connections from TCP clients and then spawn an asynchronous connection handler for each client that connects.

    March 31, 2007 | 2:12 pm


    First, I would like to start by saying I am very excited about your series on the OpenG tools. I just started using these tools last year, and like you I now find the Variant Config File VI’s indispensable. I have not had the time to look at, and understand, all the other libraries. I am sure these articles will expedite my usage of these tools and in turn help reduce my code development time. Thanks, I eagerly anticipate your article on the OpenG queues with notifiers.

    This article got me thinking about one of my projects. I spawned a .vit several times passing each one its own parameters and communicating to each one via a named queue, much like you suggest above with a spawned re-entrant VI and the clone name property. Here is the question, what are the pros and cons of the method I used vs. the technique you mention above?

    March 31, 2007 | 2:32 pm


    Thanks for the support. Your comment about not having the time to dig through all the OpenG VIs to discover the gems is something that I’ve heard a lot. I was thinking that we needed more examples and then the idea struck me that I should just post examples as blog articles. This would also allow me to discuss related ideas and better organize the content. Plus, a “steady drip” (mmmm coffee) of articles over time should help people find time to digest all this information. I appreciate you letting me know which OpenG VIs/libraries your interested in learning about. I’ll try to get around to mentioning the OpenG Message Queue library (with Response Notifier), sometime soon.

    Regarding the differences between *.vit (VI Templates) and reentrant VIs, I prefer reentrant VIs (especially as of LabVIEW 8.2, where each instance has it’s own Front Panel and Block Diagram). VI Templates aren’t great, IMO, because you cannot instantiate them when they are reserved for execution (in the call chain of a running VI). I really like to use the Static VI Reference to store my spawned VI (getting the VI Name dynamically using a property node, as shown in the article’s screenshot) and this doesn’t work with VI Templates. With VI Templates, you have to include them as Dynamic VIs in your build rules (otherwise they don’t make it into your EXE) and you have to hard-code the VI Name/Path for opening an instance reference — too much trouble, IMO.

Sorry, the comment form is closed at this time.

Bad Behavior has blocked 778 access attempts in the last 7 days.