Leaderboard

Thanks, guys. JG: I noticed in your VI you are checking the VI Type to determine whether or not you should traverse. A more robust way to determine if a VI has a block diagram is to use this VI: vi.lib\addons\analyzer\_analyzerutils.llb\VIAnUtil Has Diagram.vi Despite its name/location, this VI does ship with LabVIEW core...use it whenever trying to figure out if a VI has a diagram. There is also a VIAnUtil Has Panel.vi in the same LLB.

if it's someone else's subvi and all I need is to supply the correct inputs and get the correct output them no I usually leave it alone. If I am given ownership and responsibility for making The code work then I will refactor it to my liking. Sometimes it is worth it other times it's not. One of my biggest fears is being caught in a high pressure situation with clients or operators waiting for me to fix code that I don't fully understand or can't fix easily. So I would say that I tend to do this more often than I need to but it's worth It for my peace of mind. Mark

If you are a CLA, we want your feedback, the call for topic ideas for CLA Summit 2012 is here: https://decibel.ni.c...nt/thread/10492 CLA Summit 2012 will be March 5 - 7 Thanks, Fab

Another "major change" that may be worth considering at the same time is whether to put the OpenG packages into .lvlib libraries. Pros and cons?

Plus, if your cluster had the following: String_Name = "Hello World" Boolean_Name = True [unnamed] = False [unnamed] = True The INI file would get written as: [Cluster_Name] String_Name = "Hello World" Boolean_Name-1 = "TRUE" Unnamed_Variable-1 = "FALSE" Unnamed_Variable-2 = "TRUE" When reading this back in, we would have to assume that "Unnamed_Variable-1" is linked to "Cluster Element 2" and "Unnamed_Variable-2" is linked to "Cluster Element 3". Again this could possibly introduce a bug in your application.

I quickly wrote a tool using Traverse Refs (thanks D!) to scan the OpenG Library to discover CallBeRef node and if Re-entrant. Here are the results: Please comment if you think tool may have missed any VIs etc... I can add these to DB to be fixed based on outcomes of this performance benefits discussion. Check OpenG Library for Recursive VIs.vi Code in LabVIEW 2009.

FWIW, when I have to do this I like to use the following convention: If the Label is red (BD and FP), its dependent so don't go changing it. I think I copied it off someone after seeing it on LAVA (thanks to Olivier I think )

The OpenG Board will make the final decision on changes related to the direction of OpenG, but by all means, everyone's opinions, ideas and feedback are very much welcome and respected - so please keep them coming.

For a long time now, me and a couple other guys here have dreamed of being able to drop a "black terminal" which will literally take any type without coercion. I saw AQ's post when he first wrote it and I was excited to see that we're getting closer to having that feature. I wish I knew more about how it was written.

Doesn't having identically named values in a cluster cause you issues when developing? Anyways, IMHO identical items should not be used. One problem I can see with this is that INI files are designed so that order of the sections/keys in the file does not matter (hence the name-value paradigm). E.g. If in the future, the first item was removed from your cluster, then on reading an existing config file, the API would now return the first item's value when reading the original second item, and therefore introduce a bug into your code.

I agree that clusters should not have duplicate or unnamed elements. I'd be more inclined to say the VI should check for duplicate names and throw an error if it finds any. Losing data is something we certainly want to avoid.

Thanks for the replies, I am aware of how to obtain this information using VI server. I just find it odd this tool does not exist. Sounds like something I will have to develop and submit to the LAVA code repository. So this thread has now become suggestions on developing a VI Task Manager tool.... Please reply with your ideas!

Tell that to the people who flew the Mars Climate Orbiter INTO the planet, rather than into orbit, because one of their software packages was outputing in pound-seconds what the rest of the program thought was Newton-seconds. It's a Volt-Kelvin. Volt = Joules/Coulomb; Joule = kg m^2 s^-2; Coulomb = Amp-second --> Volt = kg m^2 s^-3 A^-1 The base unit is often unintelligible to humans, but as soon as you create an indicator and set it to "Watts", or do any math operation that requires consistent units (add, subtract, greater than, etc.) you'll get a broken wire and realize you multiplied the wrong things. And you'll get an error from your power module if you send it a VarMessage to set power at 1668.9 Volt-Kelvin. Basically, the computer is too dumb to tell you your unit is weird, but it's far better than you at identifying when the physical dimension is not the same between two quantities. Units can be some trouble, and internal to a module you might want to not use them, but for public communication between modules (possibly written at different times or by different programmers) they extend the bug-preventing value of type-checking to physical dimensions and eliminate the need to remember what units other modules expect things in. -- James BTW: the link to the prior conversation is actually here.