Darren's Occasional Nugget 02/27/2012

[Darren]

This nugget is for all the VI Analyzer fans out there. If you want a detailed log of everything that happens during an analysis session, add the following line to your LabVIEW INI file:

VIAnalyzerLogging=True

With this INI token present, the following file will be created whenever you perform an analysis: [LabVIEW Data]\VIAnLog.txt.  And in this file you will find the following information:

[path to analyzed VI]

[test name],[pass/fail/error],[analysis time in milliseconds]

[test name 2]...

[test name 3]...

[path to analyzed VI 2]

...

This information can be useful if you're interested in which tests are taking the longest to run on your VIs.  And if you're having stability problems, i.e. a crash during analysis, this log file will tell you the last VI analyzed (and test run) before the crash.  Note that I don't do anything fancy with maintaining old copies of the file...if you perform a second analysis, the log file will be overwritten with the new analysis information.

[Rachel D]

Thanks Darren for posting on the discussion forum!

Your excitement for LabVIEW and its applications is greatly appreciated.

Best,

[sbus]

Thanks much for this 'nugget'. But... I have a gripe.

I use LOTS of software packages; word processing, PCB layout, schematic capture, compilers, assemblers, debuggers, FPGA tools, etc.  One of the things that differentiates a 'good' piece of software from a 'bad' one is... the documentation.

You have been handing out options that can be set in the labview.ini file for some time. I appreciate finding out what they are. But (you can see it coming...) - it seems that ALL of the options that can be set in the labview.ini file should be DOCUMENTED and part of the doc set for the LabVIEW environment. My happiness at receiving those settings in small doses is tempered by my feeling ripped off that there's all this stuff that could make my life easier, my use of LabVIEW more efficient, and my time more well-spent, and instead of just presenting me with a platter containing all these things, the get doled out when someone (usually you!) randomly decides to release the information.

Consider this a plea to National Instruments to DOCUMENT the labview.ini file by going through your code base, finding ALL key/content pairs that can be set, and creating a document that presents and explains each. I feed good patting you on the back when you tell me something that helps me in my work; and bad patting you on the back for providing me with information that should have already been present in the documentation and that might have saved me time and effort had I known it earlier.

[billko]

---

@sbus wrote:

Thanks much for this 'nugget'. But... I have a gripe.

I use LOTS of software packages; word processing, PCB layout, schematic capture, compilers, assemblers, debuggers, FPGA tools, etc.  One of the things that differentiates a 'good' piece of software from a 'bad' one is... the documentation.

You have been handing out options that can be set in the labview.ini file for some time. I appreciate finding out what they are. But (you can see it coming...) - it seems that ALL of the options that can be set in the labview.ini file should be DOCUMENTED and part of the doc set for the LabVIEW environment. My happiness at receiving those settings in small doses is tempered by my feeling ripped off that there's all this stuff that could make my life easier, my use of LabVIEW more efficient, and my time more well-spent, and instead of just presenting me with a platter containing all these things, the get doled out when someone (usually you!) randomly decides to release the information.

Consider this a plea to National Instruments to DOCUMENT the labview.ini file by going through your code base, finding ALL key/content pairs that can be set, and creating a document that presents and explains each. I feed good patting you on the back when you tell me something that helps me in my work; and bad patting you on the back for providing me with information that should have already been present in the documentation and that might have saved me time and effort had I known it earlier.

---

I would guess that NI doesn't want people mucking around in the labview.ini file and use the options dialog instead.

[jcarmody]

---

@sbus wrote:

[...] DOCUMENT the labview.ini file [...]

---

Not an official document, but http://labviewwiki.org/LabVIEW_configuration_file

[Darren]

---

@sbus wrote:

Thanks much for this 'nugget'. But... I have a gripe.

...

---

I think the INI tokens issue can be compared to VI Server. As of LabVIEW 2014, there are 3,820 properties and methods in VI Server, give or take. Of those, 1,252 are "private". In other words, they don't show up in the property/method lists on Property Nodes or Invoke Nodes unless you have private functionality enabled. You can find several discussions on the NI Forums and LAVA where private properties/methods are mentioned, but they always have the "use at your own risk" caveat. NI does not support the use of these properties/methods, nor do we guarantee that they won't change (or break completely) in future releases.

It's pretty much the same with INI tokens. We have an internal database of LabVIEW INI tokens. As of LabVIEW 2014, there are 732 entries in that list. Of those, only 57 are marked as "user configurable", which simply means that they correspond directly to items in the Tools > Options dialog, or other configuration dialogs in LabVIEW. You can consider the remaining 675 INI tokens as "private" functionality for the purposes of this discussion. The vast majority in that list are used for internal debugging use cases, launching LabVIEW with experimental settings enabled, etc. They can easily change between releases, and many of them have been removed completely from the product since they were originally added.

Now occasionally, we'll have internal tokens that we identify as being stable enough, and low-risk enough (in regards to not being changed/removed), that we'll publicize those tokens. This nugget post is an example of this. Entries that have been made on the LabVIEW Wiki are others. But these are the exception and not the rule. As such, there just isn't much in this whole scenario that makes sense to put through the official LabVIEW documentation process.