Leaderboard

Since there's interest, I'll post a more up to date library I've been working with for the last few years, ported back to LV9. This library focuses on producing version 1 timestamp based GUIDs and is incapable of producing the same GUID twice assuming OS clock settings are not fiddled with. The caveat being if you somehow manage to run out of GUIDs for a given timestamp, the VI will yield to obtain a new timestamp, so this method can't be used in FPGA applications. It also fixes a subtle issue with random number generation. Note I have no idea if current hardware would even be able to exhaust GUIDs for a timestamp (it would require 16383 GUIDs to be generated within the resolution of the value returned by the LabVIEW time primitive), but suspect that if anything could, an FPGA may be able to. The non-timestamp methods have been removed-- I didn't see a use for them since there was the possibility of collision with those (however small it may be). LabVIEW.GUID LV9.zip Edit: sorry, originally posted the wrong zip. Fixed.

For what it's worth, attached is a zip containing three Create GUID implementations consistent with IETF RFC-4122: GUID LV11.zip Version 1: Timestamp Version 3: MD5 Version 4: Random The V3 implementation requires the OpenG MD5 library. Also included is a VI that generates a 100 ns base timestamp (used in the V1 implementation, actually works as advertised now), along with a typedef that is used in the implementations. There is no V5 VI, I haven't tracked down the SHA-1 library you have been talking about, but it should be trivial to modify the existing V3 VI (replace the checksum call with a SHA-1 and modify the version bitmask) if it doesn't already have the functionality you describe. If there's interest in having the Is A GUID method perform a basic timestamp validation for V1 GUIDs, I can throw some code together. -m

QUOTE(Tomi Maila @ Dec 4 2007, 10:05 AM) :!: For the love of LabVIEW -- LEAVE THAT FUNCTION ALONE. :!: Nothing -- and I cannot stress this enough -- NOTHING that you write that uses any of the G linker functions can be considered usable in association with any given set of VIs unless it has been certified by a LV linker expert and tested directly by LV team in the Thousand Monkeys Test Suite for provider robustness. Your *probability* of destabilizing LabVIEW by creating new linker relationships and attempting to manage those relationships is as close to certain as you can get. I don't know why you're getting an error. I can only say I'm grateful that you got an error because it prompted you to ask this question. I'm sure you're trying to do something wonderful and magical with the XNode. Do it using an existing relationship. Have your XNode script a strict static VI Reference to the target subVI-- that'll get you a type prop call any time the other VI changes its conpane. Do something creative. But efforts to use the linker functions are pretty much doomed to failure unless you've got way more linker expertise looking over your shoulder than you do. The worst part is that you might even get it working in the 90% case. That 10% case will never be clearly understood and will simply result in bizzare LV behavior that you may never relate back to having one of these XNodes lingering around on some block diagram somewhere.