Why Are You Still Using Loops in Your Functional Globals?

Are you still creating Functional Globals (a.k.a. LV2-style globals) that look like this?












If you're programming in LabVIEW 8.5 or later, do this instead!












In LabVIEW 8.5, Feedback Nodes gained the ability to live on the top level diagram of a VI... no loop required. This feature gives us the identical functionality of a single-iteration loop with an uninitialized shift register. And let's be honest here...the uninitialized shift register on a single-iteration loop is kind of a hack.

Not only does the Feedback Node clean up our diagrams, but it is slightly faster (sometimes by about 5-10%) than a loop with an uninitialized shift register. This is largely due to the removal of loop overhead.

So get over your Feedback Node (and backwards wire) hangups like I did and make your functional globals more efficient!

Bulk Creation of Controls and Indicators

In my previous blog post, Jason commented that it would be nice to have a utility that will create controls and indicators on diagram objects in bulk. I thought that was a good idea, and I decided to write a VI that gets us pretty darn close...it's not quite a right-click option, but it's as close as I can get without getting a C-monkey to modify the LabVIEW source code for me, and without having plug-in VIs yet.

So put this VI in [LabVIEW 8.6]\project and restart LabVIEW. You'll now have a Tools > Create Controls and Indicators menu option. Select a few block diagram objects, then choose this menu option. It will create controls and indicators for any terminals of the selected object(s) that aren't already wired to something. This transaction is undoable/redoable as well.

I hope this VI is useful to people. I also had another motive for writing it, but you'll have to wait until my next blog post to find out what that was.

A Good Use for Block Diagram Cleanup

One of the big new features of LabVIEW 8.6 is Block Diagram Cleanup, a way to instantly rearrange block diagram contents to make them look "better". In fact, I demoed this feature briefly during my NI Week 2008 keynote appearance. In practice, however, I find that I don't really use the feature all that much. Keeping the diagram clean as I write code has been an integral part of the way I do my job for the past several years, and honestly, if I run Block Diagram Cleanup on my clean code, it makes it considerably less clean. I know many other advanced LabVIEW developers who feel the same way.

Lately though, I have discovered a perfectly valid niche use case for this feature. One of the great things about LabVIEW is how easy it is to write "throw away" code...you know, that simple prototype VI that you write just to test an idea, or that debugging VI that helps you quickly unit test something you're working on...or even the VI where you just drop a single function and wire a few things in to double-check that it works the way you expect (I do this with Match Pattern about once every few months). Well, I tend to write throw away code very quickly, with no regard for "cleanliness". It's these throw away VIs that are the perfect candidates for Block Diagram Cleanup...with a single Ctrl-U, my code becomes considerably more clean than it was before, when I was slinging objects left and right with Quick Drop and reckless abandon. And even though it's throw away code, it's still easier to understand and modify (before I throw it away) if it's clean.

Here's an example "before and after" of one of these situations. In this case, I wanted a VI that displayed every single value in my LabVIEW Class data...in this case, there were several subclasses that contained arrays, so a simple probe wouldn't let me see multiple array elements at once...so I basically wrote a huge "probe" VI that displayed a bunch of these arrays, with several elements expanded. This VI was purely for debugging, and would be of limited utility once I got all my class data straightened out...in other words, it was a "throw away" VI. So I slopped it together, then I cleaned it up. Although not perfect, the cleaned up version is much easier to understand (sorry for all the Wite-Out...these classes pertain to features that have yet to be released):

Before:


After:


I understand that this might be a pretty limited use case, but who knows...maybe I should get my feet wet with the feature now, in the event that it gets a lot better in a future LabVIEW version?