Certification

cancel
Showing results for 
Search instead for 
Did you mean: 

CLD Tips - you can't have too many

Here's some specific practice items you might work on in preparation for the CLD.

 

  • Practice coding a timer that can be Paused, Restarted, Stopped, and Reset to Zero. Practice coding this timer from scratch. There are several examples on the forums of these timers.

 

  • Practice using the Timer express VI (don't reinvent the wheel if this timer will work for you. NI does not deduct points for using this VI, and it is in fact a very useful tool)

 

  • Practice your ability to properly apply a reset to the timer(s) in a state machine.

 

  • Practice accumulating a counter which can be reset by a user or automatically if a test is restarted. Remember, you will typically count how many times an event successfully takes place.

 

  • Practice subtracting elements from one thing while adding to another, and keep track of it. For example, subtract rocks from a rock pile while adding rocks to a dump truck. The rock pile has X rocks but the dump truck can hold only Y rocks. Say it takes 3.5 trips of the dump truck to carry away all the rocks. Can you keep track of that type of operation?

 

  • Practice creating and reading to/from an INI file, TXT file, Binary file, and CSV file.

 

  • Practice code that uses the File Dialog box, and handle all user input, including Cancel (don't let it throw an error, handle it).

 

  • Practice coding a proper sequencer using a State Machine. Your sequencer should be able to carry out a list of commands in a queue or array, and...
    • ...be able to skip certain steps if requested by the user
    • ...be able to be paused and then continued, while not loosing data such as time acrued on the current step.
    • ...be able to be stopped and aborted, with exceptions handled, and your program goes to a proper state afterwards
    • ...be able to be used again without stale data like timer values or skipped steps from past runs mucking up the new run

     

    and the most important thing in my opinion, which has been said a lot but I'll say it again ....

    • Practice the sample exams and time yourself
Richard






Message 1 of 68
(20,772 Views)

These are really good tips.

 

I can't over emphasize the practice using a state machine.  If you are not using a state machine, you are likely doing it wrong.

 

The hardest part of the exam is the time constaint.  If you haven't practiced coding efficiently, get to it.  Make sure your shortcuts and settings are setup before the exam starts (you are supposed to be allowed to set up the environment before starting the exam).  Practice the exams.  If you are not getting them done in the allotted time, you need to study up on your techniques.  Most of all, do not second guess yourself.  You do not have time to rearchitect your project.  Choose an architecture and run with it.  Simple state machines will work for 99% of the exams (I'm sure there's an exception somewhere out there).

 

One more key point:  Document, document, document!  Explain what you are doing with comments.  If something doesn't seem right, document what you did.  If you are running out of time, document what you still need to do in order to meet your requirements (you might get some mercy points).  Documentation is by far the easiest points to get.  So document as you go (especially the VI and control documentation).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 68
(20,768 Views)

If I would add just one tip; Run your code! 

 

Don't wait until the last hour to run your code for the first time.  If you run out of time and have no functionality then you will fail the exam regardless of your style or how well you documented your code.  You don't have to complete all of the requirements to pass.  But your functionality mark comes only from what works.  Remember, you get no functionality points for things that "almost" work or things that would have worked if you had more time. 

 

My advice is to get the most basic functionality coded, then get that working.  As time starts to run out, make sure you test every time you add a new function.  It's a shame to add that last feature and fail the exam because a little bug broke all your functionality. 

---------------------
Patrick Allen: FunctionalityUnlimited.ca
Message 3 of 68
(20,702 Views)

In terms of time efficiency, a few thoughts. I haven't passed the CLD yet (1 week away for me), but this helped me improve my speed on the practice exams:

 

  • Learn to use Quick Drop, plus the Insert feature with Quick Drop. This drastically increased my coding speed. Make a few 3 or 4 letter shortcuts for commonly used diagram items and get used to them. You're given time to prep the LabVIEW environment before the exam, so add your favorite shortcuts. For the test, I would definitely include for/while/case structures, build array, replace array subset, queue functions. If you use variants then include Variant To Data and To Variant.
  • If you aren't already, get used to Auto-Tool. Using Auto-Tool saves you a second or so every time you want to modify anything on the block diagram or front panel. For EVERY action. A second isn't much on its own until you add it up for almost any click while coding.
  • When you're doing your planning after reading the spec (or as you read the spec), drop the notes down as comment boxes on the block diagram. This takes care of your planning while also starting your documentation.
  • Get used to doing a quick "Ctrl+I" to pull up a sub-VI's info. When you spawn a new sub-VI, do a Ctrl+I and go to Documentation. Fill out a quick little note here. Now whenever you do a "Ctrl+I" it'll go directly to Documentation and you can quickly type in a few notes.
  • Make sure you can quickly throw together your state machine template. I like to start with the producer/consumer template built into LabVIEW, then do my modifications from there. Whatever you're comfortable with, get used to tossing it together fast. 

Good luck everyone!

 

Message 4 of 68
(20,649 Views)

Oh, in addition to Patrick's remark about making sure your code runs:

 

Before the test ends, you should close the entire project / exit LabVIEW, and re-open. Then try running your application again. This will catch any problems with uninitialized shift registers, default control/indicator values, etc. Leave enough time so you can debug from here if needed.

Message 5 of 68
(20,593 Views)

one more from me..

 

  • Bring a snack!

k3.jpg

Richard






Message 6 of 68
(20,584 Views)

what helped me most was...

 

  • FIRST! document,document,document....by the time you finish documenting your main vi FP controls and indicators (according to the CLD overview) from the "application and development requirements", you are already familiarized with the general operation and application, which left me with plenty time to code....
  • SECOND: learn to OPEN/READ those files and MANIPULATE them into an ARRAY OF CLUSTERS and disassemble the cluster with a FOR LOOP to WRITE back to deignated file in the end...so study up on FILE I/O's, ARRAY'S,FOR LOOP MANIPULATION and CLUSTERS 

btw, I was able to code the whole exam in just a while loop( a SIMPLE state machine is all you really need for it, so stop worrying about which architectural design to use)...Smiley Surprised

Message 7 of 68
(20,521 Views)

I took the exam today. With about 45 minutes left, I quit LabVIEW and tried reopening the project. The project file was corrupt and wouldn't open! I showed the proctor. Luckily all the VIs were still working, but this underlines the importance of shutting things down and opening up from scratch. I had to throw together a new project file.

 

When I turned in the test, the proctor checked it on his computer before sealing the USB stick into the envelope.

 

MAKE SURE YOU CHECK BEFORE YOU TURN IT IN!

Message 8 of 68
(20,497 Views)

@apok wrote:

[...]

btw, I was able to code the whole exam in just a while loop( a SIMPLE state machine is all you really need for it, so stop worrying about which architectural design to use)...Smiley Surprised


While I agree with that statement, it's a bit dangerous. We (the test takers) don't know what's in store for us.  I'm not advocating to worry about architecture, but at least be familiar with the Producer Consumer and well as a good State Machine. By the time someone is to the level of taking the CLD (and having a chance of passing it), you should be comfortable with all of the architectures that are represented in the templates.

Richard






0 Kudos
Message 9 of 68
(20,486 Views)

@Broken_Arrow wrote:

@apok wrote:

[...]

btw, I was able to code the whole exam in just a while loop( a SIMPLE state machine is all you really need for it, so stop worrying about which architectural design to use)...Smiley Surprised


While I agree with that statement, it's a bit dangerous. We (the test takers) don't know what's in store for us.  I'm not advocating to worry about architecture, but at least be familiar with the Producer Consumer and well as a good State Machine. By the time someone is to the level of taking the CLD (and having a chance of passing it), you should be comfortable with all of the architectures that are represented in the templates.


ohhhhh! I agree...by the time you are ready,you should be comfortable with all the different various design architectures. I was just stating the fact that I was able to do it that way and in no way am I endorsing main vi w/sub vi's coding with a single while loop Smiley Wink  , it's just some members here get stuck with the idea of using the more complex style, when all that is really needed is the "simple state machine."

0 Kudos
Message 10 of 68
(20,481 Views)