LabVIEW Certification: Preparing for the CLD

After I passed the CLAD, I decided to try the Certified LabVIEW Developer (CLD) exam. According to the CLD webpage, the purpose of this exam is to "demonstrate experience in developing, debugging, and deploying medium to large LabVIEW applications."

To prepare for the CLD, I first watched the CLD webcast to get a good summary of what to expect on the exam. It turns out the material in the CLD webcast was very similar to the material in the CLD Exam Preparation Guide, but I still read through the entire document to make sure I was familiar with all the areas of competence associated with the exam.

I spent the bulk of my preparation time working through all of the sample exams that were available. My main purpose in working through the sample exams in their entirety was to ensure I wouldn't have any issues with the 4-hour time limit of the CLD. Thankfully, I completed the sample exams and the actual CLD with plenty of time to spare. I strongly recommend that anyone planning to take the CLD work through all the sample exams, not only to assess your coding time, but also because the sample exams are very similar in nature to the actual CLD.

Many people have posted CLD suggestions and tips on the NI Forums and the LAVA Forums. A search of "CLD preparation", or simply just "CLD", will probably yield some useful results. Here's a list of what I feel are the most important points to know before going in for the CLD:

• I can't stress enough the importance of taking all the sample exams and timing yourself. If you're unsure about your programming, post your resulting app to the NI or LAVA forums and ask for some general "How did I do?" feedback.
• When the exam begins, spend a few minutes customizing the LabVIEW environment to match your typical setup. For me, this included things like adding my most common Quick Drop shortcuts, turning off structure auto-grow and red Xs on broken wires, etc. (check out this blog post where I talk about my favorite Tools > Options settings). You'll make up those few minutes many times over during the exam when you're not continually slowed down by environment settings with which you're not familiar.
• Documentation is a huge part of your CLD score, and it is one of the easiest areas to maximize points. Set a description and tip on every front panel control and indicator. Set a VI description on every VI you write. If you use the LabVIEW Project, set a description on all non-VI items in your project (like .lvlibs). Place comments *everywhere* in your diagram, describing your functionality in a concise way. Make sure to document the diagrams in different cases and loops. It is also a good idea to label long wires and wires associated with shift registers.
• Make sure your application is functional before submitting it. It's probably not a bad idea to save all your VIs and close everything down once you're done, quit LabVIEW, restart LabVIEW, open your VI, and make sure it runs correctly. This will eliminate the possibility that you've got non-default values in controls that won't persist after a restart, or that you've got changes to VIs in memory that aren't committed to disk, etc.
• For the CLD, the functionality of your application should trump the complexity of any architectures you select. If you think you can control your CLD app with a simple state machine, and that's a programming structure you're comfortable with, then use a simple state machine. Don't choose an overly complicated architecture if you're not comfortable using it.
• Make typedefs out of any clusters or enums you create for your applications.
• Create a non-default icon for every VI you write (I'd recommend this for .ctls and .lvlibs as well, although that's a pretty low priority). Simple black border, white background, black text icons should be fine. Don't waste time drawing pictures of DAQ boards or librarians in your icons.
• Write clean code. You can lose points for bad style.
• If you're running short on time, prioritize your remaining work, placing "functional application" at the top, and things like "tip strips on subVI controls" at the bottom.

I hope these tips prove useful, and if you're taking the CLD soon, good luck!

My Weekly Nuggets are Back!

I decided to start writing weekly nuggets again. Check out the first 2009 nugget here. Enjoy!

Edit: A little background on my weekly nuggets. Back in January 2006 I decided to start posting a LabVIEW tip or trick every week on the NI Discussion Forums...this was the first installment. I kept it up for about a year, then announced my retirement, since it was getting pretty hard to come up with a new tip every week for 52 straight weeks. Anyway, after I found out that people were bummed that my nuggets stopped, I started posting "occasional" nuggets...much less frequently than weekly. Now that it's 2009, I decided that, to celebrate my 10-year anniversary at NI, I'd start posting weekly nuggets again. Let's see how long I can keep it going!

LabVIEW Certification: Preparing for the CLAD

The road to LabVIEW Certification starts with the Certified LabVIEW Associate Developer (CLAD) exam. According to the CLAD webpage, the purpose of this exam is to demonstrate that the test taker has "basic proficiency" using LabVIEW. Since I've been writing LabVIEW code as my full-time job for over seven years now, I figured my work experience sufficiently prepared me for the CLAD. I recommend taking the sample exams available at the CLAD webpage above to make sure you are familiar with what kinds of questions to expect on the exam.

For me, the actual CLAD ended up being very similar to the practice exams, and I finished it very quickly (I think I was done with the 40 questions in about 15 minutes). If you have been writing LabVIEW code for several years, I doubt you'll need to do much preparation for this one. If you think you'll need more prep, I recommend watching the CLAD webcast and carefully studying the preparation materials. Both the webcast and the prep materials are available at the CLAD webpage linked above.

Additionally, there have been several threads on both the NI Forums and the LAVA Forums over the years that discuss the CLAD. Some threads have more general discussions, while others are specific to questions on the sample exams. Searching these forums for the term "CLAD" should get you to most of these threads.

"Artisan" Sounds a Lot Like "Architect"

I just found out today that I passed the CLA exam! Ever since I found out after NI Week 2008 that NI employees could receive NI Certification, I signed up in a hurry...first for the CLAD, then the CLD, then the CLA.

Look for some posts in the coming weeks about how I prepared for each exam.

Don't Like It When Quick Drop is "Populating...Please Wait"?

I wrote an occasional nugget a few months ago with some advanced Quick Drop tips. Apparently word hasn't gotten around yet, because people still sometimes ask me if there's any way to avoid the initial "Populating...Please Wait" message the very first time Quick Drop is used after starting LabVIEW.

So to reiterate, if you go to Tools > Options > Controls/Functions Palettes and choose Load palettes during launch, your LabVIEW launch time will increase by a few seconds, but Quick Drop will be immediately ready the first time you use it.

Spread the word!

Plug-in VIs for Right-Click Menu Options in the Editor

Ok, here's another idea I had. Since we can't always avoid right-click menus, what if we could write our own VIs, and place them in a special location on disk, and those VIs would become right-click menu options for objects in the LabVIEW editor? I'm not talking about run-time menus here, I'm basically talking about adding features to the editor. I'm also not talking about XControls...I want to be able to define new editor operations for native LabVIEW controls. There could be a folder on disk like [LabVIEW]\resource\MenuPlugins\String. Any VI in this folder would be presented as a new right-click menu option whenever a string (and by inheritance, a ComboBox) control/indicator is right-clicked on the front panel. If you pick this menu option, the VI executes. It takes in a VI Server reference of type String, and then you can perform whatever operations you want on the String. Perhaps the VI could take an array of references so the right-click operation could be performed when multiple controls are selected.

And with scripting, we could do the same thing with block diagram objects. For example, one diagram operation I always find tedious is when I need to delete a node from the diagram that had several pass-through wires (error in, error out, reference in, reference out), I always have to manually wire up the pass through wires once the node is deleted. I could write a plug-in VI for the Node class of the diagram that adds a "Delete and Rewire" menu option that will delete the object, then automatically create those wires for me.

Thoughts?

Edit: Here's another example. Just today I was working on a UI and really loving the "Delete All Items" right-click menu option on Tree Controls, and being annoyed that the same option isn't available for Multicolumn Listboxes. With my plug-in menu VI idea, I could have just written the functionality for the menu option myself!

Keyboard Shortcut for Creating Constants/Controls/Indicators...What Say You?

Does anybody else think this would be useful? I've been on a keyboard kick ever since I created Quick Drop, which has caused me to become increasingly annoyed when I am required to slog through using a right-click menu. I'm thinking of a few solutions here:

• Hold down a keyboard key, then double-click a diagram terminal. Depending on what key is being held down, a control, indicator, or constant would be created. Currently double-clicking a terminal with the wiring tool doesn't do anything special...it creates a wire, just like if you single-clicked the terminal. So it would probably be safe to change the behavior of the double-click operation.
  
• Add this functionality to Quick Drop. Hover over a terminal, press Ctrl-Space, then type a special key combo (which could be customizable like normal QD shortcuts) to create the control, indicator, or constant.

Any other ideas out there? Am I the only one who thinks this would totally rock?