Certification

cancel
Showing results for 
Search instead for 
Did you mean: 

CLD ATM critique

This was my first attempt at the practise exam. Finished the programming with over an hour left for documentation.

 

I seem to have made it a bit more complicated than other examples I've seen on here.

Feedback appreciated,

Cheers

0 Kudos
Message 1 of 6
(4,303 Views)

It looks like  you were able to get most, if not all, of the functionality. If you are going to use a QMH, I would suggest suggest creating a user event so that your Event Loop can be stopped if you run into an error in the Input Loop. I think you could use slightly more documentation, go for at least one comment for each case of each structure. Comments are good when you have them though. Remember to put a tip strip for the controls and indicators of your main FP VI.

 

I think you would end up losing a fair amount of points on style as well. Nothing stands out too much by itself but there are a few instances of items overlapping or going behind structures and a fair amount of unecessary wire bends. None of them are too bad individually but it adds up.

Matt J | National Instruments | CLA
0 Kudos
Message 2 of 6
(4,272 Views)

@aceagles wrote:

This was my first attempt at the practise exam. Finished the programming with over an hour left for documentation.

 

I seem to have made it a bit more complicated than other examples I've seen on here.

Feedback appreciated,

Cheers


I'm not even going to look at the code.  I'm going right here:

 

You NEVER finish programming then document the code!  Consider yourself [EDIT: ...Insulted Apparently, I can't really do those things I'd do to you in my office, to a poster to get their attention  Did I get your attention?]

 

Document first, then( and only then) develop the code by intention!

 

On your CLD 1/4 of the potential points are awarded to documentation.  Spend the first minutes getting that done and ... How long did that take? 1/4 of the points ....no where near 1/4 of the 4 hours you get.  There is simply no excuse for not documenting FIRST.

 

Sorry if that sounded harsh.  You deserved it!


"Should be" isn't "Is" -Jay
Message 3 of 6
(4,260 Views)

And to chime in, continue documenting as you code (wires, subVIs, structures & logic).  The reason we alot a significant portion of points to documentation is to encourage the development of good habits during CLD preparation.  As your skills increase and the complexity of your code increases along with it, documentation becomes more and more critical -- and the habits harder and harder to unlearn/relearn.  

Certification Engineer II
National Instruments

Certified LabVIEW Developer

0 Kudos
Message 4 of 6
(4,257 Views)

Cheers for the feedback, I've taken it on boad and tried to apply it to the Car Wash test that I did today.

 

A couple of thinks keep popping up though when I'm using VI Analyser to check my work.

 

There's always an error saying that the SubVI front panel doesn't match the terminal connector pattern even when I think it does.

The Error In cluster throws an overlapping control error as well.

Also how important is the cyclometric complexity test? I always seem to be over the specified limit but can't see a logical place to put something in a SubVI

 

I've attached my car wash solution.

Thanks a lot,

Adam

0 Kudos
Message 5 of 6
(4,250 Views)

To be honest,

 

 

I would have taken you asside for a private conversation about "Documenting" your code.  Yet,  I,m happy that you re-evaluated the priority!  Sometimes we need an objective point of view that challenges our pre-conceptions.  A "Challenge" can do that well.  Looking at the submission?  Just tweak the documentation- the rest is "In-line" with CLD.

 

Not "Perfect" but, with some documentation .... you are on the right track!  Take the test!


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 6
(4,234 Views)