Darren's Occasional Nugget 11/14/2013

I just realized I haven't posted a nugget about my favorite LabVIEW 2013 feature yet. And it's not even an official feature!
In LabVIEW 2013 or later, add the following token to your INI file:
QuickBold=True
Now, whenever you are editing text on the front panel or block diagram of a VI, Ctrl-B will bold/unbold text:
If you want this (or more generally, all standard font-editing keyboard shortcuts) to become an official LabVIEW feature, please go here and kudo the idea!
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

dan_u wrote:
So then why do we have to add a ini key to enable this feature? Just curious...
As Darren said, it hasn't officially been released yet. I believe NI just wants enough people to play with it before it is official, just in case there is a severe bug. I would assume that once it is official that the ini token won't be necessary.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Similar Messages

Darren's Occasional Nugget 11/07/2013

The default style for While Loop subdiagram labels changed between LabVIEW 2012 and LabVIEW 2013:
If you want your While Loop subdiagram label appearance to be consistent across your LabVIEW versions, here are two utilities you can use:
Quick Drop Keyboard Shortcut - While Loop Subdiagram Label - Download this shortcut from the Quick Drop Enthusiasts group to use in LabVIEW 2012. It will create subdiagram labels on While Loops that match the default appearance of labels created in LabVIEW 2013. Note that this plugin will create a left-justified label...you can change the plugin code if you prefer center or right-justified.
Convert While Loop Subdiagram Labels Utility VI - Attached below, you can point this VI (saved in LabVIEW 2013) to a folder of VIs and it will bulk-convert all the While Loop subdiagram labels in those VIs to the default LabVIEW 2013 appearance. This utility VI will not change the existing text justification of the labels. Make sure to back up the folder of VIs before running this utility, as it will make changes to your VIs and save them in LabVIEW 2013.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
Attachments:
Convert While Loop Subdiagram Labels.vi ‏32 KB

This is a good trick. I'm quite fond of property nodes with classes for one simple reason: They separate Public, protected, and private properties in the selection dropdown. This is beneficial for two reasons. 1) When using VIs as accessors, it is much more difficult to determine their access scope visually. 2) When working with a child class, I don't have to go to the project dialog and look in the parent class to determine what accessors it has; they are automatically populated in the property node (with the caveats TST mentioned above on creation of accessors).
CLA, LabVIEW Versions 2010-2013

Darren's Occasional Nugget 04/25/2013

Did you know there is a VI Analyzer Enthusiasts group on the NI Community? Over the past few weeks, multiple community members have posted custom VI Analyzer tests to this group, and they are all available as links here:
List of Community VI Analyzer Tests
Note that you do *not* need the VI Analyzer Toolkit installed to use these tests. Most of them are saved in LabVIEW 2012.
If you have any of your own custom tests that you'd like to share with the NI Community, please post them to the group!
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

RedAG wrote:
Correct me if I am wrong, so people can post custom VI's to this forum and download custom VI's from thsi forum, like examples? Or is it a Forum where they check your VI's? That can't be true can it?
It is a community site. Not quite the same as a forum. But it is there for people to share tools that they wrote. That community site Darren gave is specifically for VI Analyzer tests that people have written. Darren posted a bunch of his own there. You can make comments on people's code and ask for changes. People will make updates if they have the time.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Darren's Occasional Nugget 07/11/2013

Quick tip...I learned this little tidbit from browsing LAVA today. You can wire a Data Value Reference of a class to a property node and it works:
Both calls return '123' and no error. Pretty cool!
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

This is a good trick. I'm quite fond of property nodes with classes for one simple reason: They separate Public, protected, and private properties in the selection dropdown. This is beneficial for two reasons. 1) When using VIs as accessors, it is much more difficult to determine their access scope visually. 2) When working with a child class, I don't have to go to the project dialog and look in the parent class to determine what accessors it has; they are automatically populated in the property node (with the caveats TST mentioned above on creation of accessors).
CLA, LabVIEW Versions 2010-2013

Darren's Occasional Nugget 07/17/2014

Today's nugget has to do with Intensity Graphs and Intensity Charts. By default, they have a blue color map for the Z scale:
If you want to reconfigure the colors, you can right-click any of the numbers in the Z scale and choose Marker Color. It is also possible to programmatically manipulate the scale with the Color Table property of the Intensity Graph/Chart.
I have attached a VI below called Intensity Color Tables.vi that allows you to select between several pre-defined color maps for your Intensity Graphs and Charts. The VI generates the Color Table array that can be wired to the Color Table property. I think my favorite color map is "fire":
Check out the demo VI (in LabVIEW 2009 or later) to see the Intensity Color Tables.vi in action.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
Attachments:
Intensity Color Tables.vi ‏28 KB
demo_Intensity Color Tables.vi ‏26 KB

And this shipping example shows an practical usage of this feature:
C:\Program Files (x86)\National Instruments\LabVIEW 2013\examples\Signal Processing\Transforms\STFT Spectrogram Demo.vi
Barp - Control and Simulation Group - LabVIEW R&D - National Instruments

Darren's Occasional Nugget 03/25/2014

I attended the European CLA Summit last week (my first trip outside the USA!). At the summit I gave a presentation that discussed, among other things, the VariantDataType VIs. Among the myriad use cases for these VIs is checking a variant to see if it matches a particular type. For example, we have a VI that ships with LabVIEW that will assess whether or not a variant is an error cluster (for reference, this VI lives in vi.lib\addons\analyzer\_analyzerutils.llb\VIAnUtil Check Type If ErrClust.vi):
In this VI, we check the variant to see (1) if it is a cluster, (2) if it has three elements, and (3) if those elements are Boolean, I32, and String (in order). I have often recommended this approach for type checking over a simple Variant To Data function call, since Variant To Data will attempt the conversion, even if the types don't match exactly:
Another great use case for these VIs is programmatically retrieving, at runtime, the names of enum entries as a string array:
The VariantDataType VIs are great for data type parsing, and these are just two of many use cases that demonstrate the power of this undocumented API. Have you encountered a novel use for the VariantDataType VIs in your applications?
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Jeff·Þ·Bohrer wrote:
Tools>>Advanced>>Edit Palatte set...(drink Coffee)
Right click an open palatte position Insert>>Subpalatte:
Check Link to a directory
Browse to <LabVIEW> \vi.lib\Utility\VariantDataType
Select Save
select Continue
Whoomp! There it is:
Cross-Posted to uNuggets Thread since this comes up WAY TOO OFTEN.
Not needed just install the package in the Package Network made by NI called Hidden Gems in vi.lib as mentioned at the end of the slides posted by Darren.
Edit: Thank you by the way for making this a package. I already have a vi.lib package with many of the things you mentioned in your slides but not all so this is easier.
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

Darren's Occasional Nugget 02/27/2012

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.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

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.
Bill
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.

Darren's Occasional Nugget 05/13/2014

Having the ability to generate PDF files from LabVIEW is a rather common request. I recently discovered a very simple way to generate PDFs from LabVIEW with a quick modification to some existing NI software. First, you must have the following products installed:
LabVIEW 2009 or later
LabVIEW Report Generation Toolkit for Microsoft Office 2009 or later
Microsoft Word 2007 or later
If you have all of this software, then open vi.lib\addons\_office\_wordsub.llb\Word_Save_Document.vi and make the following modification:
More specifically, add the ".pdf" case with a value of "17" inside. Now, if you wire the path to a PDF file to the Save Report to File.vi for a Word report, then a PDF file will be generated:
We will try to get this change into the Report Generation Toolkit in a future version. I realize that this trick doesn't solve all the use cases (like PDF generation on a system without Word installed), but I'm hoping that it can help out some people today.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

UliB wrote:
I wonder if this tricks works for a Excel report as well.
Yes, I was able to get it to work with Excel with a similar edit to vi.lib\addons\_office\_exclsub.llb\Excel_Save_Workbook.vi. Some things to keep in mind:
For Excel 2010 and later, the numeric value inside the ".pdf" case would be 57.
For Excel 2007, I think you would need to first install the Microsoft Save as PDF or XPS add-in.
For Excel 2007, I think the numeric value inside the ".pdf" case would be -1.
I'm not 100% sure about the Excel 2007 scenario, because I didn't have a test machine available to try it out. But for Excel 2010 and later, it definitely works.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Darren's Occasional Nugget 01/30/2014

I've posted several nuggets in the past about tokens you can add to your LabVIEW INI file. But during a presentation the other day, somebody asked me where the INI file is located, and I couldn't give a complete answer. Its location is pretty easy to remember on Windows, but what about Mac and Linux? Here's where you can find the LabVIEW INI file (also called the LabVIEW Preferences file) on all three desktop platforms:
Windows
LabVIEW [20xx]\LabVIEW.ini
Mac
[user 'Library' folder]: Preferences:LabVIEW.app [20xx] Preferences
Linux
[user folder or 'root']/natinst/.config/LabVIEW-[20xx]/labview.conf
If you want to programmatically retrieve the LabVIEW INI file path on your system, you can call the VI I've attached to this post. It works in LabVIEW 8.0 and later on all desktop platforms. I hope this nugget post eventually bubbles up in a google search for "Where is the LabVIEW INI file?".
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
Attachments:
Get LabVIEW Preferences (INI) File Path.vi ‏20 KB

Darren wrote:
Windows
LabVIEW [20xx]\LabVIEW.ini
Just a reminder that this is machine-wide, and not per user, making things tricky if there are several regular users.
There are some good ideas ideas to move it to the user hierarchy or even move it to the cloud.
LabVIEW Champion . Do more with less code and in less time .

Darren's Occasional Nugget 05/09/2012

When I first learned LabVIEW over 13 years ago, one of the things that stuck with me from my LabVIEW Basics course was that LabVIEW does not support creating an array of arrays:
One way that developers have tried to combat this limitation over the years is to create a 2D array of the appropriate data type, then keep a separate array indicating the column index of the last "real" data value within each row of the array:
This method works, but requires storing lots of garbage data that you don't need, and it also requires maintaining the separate index array, which can be a headache if you are frequently manipulating the contents of the array.
The best trick I know of for storing arrays of arrays is to stick an extra cluster in there, like this:
This technique effectively allows us to store arrays of different lengths within an array. No more garbage data, and no extra work required to keep track of how many values are in each array. I have used this technique many times over the years when I need 'array of array' functionality in LabVIEW. When you are generating the 'array of arrays' on the diagram, you can do so with a Bundle function to add the extra cluster, and likewise use an Unbundle when you need to retrieve one of the nested arrays:
P.S. - My motivation for posting this nugget is this post on the 'Eureka' thread, in which Ben admirably admits to just now learning the 'array of arrays' trick that I've taken for granted for years.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Goodness gracious, those Silver Controls certainly chew up the real estate don't they? They are the FP equivalent of the terminal icon view IMO. Here is what the data structure could look like using (1) My totally hackified borderless cluster which lets me invisibly bundle controls on the FP (2) the usual system controls in modern containers.
I have attached the custom cluster I use, but since I did this via black magic and reverse engineering, caveat bundler. In other words, you have been warned. No substitute for simple, clean controls.
Attachments:
Borderless Cluster.ctl ‏5 KB

Darren's Occasional Nugget 02/29/2012

Only one chance every four years (roughly) to post a Leap Day nugget, so here goes.
I have really been enjoying Class Property Nodes in my current project. I find the familiarity of the Property Node semantic to be helpful in making my class-based diagrams more readable:
This diagram looks much cleaner (in my opinion) than four class data accessor VIs (two write and two read) wired in a row.
Anyway, earlier today I wanted to find all the places in my code where I wrote to a particular class property. It turns out that a simple Find on the write accessor VI for that property was all I needed to do:
Note that I did this from the right-click menu of the icon on the accessor VI's front panel...this trick doesn't appear to work when doing a Find from the Project window. Anyway, once you do this, the Search Results dialog will display all instances of that subVI *and* any property nodes that are using that VI to write the value of that class data.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Ben Phillips wrote:
Does using property nodes in this fashion result in a performance hit compared to using normal LV OOP accessor methods?
In the compiled code, class property nodes do an extra case structure check on the incoming error to avoid executing the property read/write VI. So if your property read/write VI has an error case structure in it, that's essentially a double-check of the error condition. This ends up being an extremely small hit, but it is there. Interestingly though, the Property Node will be a bit *faster* in the case where there is an incoming error, since the property read/write VI won't even execute...whereas a direct subVI call will always execute (although its diagram may be cased out) regardless of the error condition.
Other than the error checking, the compiled code between these two scenarios should be identical.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Darren's Occasional Nugget 03/20/2008

It was brought to my attention recently that one of my favorite little LabVIEW tricks has yet to be nuggetized. You know how if you right-click in the diagram to bring up a temporary palette, you can pick a subVI off the palette to drop it? Well, if you instead Ctrl right-click to bring up the palette, whenever you pick the subVI, instead of putting it on your cursor to drop, it opens the subVI front panel instead. Isn't that neat?
-D
P.S. - Check out past nuggets here.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Darren wrote:
As you already mentioned, right-clicking on that mouse does exactly the same thing as ctrl-left clicking (I guess there's some sort of internal mapping going on?). So it's not *really* treated like a different mouse button click...it's treated like a modified click of the single button. So again, once y'all get a *real* second mouse button, we'll talk.
Darren,
I honestly, all joking aside, don't see the real problem, other than the normal dismissiveness of uni-OS folks. On the Windows side, you use the control key for everything we (i.e. mac users) use the "command key" for (also know variously as Apple Key, or Clover). So if I use control-click to be a right click what is the big diff? The command key should map to what you call a control key.
So, command-control-click should map to this function. That is equivalent to command-right click, which maps on the normal
command <-> control mapping. The control-click is a system mapping to "secondary button". There is a logical consistent mapping to a unique user interaction.
Tomorrows lesson is the option/meta key and emacs mappings..... ;-)

Darren's Occasional Nugget 07/24/2012

Sometimes it's useful to know the default value of a data type for comparison purposes. Some data types have easy default values to check against...'zero' for Numerics, 'false' for Booleans, 'empty string' for String, etc. But what if you have a complex, arbitrary data type...how do you check against the default value? Well, I saw one of my colleagues (a master FPGA programmer) use this trick in his code, and I thought it was novel enough that it deserved a nugget:
The Diagram Disable Structure is normally used to "comment out" code on the diagram. But in this case, we've got a pass-through wire in the Disabled case to define the tunnel output type, but we're enabling the non-pass through case, so we can use the default data type value on the output. As long as you have a wire, you can use this approach to get the default value of the data type of that wire.
I should point out that this trick is particularly useful in FPGA programming when you're testing algorithms with different FXP types...if you were comparing a wire value to a zero constant, and you wanted to avoid type coercion, you would need to go change the data type of the constant every time the FXP type up stream changed...this trick saves you time by eliminating the constant.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Which in this particular case is just a wire wired straight through, so very little chance of uncompilable code.
Besides at least in older versions of LabVIEW the conditional compile structure still fell over some errors such as Call Library Nodes referencing non existing shared libraries, even in the disabled frames.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Darren's Occasional Nugget 01/26/2012

It's been a while since I've posted one of these. But I discovered this trick earlier this week (which ended up being the solution to a tricky UI issue I had), so I had to share it. Have you ever noticed the "Byte Offset from Point" method of the String class?
Yeah, I hadn't noticed it either. But it turns out that this nifty little method will tell you which character is being displayed in a string control at a particular coordinate. In my case, I was drawing a string image within a picture control, and I needed to know when the user was hovering over certain text in the picture with his mouse. So I took the mouse coordinates over the picture, converted them into coordinates on a dummy string control I had in another VI with the same text in it, and got the hovered-over character. Pretty cool!
This method has been publicly available since at least LabVIEW 8.6...I didn't check any earlier. The demo VI (saved in 8.6) is attached below.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
Attachments:
Demo - Byte Offset from Point (8.6).vi ‏12 KB

Darin.K wrote:
Ben wrote:
I think that was what Darren was think when he wrote "(grone)".
I wish, actually he was referring to the quite bad pun that proceeded "groan". Once again people, I try to tell you that comedy is best left to us trained professionals.
So of course I had to look.
A trained C-el could do better (Groan)
Jeff

Darren's Occasional Nugget 10/16/2012

This nugget describes how to provide your own custom content in the Create Project dialog in LabVIEW 2012 or later. For a great intro on the Create Project dialog, check out this Eyes on VIs post.
The Create Project dialog provides project templates and sample projects as starting points for your LabVIEW applications. If you want to include your own content in the Create Project dialog, either for public consumption or your company's internal use, the dialog uses an XML-based plugin mechanism to present all available templates and sample projects installed on your system. To learn more about how to add your own content, check out the following link:
Using Custom Templates and Sample Projects to Develop LabVIEW Projects
As you can see from the Eyes on VIs post linked above, the second page of the Create Project dialog allows you to configure certain things about your new project, like its name, path, file prefixes, and icon overlays. Some of these items are customizable through the XML. If you are comfortable with what the default second page provides, then the XML and the source files for your project are all you need to worry about.
If you want to customize the appearance of the second page of the dialog beyond what the default page provides, you can follow the instructions on the Using Custom Templates link above, and use the source files for the Actor Framework template (which displays a customized second page) as a guide.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Darin.K wrote:
Ben wrote:
I think that was what Darren was think when he wrote "(grone)".
I wish, actually he was referring to the quite bad pun that proceeded "groan". Once again people, I try to tell you that comedy is best left to us trained professionals.
So of course I had to look.
A trained C-el could do better (Groan)
Jeff

Darren's Occasional Nugget 11/14/2013

Similar Messages

Maybe you are looking for