Identical reentrant FGV's? How to tell them apart?

[PaulOfElora]

I think I'm having a brain fart.  I have an FGV state machine that I need to use for several different state machines in an application.  That is, each of the 'instances' of the state machine VI needs its own separate state data, and will execute with different actions & parameters.  So I develop and get the FGV debugged, make it reentrant, and copy/paste them all in nice row like little soldiers.  I can initialize them all in the same place, yeah fine.  But then, all throughout the code, hereafter each 'instance' clone would not be identifiable to me.  By that I mean, (obviously) the icon for each 'instance' will always be the same, and each instance will just have clone number.

Am I hallucinating?  Will I have to make copies of the VI and save each one with a different name?  That sure smells to me, having to maintain N identical copies.

But then I think "Use the Asynchronous Call/VI Server, Luke!" and pump out the needed 'instances'.  But then I'm left with the same problem - once these babies leave the maternity ward, they all look exactly alike!

What am I missing here? Many thanks for any correction of my thinking, paul

[billko]

I remember something about this, so I Googled labview clone reference.  (I remembered something about clone references.)  I think there are several entries in the top 5 that will interest you.

[Bob_Schor · Accepted solution]

When an infant is born, one of the first things they do in the delivery room is to put a band around its wrist that says "Baby Boy, mother Judy Smith".  If the mother had twins, the wrist bands might say "Baby Boy 1, mother Judy Smith", "Baby Boy 2, mother Judy Smith".

When Mother and Babies are ready to "leave the maternity ward", the nurses check the Wrist Bands (a.k.a. "Clone References") -- by referring to the Reference Numbers (eventually replaced by Parent-chosen "names", like "Jim" or "Bob"), the parents can always identify the First Born ("Hey, Jim"), and can "call them by their Reference Number", keeping them straight.

Note -- even when the children clones aren't identical, but just treated as individual children, with their own identities, we still often refer to them by their "names", but if Birth Order is important, we may want to have an array that lists them in Birth Order, e.g. ["Jim", "Bob"].

Bob Schor

[Yamaeda]

---

@PaulOfElora wrote:

I think I'm having a brain fart.  I have an FGV state machine that I need to use for several different state machines in an application.  That is, each of the 'instances' of the state machine VI needs its own separate state data, and will execute with different actions & parameters.  So I develop and get the FGV debugged, make it reentrant, and copy/paste them all in nice row like little soldiers.  I can initialize them all in the same place, yeah fine.  But then, all throughout the code, hereafter each 'instance' clone would not be identifiable to me.  By that I mean, (obviously) the icon for each 'instance' will always be the same, and each instance will just have clone number.

Am I hallucinating?  Will I have to make copies of the VI and save each one with a different name?  That sure smells to me, having to maintain N identical copies.

But then I think "Use the Asynchronous Call/VI Server, Luke!" and pump out the needed 'instances'.  But then I'm left with the same problem - once these babies leave the maternity ward, they all look exactly alike!

What am I missing here? Many thanks for any correction of my thinking, paul

---

I think you're having a brain fart, yes. Isn't the whole idea of an FGV that it _isn't_ reentrant?

Ditch it into a class and make an array of FGV objects. 🙂

[drjdpowell]

A method of preallocated clone FGVs called by reference is described in this conversation.

[stevem181]

To identify each instance of a reentrant vi, include a required input called something like "ID" or "Index".

This can be a simple numeric or for better readability, an enumerated type can be used (Type Defined of course).

When you place an instance on the block diagram, create a (unique) constant for the "ID" input.

The "ID" input is used internally in your vi (shift register) to differentiate itself from the other instances.

This covers showing a unique ID on the block diagram and using this ID internally.

[PaulOfElora]

Ahhh thanks billko, will pursue & digest - paul

[PaulOfElora]

That's exactly what I'm looking for, thanks much Dr. Powell! paul

[PaulOfElora]

Ahhh Yamaeda, that's a whole different direction for me!?!?  To be clear, do you mean 1) Create a class for the FGV, 2) Make the FGV's internally stored data the class data 3) Replace each 'Action' of the FGV with a class method? Thanks as always, paul

[PaulOfElora]

Thank you much Bob, that's a whole Core 3 lesson right there - will play with this - paul