Leaderboard

Enable Training and Consulting, Inc. is a dynamic employer involved in developing custom programming solutions for a variety of clients. Our team of LabVIEW developers carry a combined programming experience of more than 65 years. We are located in downtown Milton, Ontario. Our growth has been exponential since our inception in 2006. Today, we have consulting clients as diverse as: Bosch-Rexroth, FIRST Robotics, the University of Waterloo, Kinectrics, Magna, LEGO Education, National Instruments, SolidWorks, and RWDI. We are currently seeking a LabVIEW Developer to join our team of LEGO-tinkering, educational resource-creating, robot-loving people! Check out our website & blog: www.enabletc.com blog.enabletc.com Send resume to Karen Smolenaars (karen@enabletc.com) We look forward to receiving your resume!

I've used functional globals, however I've used and read good argument for using global variables. Global variables can contain constants kept in controls with the value set as the default. You then have one VI to go to for all of your constant values. I would recommend the FG over the global if you are going to access the value frequently, but if it's something that you are going to read once during initialization and never again (e.g., IP address of target system) then a global would be appropriate. If it's a value that never changes and you don't load, a VI with a constant in it could be set to inline, thus providing the same (similar?) overhead as a constant with the benefit of changing the value one place. Tim

I don't believe so. By my reading, a pseudo-random GUID conforming VI would follow the logic in section 4.4. Given the following syntax: typedef struct { unsigned32 time_low; unsigned16 time_mid; unsigned16 time_hi_and_version; unsigned8 clock_seq_hi_and_reserved; unsigned8 clock_seq_low; byte node[6];} uuid_t; So something like this (all optimization aside): Also of note:

Agreed, the alternation character is unnecessary. It'll work just the same, but it changes the logic of the expression (though it may have no performance impact). The Match Pattern node does not support finite quantifiers, but dot and star work as expected. Because string length is an O(1) operation, maybe this is worth considering: Edit: Oops, had a-z as the character range, when it should have been a-f.

I'd argue the function is too restrictive. About the only thing that can be said about GUIDs is they are 128 bit hex strings. Formatting of a GUID is not always enforced. Personally, I would use a regex more along the lines of ^\{?\w{8}-?\w{4}-?\w{4}-?\w{4}-?\w{12}\}?$ Even then, some common forms of GUIDs would still return false: (CA761232-ED42-11CE-BACD-00AA0057B223) {0xCA761232, 0xED42, 0x11CE, {0xBA, 0xCD, 0x00, 0xAA, 0x00, 0x57, 0xB2, 0x23}} I've never seen the one top one in use, but I've used the bottom one plenty of times before as it also turns out to be a valid C statement. The difficult thing is there is no standard to interpret. I'd recommend adding a VI to create a GUID, and then have Is a GUID.vi follow whatever format is used in the create function, while also being able to interpret whatever format(s) LabVIEW might present.

The RFC states that it must be lower case... http://www.ietf.org/rfc/rfc2831.txt Let HEX(n) be the representation of the 16 octet MD5 hash n as astring of 32 hex digits (with alphabetic characters always in lowercase, since MD5 is case sensitive).

A Regex would be slower, I would ignore the error (if using Match Regular Expression) and the \w will include non-hex characters.

This all sounds like a very good plan.

If there is a VI that creates a GUID, it's a good thing to have. So is there a VI that will do this in string package? //Mike

I think that the update of this information could very easily be automated during the build process. What if there were a special package that OpenG Developers had installed that included a dialog for editing these tags and performing other, similar/related activities?

This OpenG Review is now closed. Please start a new thread to discuss new changes to this VI. Please PM me if there are any issues with this thread. Review Summary Trim Whitespace (String).vi Code is in LabVIEW 2009

I think It's in Omar's slide deck from niweek: http://blog.jki.net/events/niweek-2011-five-clever-debugging-techniques-slides-and-code-now-available/