08-08-2015 11:41 AM - edited 08-08-2015 11:56 AM
@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.
08-09-2015 01:45 AM
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 🙂
08-15-2015 05:05 PM
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
Any replies would be appreciated.
08-20-2015 10:29 AM
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
08-20-2015 12:35 PM
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.
08-20-2015 05:00 PM
Here it is saved for 8.6
08-21-2015 12:23 AM
@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.
08-24-2015 06:21 PM
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.
08-24-2015 06:33 PM
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.
08-25-2015 12:44 PM
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!