Changes to the CLA Exam

The Preparing for the CLA post is one of the most highly visited links on my blog, so I figured I should post some updates that I just learned about (thanks to JG's post on LAVA) to the way the CLA exam is now done. Much of the advice I gave in the aforementioned post is no longer valid, so I'd like to highlight some of the new features of the CLA Exam as described on the NI CLA prep website:

• No more written portion - When I took the CLA exam, it contained a written portion that was 40% of my score. This part of the exam has been removed, which now makes the CLA a 100% practical exam.
• Customize LabVIEW settings prior to exam start - When I took the exam, I had to spend the first few minutes after the clock started customizing LabVIEW (adding Quick Drop shortcuts, turning off auto wire routing, etc. etc.) before I even read the first question. But now, it seems you can ask your proctor to allow you to customize LabVIEW *before* starting the exam. The following is a direct quote from the new CLA Exam Preparation Guide (page 2) on ni.com: "Please note that you will not receive extra exam time to compensate for non-familiarity with the LabVIEW environment. If you need time to customize the environment, please make arrangements with your proctor to hold off on giving you the exam packet until you are ready to start the exam."
• Sample Exam Available - There is now a CLA Practice Exam available...this is a great asset in CLA preparation that I highly recommend taking very seriously. There is also an exam solution available.
• Requirements tracking - 30% of your CLA score is now determined by requirements tracking, the details of which are described in the practice exam and prep guide documents linked above. The exam graders will be using NI Requirements Gateway to verify requirement tracking in your VIs, so make sure you adhere to the [Covers: ] syntax described in the prep guide and sample exam. Note that knowledge of NI Requirements Gateway is *not* a requirement for the CLA.
  

Looking at the changes, I think they're probably for the best. I personally found the written portion of the CLA when I took it to be relatively easy and straightforward. But I know that written exams are notoriously hard to grade, and there might potentially be language barriers for some test takers. It looks like the test writers are expecting the additional requirements tracking to take roughly the same amount of time as the written portion of the exam, since the sample exam is very similar to the actual exam I took for my CLA, with the addition of the requirements tracking information.

Conclusions - The Diagram Cleanup Experiment

It's been just about a year since I embarked on The Diagram Cleanup Experiment. I attempted to use block diagram cleanup on just about every VI I wrote in LabVIEW 2009 this year. With such heavy use of the feature, I have come to the following conclusions:

• Use it on moderately-sized diagrams - The majority of the VIs I write fit on one screen, and have relatively low levels of nesting. For these kinds of VIs, it is *way* faster to quickly write the VI, then press Ctrl-U to clean it up. The cleanup results in these cases, although not perfect, are acceptable. The diagrams are readable enough to avoid maintenance headaches down the road.
• Don't use it on large diagrams - Diagram cleanup still has trouble with large diagrams. For top-level state machines, or similar architecture-level VIs, cleanup does not respect the arrangement of the diagram, which, for these VIs, is crucial to the understanding of the VI. I have decided that it is still best for me to arrange these diagrams myself.
• Don't use it on heavily-nested diagrams - As I mentioned in my progress report, diagram cleanup completely explodes the diagram if there is heavy structure nesting. It simply can't figure out how to condense space in multiple frames simultaneously. Until it does, I will continue to arrange heavily-nested diagrams myself.
• Mixed results with Tools > Options settings - I tried several times to tweak the settings in Tools > Options > Block Diagram > Block Diagram Cleanup to see if that would improve the cleanup arrangement, but I couldn't figure out a definitive collection of settings that always worked better. If anyone has any specific suggestions for settings that seem to improve the cleanup layout, let me know.

So what's next? I just posted the following idea on the LabVIEW Idea Exchange:

Tell Block Diagram Cleanup what "Clean" Looks Like

I think the easiest way to get diagram cleanup to arrange VIs to my liking is to show it VIs that I like. :) Please kudo the idea if you agree.

So that's pretty much it. In short--I like the feature, I will continue to use it because it helps me program faster, but it definitely has room for improvement.

I Like Global Variables

I think the title of this post alone will probably lose me some followers on this blog. :) Nevertheless, let's proceed...

Here's the deal...global variables are not evil. There are perfectly valid use cases in which a global variable is the best tool for the job, and doing something more complicated just to say, "I didn't use globals!" doesn't make sense. Now sure, globals can be abused, and there are certainly scenarios where they are contraindicated. But if you're aware of those situations, and you avoid them, you should feel free to use globals where needed. So let's look at some use cases where, in my opinion, globals can come in handy:

• Static Data - Whenever I create a UI in LabVIEW in which user-visible strings are programmatically changed, I always store those user-visible strings in a global variable. Let's call this kind of global a Write Never, Read Many (WNRM) global. I am never writing new values into this global...I'm only reading from it in my code whenever I need to update a user-visible string. Another use case for WNRM globals is in scripting apps. When I'm doing code generation involving templates, I always store the identifying labels of panel/diagram objects within a global, and I always read those identifiers from a global in my scripting code. That way, if I need to change the identifiers in the templates, I know that I'll only need to change the identifier in one place (my global) in my scripting code. (Note: I believe Yair's Adding CONSTs to LabVIEW idea on the Idea Exchange is intended to facilitate a cleaner implementation of this use case.)
  
• Debug Flags - If I've got parts of my code that I want to run differently when I'm debugging, I use a WNRM global. I'll open the global and change the debug flags before I run my code. Someone once suggested that I should instead use Conditional Disable Structures with conditional symbols in my project, but after I looked into it, I decided that the added complexity and configuration associated with conditional symbols didn't add enough value over the simple global solution.
  
• Configuration Data - In this scenario, we are initializing configuration data (from an INI file, for instance) at some point in our code, and reading that data at later points. So here we have a Write Once, Read Many (WORM) global. (Note: The term WORM global was first coined by tbob on the NI Forums a few months back.) As long as there is one, single place where the global is written, it is perfectly fine to have many other places in your code that read that global.

Now one of the biggest reasons given as to why globals should be avoided is that new users could easily find themselves in race conditions if they're not careful. But with the use cases above, there should never be any worry about race conditions, as long as developers adhere to the WNRM/WORM constraints. I don't think we should hamstring ourselves with a blanket refusal to use a feature when it really can be a performant time-saver when utilized correctly.

Ain't No Party Like a CLA Party...

If you are a Certified LabVIEW Architect, make sure you are in Austin on March 8-9 for the first-ever CLA Summit. In case you didn't get the memo, here it is. We also have an NI Community Group with more information and discussions about the event. There will be presentations (one of which I'll be giving), coding challenges, hang time with LabVIEW R&D, and much more. And even if your CLA certification is expired, you can still show up and recertify with the new one hour recertification exam.

So if you are (or were) a CLA, come on down to Austin in March, and make sure to bring some warm weather with you!

LabVIEW Performance Tips and Tricks Webcast - Wednesday, November 4th at 11 AM

This week I am giving the following LabVIEW Virtual User Group presentation:

NI LabVIEW Virtual User Groups: Tips and Tricks to Increase LabVIEW Performance and Speed

My co-host will be Todd Sierer (of An Engineering Mind fame), and I will be giving the same Performance Tips and Tricks presentation that I gave at NI Week 2009. Hope to (virtually) see you there!

Progress Report #1 - The Block Diagram Cleanup Experiment

As I mentioned a few months ago, I am attempting to use Block Diagram Cleanup for 100% of my diagram arrangement needs in LabVIEW 2009. I figured I might post updates every once in a while detailing my progress. So here, in no particular order, are some of my observations and impressions after heavy use of block diagram cleanup for a few months:

• It Creates Big Diagrams - When left to my own devices, I create tight diagrams with very little whitespace. I have very quickly discovered that diagram cleanup is rather liberal with its allocation of whitespace. :) Typically this is because I've got a moderately nested diagram, and diagram cleanup doesn't quite know how to allocate space in each frame of a multiframe structure such that whitespace is minimized. I imagine this would be a rather difficult problem to solve, since it would require the repositioning algorithm to simultaneously keep track of the spacing in each frame of a multiframe structure.
• It Doesn't Respect My Window Size - Along similar lines, the diagram gets resized and often goes past the height and/or width of the diagram window. Sometimes I have diagram windows set to a particular size for a reason, and if I were arranging the diagram myself, I would fit the diagram within those window bounds. I wish we could constrain diagram cleanup to the current diagram's window bounds.
• It Creates Bendy Wires - I've always been very careful to minimize the number of bends in my wires, maybe because my boss was always very picky about it. In fact, he's the one who insisted "Wire Bends" be a test that shipped with VI Analyzer 1.0! Anyway, diagram cleanup doesn't seem to be so concerned about wire bends. From what little I know about the cleanup algorithm, this makes sense because the algorithm is very much concerned with node placement, and not so much wire placement (except for its strict insistence on keeping error wires straight, which I like). But if you've got nodes that you've arranged just to keep non-error wires straight, diagram cleanup will not take this into account when rearranging. Also, if you've got constants wired to things, and you've got the constants positioned to minimize wire bends, I frequently see the constant moved, and wires bent as a result.
• It Moves My Control Terminal Labels - I like my control terminals on the sides (left for controls, right for indicators)...in fact, I added the Ctrl-Space-Ctrl-T shortcut in LabVIEW 2009 to make it easier to perform this operation in bulk for all top-level terminals on the diagram. But I've noticed my terminal labels get moved by cleanup, and it doesn't look like something that's configurable.
• But...I Code Faster - Despite its shortcomings, block diagram cleanup allows me to code *much* faster than I do when arranging the diagram myself. I don't have any specifics, but I'd estimate that I write VIs about twice as fast as normal when I spend zero time arranging diagram objects myself.

These are my first impressions of block diagram cleanup, with just a few months of LabVIEW 2009 development (on a mishmash of small projects). But right now, I'm in the beginning stages of writing a LabVIEW Class-based prototype for a LabVIEW Scripting architecture for my current project. I hope to post more detailed observations as I become more involved in this adventure.

Quick Drop Keyboard Shortcut - Commands for "Create" Menu Options

My third post-release Quick Drop keyboard shortcut is now available on the NI Community website. This shortcut allows you to perform all the options in the right-click > Create... menu with your keyboard. You can perform these operations with one or more objects selected. For example, you could select several control terminals on the diagram, press Ctrl-Space, type reference, and press Ctrl-A, and a control reference will be created for each one, just as if you had right-clicked them individually and selected Create > Reference on each one. Check it out and let me know what you think:

Quick Drop Keyboard Shortcut - Commands for "Create" Menu Options