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.
