Using sample projects for the CLED Exam

[LewisG]

I have my CLED practical exam next Tuesday and I'm not sure if I should try to use one of the cRIO example projects that ship with LabVIEW.

 

I have been looking over the sample projects and I can see an awful amount of local and global variables.  I want to use an example to save time because I think the exam will be similar to the sample projects but I'm worried I would get penalized for using to many local/global variables.

 

Has anybody had a look at the shipping examples for cRIO like the LabVIEW FPGA Waveform Acquisition and Logging on CompactRIO?  What are your thoughts on them?

 

Thanks.

Lewis

[Neil Pate]

Hi Lewis,

 

I am also taking my CLED next Tuesday (you taking yours in Newbury, right?) and will probably not be using the sample projects, although I may borrow bits and pieces.

 

You are probably right in that the exam will be quite a close match to the sample project, but I think you would have to spend too much time modifying it to meet the new requirements.

[Darren]

The cRIO sample projects were written with close collaboration with the Systems Engineering group here at NI. The places in which we used global variables for multi-loop communication were specifically chosen for performance benefits over other data communication mechanisms.

 

I'm going to make our certification department aware of this thread so they know about your concerns, and take into account the (approved) implementations of the sample projects when grading the CLED.

[mkerry]

Darren is right that we used globals and locals following our own best practices, so there is no need to be concerned about this (globals are used primarily for configuration). However, I would strongly advise not starting from a Sample Project for the CLED exam. I would recommend referring to the CompactRIO Sample Projects to gain an understanding of the general software architecture that NI recommends for embedded control & monitoring applications, as your design should resemble this architecture to some extent (your design will need to accomplish similar tasks). However, the architecture you implement within the exam should be a scaled back, much less complex version. We've noticed that those who have passed this exam, were more efficient building their own architecture from scratch, and using basic LabVIEW primitives (Queues, etc.) over more complex APIs like the Queued Message Handler API that ships in the Sample Projects. 

 

I hope this helps - please let me know if you have any other questions or concerns!

 

Meghan

Edited June 2, 2014 by mkerry

[PiDi]

We've noticed that those who have passed this exam, were more efficient building their own architecture from scratch

 

That's very suprising to me. I took CLED exam two weeks ago.. And probably failed miserably However, I have a strong feeling that if I were more used to example projects, I'd do much better. The exam I got was very similar to the example projects and I some of the functionalities needed to pass exam are already implemented in those examples. My main mistake was choosing wrong template and loosing time to adapt it into my project. If I'd just choose right template and use it as a starting point, I think there would be no reasons to worry for me now.

[LewisG]

I took the exam today and it didn't go too well.  There was simply to much to do in 4 hours.

 

I'm also very surprised you strongly recommend not using the sample exams.  I did decide to use the sample project as a framework and I think this was a good decision.

 

What are the expectations for these are exams?  Are we expected to finish them?  

 

The sample exam is a similar size/type of application as the shipping example called LabVIEW FPGA Waveform Acquisition and Logging on CompactRIO.  We are expected to code it in 4 hours but I wonder how many hours the example took to code

[Neil Pate]

Like Lewis I also took the exam today, however I chose not to use the sample templates. Same result though, I and also ran out of time 

[mkerry]

If you can complete the Sample Practical Exam which is similar to the Waveform Acquisition & Logging Sample Project in 5 hours, you are in great shape. We decided to make this particular exam a "sample" exam because we know that it cannot be completed in 4 hours. You should be able to complete ~80% of the actual practical exam in 4 hours (I haven't seen anyone complete 100% of it). 

 

If you feel confident in using the Sample Projects for this exam, then I encourage you to do so. They are "the" recommended architecture from NI for CompactRIO applications, and if you can get them work, that's fantastic! I'm only speaking from experience in what I've seen so far with CLED practical exam attempts, and the ones who have passed did not use a Sample Project. Please keep us posted on your results though, and share any tips! 

[M_P]

I highly recommend *reviewing* the sample projects, as there are useful design patterns to learn and emulate, but the effort involved in refactoring the sample projects to meet the exam requirements is usually higher than writing code from scratch that follows a similar design pattern but directly matches exam requirements.  Bear in mind with this exam that it is primarily graded on functionality (50%) and design (30%), with style (15%) and documentation (5%) worth much less. Compare this to the CLD, where style and documentation are collectively worth 25 out of 40 points (62.5%).  Your strategy for time management during the exam should reflect this.

 

I wrote the sample exam for the CLED, and the solution provided is what I coded in 4 hours of time (yes, including the icons).  I expect, like MKerry says, that if you could finish the sample in about 5 hours that you're on track to do well on the actual exam.  The sample is more complicated than the actual exam.

[ShaunR]

 Bear in mind with this exam that it is primarily graded on functionality (50%) and design (30%), with style (15%) and documentation (5%) worth much less.

 

A much better grading scheme IMO. Employers pay you for functioning code, not whether you fill out labels or descriptions. It's only really a necessity for toolkit developers.

[Neil Pate]

I think perhaps the design, style and documentation should be worth more. I have a pretty high level of coding standard (i.e. block diagram neatness, comments etc) that I always try and aim for. This is ingrained in me after more than 15000 hours of doing LabVIEW. As such, it is very difficult to override this instinct and code "messily" just to try and get all the functionality in.

[ShaunR]

I think perhaps the design, style and documentation should be worth more. I have a pretty high level of coding standard (i.e. block diagram neatness, comments etc) that I always try and aim for. This is ingrained in me after more than 15000 hours of doing LabVIEW. As such, it is very difficult to override this instinct and code "messily" just to try and get all the functionality in.

 

Depends on your approach, I suppose. Or, more specifically, how much time you have. I haven't met a customer yet that would say yes to me billing for more time to make the diagrams look better or fill in all the VI descriptions/labels. I tend to throw stuff at the diagram, get it working, then make it look pretty. In fact, when faced with a particularly knarly problem, I will go around and fill in descriptions, labels and make icons as a distraction. It fits with an iterative development better as you can make it look better with each iteration, as long as it works. Often, as more features are added to diagrams, they need re-prettifying as the feature list increases so making it pretty off the bat, is a bit pointless.

 

But here we are talking about an exam which is designed to be time stressed and given that the purpose is to certify coding competence, not the examinees graphic design skills or obsessive/compulsive tendencies; I think this emphasis of marking is more fitting. If you have time at the end of the exam to make it easier to read for the examiners, great, but if it's that bad they can press THE button. However, working code is a better yard-stick for coding competence and debugging capabilities in a time constrained environment, IMO (at least for a CLED), and that's what employers want. The Architect cert is probably where how pretty it looks is more relevant (more a test of communication than CLED), once you've proved you can write the code first..

 

But what do I know! I've no certifications at all

[Neil Pate]

However, working code is a better yard-stick for coding competence 

 

Definitely have to disagree with you here.

 

 

 and that's what employers want.

depends... do they want something quick and dirty that will help them right now, or something with more thought (and probably neater) that will probably serve them better in the long run. Different clients have different requirements.

 

Anyway. I am not really moaning or anything. If I fail it due to missing functionality then next time I just better not take the five pee breaks I needed this time around 

[ShaunR]

do they want something quick and dirty that will help them right now, or something with more thought (and probably neater) that will probably serve them better in the long run. 

 

All of them want working code, on-time and on budget. Simples.

Edited June 7, 2014 by ShaunR

[dannyt]

All of them want working code, on-time and on budget. Simples.

 

 

I cannot agree with you there as you missed out the fact that the code needs to be maintainable and by maintainable I mean by any programmer of a suitable experience level, not just the person who wrote.

 

I do not believe every node & wire should be labelled, but at least enought for somebody else to pick up the code and run with it.

[Tim_S]

I cannot agree with you there as you missed out the fact that the code needs to be maintainable and by maintainable I mean by any programmer of a suitable experience level, not just the person who wrote.

The customers I've worked with (mainly automotive) want a system that has a green light for a good part, a red light for a bad part, and the part-to-part must be under the cycle time. The metrics of performance are on-time and under budget. The code should always be maintainable as this will always help out the next person to look at the code (even if that person is the one who wrote it in the first place), but being the last pole to go up in the tent forces trade-offs that can include breaking-even on a project.

[ShaunR]

I cannot agree with you there as you missed out the fact that the code needs to be maintainable and by maintainable I mean by any programmer of a suitable experience level, not just the person who wrote.

 

I do not believe every node & wire should be labelled, but at least enought for somebody else to pick up the code and run with it.

 

Maintainable code is not really quantifiable-it is a subjective assessment. All code is maintainable, it's just how much effort it requires. Even a re-factor (euphemism for a re-write) is a form of maintenance. Good coding practice and style can go along way towards making the life of a programmer easier but, the crux of the matter is that it can look as pretty as you like and you could have filled out every description and hint but if it doesn't work; you won;t get paid and you won't be asked to come back.

.

Therefore it cannot form the basis of a performance or coding metric for the purpose of quotation or deliverable. It's a bit like "future-proofing" in that sense. Additionally, only programmers care about neatness because they are the ones that will be required to maintain it. A project manager just wants it to work and it's your (my) job to make sure it does even if the wires are out by a pixel or two.

 

So I like the grading scheme here because it will be a good indicator that they can write working code under time pressure (like the day before delivery )..

 

programmer  [proh-gram-er] : noun

1.a person who converts caffeine into computer programs.

[Neil Pate]

Got the result of my CLED exam today, passed 

[JamesMc86]

Congrats Neil! I also got mine through and passed, just! 

[Neil Pate]

Congrats Neil! I also got mine through and passed, just! 

Thanks James, congrats on yours too. 

[LewisG]

Congratulations Neil & James!  I unfortunately failed with 63.25% and scored low for functionality and design.

 

In the exam, both my RT, FPGA and HOST were not finished.  When I started running out of time I went into CLA exam mode and putting in the framework for things.  I should have probably concentrated on getting half of it working instead of getting all of it nearly working.

 

More practice and code quicker and I might get it next time 

 

Did you start from a sample template James?

[Neil Pate]

Thanks Lewis,

 

I definitely should have spent more time getting things actually working 100% rather than documenting and making things tidy (which, unfortunately for this scenario is, is just a habit of mine). 

[Thoric]

Wish I'd read this thread before I took my CLED! I didn't realise documentation was worth so little! Luckily I passed also, but next time I take a test I'll pay more careful attention to the grading criteria! Well done to everyone who's passed the CLED, and good luck to all future LabVIEWers who take it!

[JamesMc86]

Hey Lewis,

 

Bad luck, my functionality score was pretty low in the end as well which meant I only scraped it!

 

I didn't start from a sample project but I did generate one and nick a couple of useful subVIs, I think I used a watchdog from one to try and save time.

 

Cheers,

James

[Fab]

I passed my practical CLED recently on the second attempt, I wrote about it here: http://delacor.com/how-to-prepare-for-the-cled-exam/

I wanted to reply to this old post, because I wanted to let others know that using the sample projects might help, provided that:

* you are familiar with them

* you know what to strip to convert them from a sample project template into an actual project template

I hope this helps people preparing for the CLED.

Regards,

Fab