Jump to content

Recommended Posts

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.

 

Link to comment
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.

Link to comment

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.

Link to comment
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.

Link to comment

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.

Link to comment

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".

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.