Unique instance identifier

[cherold]

I'm looking for a way to programmatically generate a unique identifier for each instance of a object class.

E.g. is there a function to get a refnum from an object?

 

Ideally, someone can suggest a built-in unique identifier so I don't have to build into object data and check it myself.

 

[hooovahh]

Would the UID work?  It looks like it applies for all GObjects.  The help states that it is only unique for objects within the same VI but you could try to hash the UID with the VI name or something like that.

[ak_nz]

I'm looking for a way to programmatically generate a unique identifier for each instance of a object class.

E.g. is there a function to get a refnum from an object?

 

Ideally, someone can suggest a built-in unique identifier so I don't have to build into object data and check it myself.

 

By-value objects are just data so there is no unique identifier for them that already exists - you will have to create one yourself. You could create a GUID as an object property. They are unique "enough" that they are used through-out the Windows infrastructure. The .NET static method Guid.NewGuid() will provide this for you as a string in a single call.

[QueueYueue]

The .NET GUID would work for sure, but here's my KISS solution.

 

A private VI that is a functional global. I'll call it "generate GUID". All it does is store an internal counter that gets incremented every time you call it. First time you get to it you get a 0, 2nd time it's a 1, etc. Guaranteed to never give you the same value twice (until your program restarts or your counter rolls over). I find this works for 99% of my unique ID needs.

 

Followup food for thought: if you use unique ID's you probably need to use a constructor type VI. There's no way to enforce this in LabVIEW, but it's something that you can document and check for at runtime. If you do things By reference you can enforce the constructor a little better, you get a built in Unique ID (the reference value), but now you have all the additional concerns of a by-ref architecture. Unique IDs are not enough of a reason for me to switch to By-ref, but they could be one check in the "pro" column that I would consider when designing the entire system.

[ak_nz]

The .NET GUID would work for sure, but here's my KISS solution.

 

A private VI that is a functional global. I'll call it "generate GUID". All it does is store an internal counter that gets incremented every time you call it. First time you get to it you get a 0, 2nd time it's a 1, etc. Guaranteed to never give you the same value twice (until your program restarts or your counter rolls over). I find this works for 99% of my unique ID needs.

 

Followup food for thought: if you use unique ID's you probably need to use a constructor type VI. There's no way to enforce this in LabVIEW, but it's something that you can document and check for at runtime. If you do things By reference you can enforce the constructor a little better, you get a built in Unique ID (the reference value), but now you have all the additional concerns of a by-ref architecture. Unique IDs are not enough of a reason for me to switch to By-ref, but they could be one check in the "pro" column that I would consider when designing the entire system.

 

 

You could certainly use the basic incrementing number solution. Often I need to serialize my objects to disk and back so I tend to go straight to the less KISS approach so that each object really is unique.

[mje]

Yeah, I usually just go for an incrementing integer stored in an LV2 when I need a UID.

On the rare occasion I need a true conforming GUID, I use a small native LabVIEW library to generate strings. I posted that library on lavag a while ago, search for LabVIEW.GUID if you're interested.

[Yair]

Followup food for thought: if you use unique ID's you probably need to use a constructor type VI. There's no way to enforce this in LabVIEW, but it's something that you can document and check for at runtime. If you do things By reference you can enforce the constructor a little better, you get a built in Unique ID (the reference value), but now you have all the additional concerns of a by-ref architecture. Unique IDs are not enough of a reason for me to switch to By-ref, but they could be one check in the "pro" column that I would consider when designing the entire system.

 

It is important to define what's meant by "instance" here by the OP. Technically, each split in a wire can (does? depends on how you look at what happens when LV schedules the code to reuse the object in both branches of the wire) also create a copy, which is technically a new instance, but while you can create a constructor VI to init an object, and even create code to make sure the init VI was called, LV does not have the concept of a copy constructor which C++ has (this calls a constructor function whenever you create a copy), so there's nothing to guarantee that a new UID is created at that split. You could call the constructor after each split in the wire, but there's nothing to guarantee it. As you said, by-ref makes this somewhat more controllable in that you define the existence of instances explicitly.

 

But like I said, it should start with properly defining the concept of "instance".