why are my GUIDs duplicating?

[kaflooey]

Hi all,

I have instrument automation software that generates a GUID to attach to each measurement line that is logged into a text file.  I found a module called 'GUID.vi' and use this to generate my GUIDs (32 hex characters).  This VI uses a loop and genearating a random number then truncating it and converting it to hex. 

I have been told by users of this software that duplicate GUIDs are occuring after 30 or so measurements.  I have been unable to replicate this.

the chances of a 32 char hex number duplicating this often is pretty slim, and I can't work out how this is happening.

[GerdW]

Hi kaflooey,

it would really help to see your 'GUID.vi' - everything else is just guessing wildly...

[kaflooey]

That would make sense.  I've attached an image of the VI, but I'm not sure it's the vi itslef causing the issue. 

also a bit of background on the calling program:

The guid vi is called once for each measurement which is about once every minute.  The program runs for typically 10 measurements.  the duplicate GUIDs don't tend to occur within one set of measurements.  For example, 10 measurements were taken all having unique GUIDs.  10 more measurements were taken in a second and third instance and 10 more unique GUIDs were generated for each, and then on the fourth go the 10 GUIDs were identical to the first 10, in the same order and everything. 

Could this be a seeding issue?

[RavensFan]

What kind of target is this VI running on?  Is it on a Windows PC or some other OS or some real-time target?

The actual VI instead of a screenshot would have been nice.  I duplicated your VI, ran it a million times, and never saw a duplicate.

It could possibly be a seeding issue, but on a Windows PC, I'm not seeing it.  Could it be the way you are using in a larger VI that somehow is maintaining old data in a shift register?

[kaflooey]

Sorry, I'm new to this discussion board, i will upload the actual vis in the future.

I ran a similar test on the module itself and never obtained a duplicate. 

The program which calls the module is being run on a windows XP machine.

The GUID value is written directly into a text file and never put into a shift register or anything like that. The rest of the program is quite complex, but it's basically a state machine and the GUID vi is called in a measurent logging state whos only purpose is to write a bunch of variables, including the GUID, into a tab delimited text file.  All the variables are initialised at the start of the program.

I didn't really expect an answer with the little information I am able to give, but it's really got me stumped.

[RavensFan]

Maybe if you could find a way to simplify the application that still duplicates the problem.

I'm really curious how users are able to see this problem, yet you haven't been able to duplicate it.  How are they running the program?  Are they in the development environment also, or are they running a built. exe version?  (I don't think that should make a difference, but it's worth asking.)

Have you witnessed this happening yourself, or is it only the users who are seeing this and passing the word along?  Just wondering in case the users are doing something dumb like looking at the same file rather than a different file.

If you can simplify the larger program and post it here, maybe we can see something that would explain it.  If you are able to send the simpler version to your users and have them try it out.  Perhaps it could have some debugging features added like logging the random numbers before processing as well as the final GUID's.

[kaflooey]

I can't even duplicate the problem with the full application let alone a simplified version.

I am also curious how others seem to be having issues that I can't replicate.  The users are using a built exe version, but I have tried to use the same build to duplicate the issue with no luck.  (I ran it about 30 times with no duplicates, but the thing takes 10 minutes to run each time and duplicates were reported as happening a couple of hours apart)

My first instinct was that the users were doing something dumb like looking at the same file rather than a different file, but the logs are time stamped, and the GUIDs were indeed identical in two different logged files.

Unfortunately the program is for the automated collection of data from a Rohde and Schwarz TV analyser and doesn't really do anything unless it detects the GPIB connection to one of these as well as other peripheral hardware, and I haven't had the time to implement a simulation mode.  I have uploaded the logging module which calls the GUID.vi (warning: it's some terribly ugly code) which is called every time a measurement completed, but it won't work without the subvis or text files it needs to read from.  I know this VI is running correctly for each measurement as everything else is logged correctly and as expected, and the GUID.vi is only called from within this module and it's output isn't used anywhere else.  

I am going to try using a GUID that is created externally to LabVIEW called from the command line.  I will get the users to test it (seeing as they are so good at breaking my code) to rule out issues with the GUID.vi

[RavensFan]

Good luck figuring this one out.  I can only think of two possibilities:

1.  User error, they don't know what they are getting or how they are reporting

2.  Somehow, some way, their system is doing a reseeding, or the underlying libraries that calculate the random numbers on their system operates completely differently from just about everyone else's system.

I'm curious, what is the purpose of this GUID number?  Why do you need this data to have a unique, but randomly generated code associated with it?  What do you do with the code after it has been generated and logged?

[kaflooey]

Yeah, It's rather illogical so I'm going to just chuck a few trial and error solutions at it and hope for the best.  Fun times.  I even tried running your code but with a timed 30 second delay between the GUID generations to more closely mirror the logging.  I left the thing running since yesterday afternoon (2000 iterations) and no cigar.

To answer your question, the GUID was added to the specs after I wrote the software to handle duplicate measurements.  Initially we were using the date, time stamp and location (lats and longs) but some genious thought checking one field would be better than checking four and proposed adding the GUID.

I understand that the GUID is randomly generated and thus not immune to (although I thought unlikely) duplicates occurring.  Even adding elements based on things like the MAC address and time stamp don't eliminate this possibility, but the liklihood of a duplicate I was told was infinitesimally small.  It's caused me nothing but a pain in my butt.

Anyhow, thanks for all your help and if I ever work out what's causing it I'll post, but I'm not holding my breath.