Certification

cancel
Showing results for 
Search instead for 
Did you mean: 

CLD Tips - you can't have too many

Thanks to all who posted tips in this thread.  I took the CLD exam yesterday. The tips here, many of which I applied during preparation and while taking the exam, left me feeling comfortable that I was well prepared.

 

Lynn

Message 11 of 68
(9,036 Views)

@johnsold wrote:

Thanks to all who posted tips in this thread.  I took the CLD exam yesterday. The tips here, many of which I applied during preparation and while taking the exam, left me feeling comfortable that I was well prepared.

 

Lynn


Great!  Piece of cake, right?

 

Richard






0 Kudos
Message 12 of 68
(9,033 Views)

I will know for sure in a few weeks.

 

Lynn

0 Kudos
Message 13 of 68
(9,031 Views)

I Passed CLD with 89%, thanks for your Tips. Kudos to Broken arrow, your tips are very usefull. 

Balaji PK (CLA)
Ever tried. Ever failed. No matter. Try again. Fail again. Fail better

Don't forget Kudos for Good Answers, and Mark a solution if your problem is solved.
0 Kudos
Message 14 of 68
(8,917 Views)

I more concentrated on the Style and Documentation. Missed few functionalities to avoid patch work in the code, but still it payed me back 🙂

 

Documentation - 10/10

Style               - 14/15

Functionality    - 11.6/15

 

Total               -  35.6/40 -  89%

Balaji PK (CLA)
Ever tried. Ever failed. No matter. Try again. Fail again. Fail better

Don't forget Kudos for Good Answers, and Mark a solution if your problem is solved.
0 Kudos
Message 15 of 68
(8,911 Views)

@Baji wrote:

I more concentrated on the Style and Documentation. Missed few functionalities to avoid patch work in the code, but still it payed me back 🙂

 

Documentation - 10/10

Style               - 14/15

Functionality    - 11.6/15

 

Total               -  35.6/40 -  89%


Great score Baji, congrats !!  14/15 on Style is fantastic.

Richard






0 Kudos
Message 16 of 68
(8,897 Views)

I received notice that I passed my CLD today and was just thrilled! It was quite a battle, as I write good, clean code. However, my speed needs to be greatly improved. It is getting there it just takes time and practice. 

 

One of the biggest tips I can give, and I learned this while developing as a contractor....take all of the front panel items, controls and indicators, and make one giant data cluster, save it as a type-def, then you can pass any data you need, anywhere in the program without having to worry or spend time looking for specific type-defs. It may not be ideal in all situations, but it certainly saves time in developing the main as well as subVIs.

 

Another tip, that I can't stress enough....get a clear understanding of the application and choose a good design pattern to start with. I chose a design pattern only to find out about an hour and a half into the exam that it would not work. Luckily since I had done the ground-work with the data structures, I was able to go back and create a design pattern from my troubleshooting that worked and garner enough points to pass. Had I not made the mistake on the design pattern, I likely would have achieved total completion of the requirements. 

 

A third tip, and I learned this in my development endeavours as a CLAD and working on customer applications, becoming a great troubleshooter and learning how to use the debugging tools efficiently is an absolute MUST. Had I not been as good as I am now at debugging, I likely would not have passed the exam, as it would have taken much more time to pinpoint the troublespot and resolve it quickly. 

 

Good luck to all the folks out there waiting on their results or preparing to take the exam! 

 

 

 

Steven Howell

Certified LabVIEW Developer

Arcus Technology Services, LLC.

steven.howell@arcustechservices.com

 

Certified-LabVIEW-Developer_rgb.jpg

 

Steven Howell
Controls and Instrumentation Engineer
Jacobs Technologies
NASA Johnson Space Center
Message 17 of 68
(8,540 Views)

Good advise Mike_LE,  I have failed my CLD many times and the reason was, in almost all of them I was adding that last functionality that broke the code and caused bugs at the end of the exam then all hell broke loose as I was trying to calm myself down, but I couldn't and then all sorts of **bleep** ups started to emerge due to the fear of failure at the last minutes.

My advise of a serial CLD Failing person, is keep the last 20 minutes code free and dedicate them to documentation and messy wires cleanup. Not much functionality can be added in 20 minutes anyway, but a lot of good functionality can be wiped out by a single **bleep** up.

 

The startegy at the start of the exam should be, understand the requirement, then code with a skeleton of the architecture, eg sate machine, or other architecrures of your choice, by skeleton , I mean without the subvis. Test your skeleton achiutecture with made up booleans and a string indicator that shows what state is being performed and compare to the exam requirements.

When your skeleton prototype is tested to work, half the battle is already won, and the debugging time reduced almost to zero.  Remember, debugging is where most of the valuble exam time is spent if not careful.

You can now add SubVis to your prototype with confidence that the outer architecture is working. remember to debug your subVis individually before adding them to the full architecture, then you need to test the full system with your SubvIs added.  It is a top down approach that I knew and failed to execute in a my exams and that is why, I am going to retake my CLD in Sept 2014.  Good luck to me to to all those CLD takers.

Message 18 of 68
(8,039 Views)

Took my CLD today and walked away feeling pretty bummed. I got my CLAD in October of 2013. I started prepping for the CLD in March of 2014 by doing the 4 practice exams continuously back to back up until last night. I felt very confident that I had command of the various elements and concepts present in the Prep Kit, the exams and from the Tips on the forums. Upon opening my exam ( I won't say which it was ) I was faced with a number of elements that I had to manipulate that never appeared in any of the practices. The biggest problem was that in order to initialize the controller, I had to manage these elements. And, being the stubborn person that I am, I focused on getting my initialize state up - which I did, ( Involved the normal initialize things as well as reading a csv file and manipulating somecontrols and indicators ). I know that I should have put code in place to register all  my switch events and demonstrated that I had command of that ability (which I do ), but the unfamiliar stuff just threw me.

I had no broken arrows, my documentation was very good, and I know that my Producer/Consumer structure and dynamic event handling were solid. However, 'meh.... my functionality was maybe 30% of the total requirement.

Also I wasn't prepared for the stylistic variablity in the requirements documentation. I was kind of surprised by the clunky nature of the requirements in the exam. The example specifications were actually better than that of the exam.

Don't get me wrong, I am a strong supporter and advocate for Labview and believe in the certification concept. I see how it assures best in practice code generation and I myself am 10 times the Labview programmer than I was back in March. I really wished that I could have demonstrated that better today when it really counted.

Message 19 of 68
(7,856 Views)

Good luck for the next CLD exam mblair.  I have failed so many CLD exams that I lost account, but this last one I passed it and I have got the results last Friday (17/10/2014).

The difference between the one that counts and the countless failures was that I swared to take care of the documentation and the style 1st and I did my best at documenting every subVi with comments, I have made meaningful icons for every subVi. In the Top Vi I included description and tips for every cluster control and indicator as well as arrays.  The top Vi had also a meaningful description and icon.

I have used the simplest architecture (standard state machine).  About the functionality I was aiming at doing the initialisation and one part fully functional and debugged and any more than that I saw it as a bonus.

Rememeber, any added functionality that is not functional waists time, doesn't count, and adds more frustration and panic at the last minutes of the exam, leading to more panic errors, hence leading to a failure.

The trick is, don't aim for full functionality and full documentation and style. One of these departments has to give, as 4 hours is not enough to get them all. So be pragmatic and make passing the exam your 1st aim.

Start with documentation, then style as these are easy points to get. If you get 10 for documentation and 15 for style, you already got 25 points.

Generally it is almost impossible to get 25 points, so aim at getting 20 points from documentation and style (very doable).

If you do that get the initialasation working and debugged (3 ponits), then get only 1 part of the rest of the functionality working (5 points).  This adds up to 70% and you pass. Anything above that is a bonus. 

Also, by knowing that you.ve got your documentation and style sorted 1st then your initalisation and 1 part or 2 of the exam done and proved to work by debugging, you will be relaxed during the lst minutes of the exam and you make less panic errors at the last minutes.

Here is the breakdown off my exam, 13 points for style, 8.8 points for documentation, 6.4 points for functionality, totalling 28.2 i.e 70.2% .

I made a lst minute knee jerk that fortunately cost me only 3 points and it could have been more and I could have failed because of it.

Without that last minute error my average would have been 78%.

So, my other advise is, never be tempted by doing anything to the functionality in the last 20 minutes as it can lead to undoing the good things you have done so far in the exam and even to a brocken arrow when you return the exam which is an automatic failure.

Keep the last 20 minutes for more documentation, straightening wires, removing unnecessary wire crossing, labelling wires, and generally improving the readability, the stayle, and the documentation of your project.  Doing it this way your are gaining easy points rather than chasing a fuctionality that can go either way and requires a long time to debug and prove.

Message 20 of 68
(7,849 Views)