Sample Exam Solutions for Review

[JÞB]

---

@jerryatnz wrote:

Hi Jeff,

Thanks for bringing it up.

I understand where you are coming from, and I agree with you - this is top level vi, and I don't think there should be wired controls or indicators either.

1. When I read post Best strategy for the CLD Exam , it says "Connect the connector pane of the main VI (I lost my 0.5 points because I forgot to connect it as it is oft useless for the main of an application)". 

2. In the CLD success package, when I look at the solutions provided by NI, they all have error in as control.

Maybe NI should clarify their expectation on this...

By the way, I would hope everyone who comes here to learn something and pass the exam, instead of hoping someone "won't pass the exam".

---

First - The example solutions were never intended to demonstrate a "Perfect" 40 grade example- but passing code There may be some benefit to discussing their issues and seeing where they would have lost points.

I just looked back at the sucess package solutions- Perhaps you have an outdated success package?

Sprinkler and Boiler  user a BD Constant Default Error cluster

Car Wash and ATM use a USRwhen open and run FOR THE FIRST TIME that would be a default error type (Mallori- Those example needs to init that SR!)

Both top level vis use the 1 terminal connector pane with nothing wired-  I would discount post 10 on the LAVA Link you read.  Perhaps he was mistaken and lost that 0.5 point as a "Picky point" (a 40 would leave the developer with no room to improve) for leaving the default 4-2-2-4 pattern.

[jerryatnz]

Thanks for the comments Jeff.

Maybe you are right on that LAVA link - Perhaps he was mistaken.

When I mentioned the CLD success package, I meant the 17 sample exercises in the "cld_success_package.zip" from http://www.ni.com/gate/gb/GB_EKITCLDEXMPRP/US

When I went through all the solutions, they made me think it is a requirement to use error in as control. You may look at the last a few exercise solutions. 

Once again, I agree with you on using empty error constant for top level vi, and I do that in my daily work too. But, I just wanted to better understand NI's rules on this exam, not interested in challenging the rules, just wanted to pass the exam and move on 🙂

[Jacobson-ni]

This is my first attempt at the CLA exam.  I am not particularly happy with the result but I went into it after about an hour or two of preperation so I'm not surprised.

I learned a lot of what to do and what not to do but I figured I would post this if anyone would like to offer some advice.  I stopped right at four hours.

My Thoughts

1. The controller is a disaster, I realized I should have had a state machine way too late.  Don't try too hard to make sense of how it would work
2. I created each module from a base Message Handler and all of the Private VIs in each module.  I think I could have saved a lot of time if I had also made an Exit API call and copied that over.  I wasted a lot of time making probably close to 10 API calls from nothing before I realized I could just save a duplicate VI.  Plus an Exit API call is probably generic enough that I will need it for every state.
3. After reading the requirements I tried putting down all of the states I thought I would need into each message control then adding those states to the message handler.  This messed me up later on.  I didn't end up using half of those states and it was hard to keep track of documenting all of those states.  Towards the end I was making states as I needed and reusing what I could.

Any replies would be appreciated.

[rgwagner888]

Hi ,

Attached is my try at the Sprinkler Controller CLD Example. Thank you for your comments and critiques. Total time: 4:40

Kind regards,

Rick Wagner

[jerryatnz]

Hi Rick, can you save it to LabVIEW 2012 or earlier version so I can open it. I don't have newer version installed on my machine. Thanks.

[rgwagner888]

Here it is saved for 8.6

[jerryatnz]

---

@rgwagner888 wrote:

Here it is saved for 8.6

---

Hi Rick, I am preparing for CLD too, but here's my two cents:

- Functionality: When water pressure is low it's supposed to show "Low Water Pressure" instead of "Running".

- Front panel buttons description and tip strips should be added.

- Each sub vi should have vi description. 

- I would suggest simplifying the timer FGV, and the kernel sub vi inside the timer FGV. This application only requires start timer and read timer functions. You may consider using the elapsed time express vi in FGV, could save a few minutes.

I like the style, and comments in diagram. Good work.

[Jacobson-ni]

Rgwagner,

I thought you did a good job.  I would add a bit more documentation though.  Your process state has a lot of states but each one of them has a sentence or two about what is happening.  If you made sure that your other states (Initialize, Setup, Run , etc.) and your SubVIs had the same level of documentation you'll be good.

You are doing some form of error handling (enough for the CLD) but I would put a simple error handler outside of your while loop to make sure you are at least doing something with the error if one comes up.  I got a deduction for doing something really similar.

[Jacobson-ni]

I know it is pretty hard to review a CLA exam but I have my test coming up in a few days and wanted to throw in my second full attempt, this time on the ATM problem.

I spent a fair amount of time just looking through my past test and coming up with a few basic strategies for different modules then running through those a couple of times to make sure I could execute.  I also made sure I could quickly decide when I would want to go with one strategy over another and had a much better idea of the best order for me to do all of these tasks.

In the end, it took me about 3 hours and 20 minutes.  I struggled with finding good ways to meet application timing requirements and more broadly any task that had to communicate back and forth between modules multiple times to perform a single task.

Any tips would be greatly appreciated.

[Fisel]

Hi Matt

Two quick observations (being careful not to say too much...).  (OK -- three observations...)

1)  If you use variant data you'll want to make clear what LabVIEW data type the developers need to convert the variant to when the data is delivered for use.  It looks like you do define what data to send, so you're most-way there.  Your task as Architect/team lead is to ensure that different teams working semi-independently on different modules of the project use the same data types when those modules communicate. 

2)  The Text Array to store list of messages probably isn't the strongest solution.  It's not very scaleable (for example those messages need to be available for the Hardware module as well as the simulated).  Some form of File IO or otherwise more broadly available source would probably be better. 

3)  Regarding tasks that require multiple communications:  We're aware that this is a 4-hour exam, we're looking for the framework you establish.  In a given module, flesh out one case well and refer to that case as a guide for the developer to do the other cases.  (just make sure the developers have the data they'll need to do the task in those cases). 

Hope this helps.  Good work so far, and good that you've got time to spare!