Certification
Sample Exam Solutions for Review
Please help review my first attempt on ATM practice exam (in LabVIEW 2012).
It took me about 5 hours to finish, with a few interuptions - apparently I need to work on speed, and get more familiar with quick drop short cuts.
When I design the state machine, I tend to break down the process into small pieces. I listed all the enum states in the block diagram. When I write code for each state, it helps remind me where I'm at and how far I need to go. I think it's also for documentation purpose.
I will be taking CLD exam in September. Any advice is appreciated.
@jerryatnz wrote:
Please help review my first attempt on ATM practice exam (in LabVIEW 2012).
It took me about 5 hours to finish, with a few interuptions - apparently I need to work on speed, and get more familiar with quick drop short cuts.
When I design the state machine, I tend to break down the process into small pieces. I listed all the enum states in the block diagram. When I write code for each state, it helps remind me where I'm at and how far I need to go. I think it's also for documentation purpose.
I will be taking CLD exam in September. Any advice is appreciated.
I don't have LabVIEW installed on this computer so I can't see the code, but here's a few general tips that maybe you haven't heard before.
One thing I can think of is that if you use a reasonable amount of subVIs, you can partition off stuff you are working on so if you run out of time, you can simply not include/delete the subVI from your main VI and avoid the dreaded "broken arrow and I don't have time to fix it" syndrome.
Also, whatever your method of practicing, do it a lot. Try each practice exam randomly until you are bored with them. Of course, the familiarity will make it easier every time you practice, but I wouldn't worry about that unless you find yourself still barely making the 4 hour time limit. You should then be able to instantly recognize which attack plan you are going to use when you open the exam, and that familiarity will largely help you avoid the initial "freak-out" phase and you can get right down to business.
This is nicely done. I had three thoughts that might be helpful:
- Visually, the style and documentation look good -- have you run it through the VI Analyzer to verify that you're not losing any easy-to-collect points?
- Make sure you are prioritizing the functionality and have something that will run at the 4-hour mark. Next sample exam you do, perhaps you could stop at 4 hours, note what's working, then continue.
- Before the actual exam, make sure you can also use and parse out .csv and .ini files, and are comfortable with timing including pausing and resuming the time as it counts either up or down (you can practice these skills using the CLD success package exercises).
Keep going! It looks like a September CLD is very feasible for you.
@Fisel wrote:
This is nicely done. I had three thoughts that might be helpful:
- Visually, the style and documentation look good -- have you run it through the VI Analyzer to verify that you're not losing any easy-to-collect points?
- Make sure you are prioritizing the functionality and have something that will run at the 4-hour mark. Next sample exam you do, perhaps you could stop at 4 hours, note what's working, then continue.
- Before the actual exam, make sure you can also use and parse out .csv and .ini files, and are comfortable with timing including pausing and resuming the time as it counts either up or down (you can practice these skills using the CLD success package exercises).
Keep going! It looks like a September CLD is very feasible for you.
Thanks Fisel for reviewing code and comments.
I have just run it through VI Analyzer. Couple of questions:
1. It doesn't like me listing all the enum states on block diagram, because it's considered as "unused code". Although I thought it is good information for someone to quickly understand the state machine, which can serve as documentation purpose. But in the actual exam, shall I keep this? If this is not a good practice from code efficiency point of view, I'll just delete them, or replace them with free label comments.
2. VI Analyzer suggests to connect "error in" (on the main vi) to a case structure. I would agree if it was for a sub-vi. But this is main vi, isn't it redundant?
@jerryatnz wrote:
@Fisel wrote:
This is nicely done. I had three thoughts that might be helpful:
- Visually, the style and documentation look good -- have you run it through the VI Analyzer to verify that you're not losing any easy-to-collect points?
- Make sure you are prioritizing the functionality and have something that will run at the 4-hour mark. Next sample exam you do, perhaps you could stop at 4 hours, note what's working, then continue.
- Before the actual exam, make sure you can also use and parse out .csv and .ini files, and are comfortable with timing including pausing and resuming the time as it counts either up or down (you can practice these skills using the CLD success package exercises).
Keep going! It looks like a September CLD is very feasible for you.
Thanks Fisel for reviewing code and comments.
I have just run it through VI Analyzer. Couple of questions:
1. It doesn't like me listing all the enum states on block diagram, because it's considered as "unused code". Although I thought it is good information for someone to quickly understand the state machine, which can serve as documentation purpose. But in the actual exam, shall I keep this? If this is not a good practice from code efficiency point of view, I'll just delete them, or replace them with free label comments.
2. VI Analyzer suggests to connect "error in" (on the main vi) to a case structure. I would agree if it was for a sub-vi. But this is main vi, isn't it redundant?
My thoughts on your questions:
1) I don't know if it's time-savvy, but you could snip the picture of your enum explanation, copy and paste it into your VI as a free label!
2) I used to think it was redundant also until one day I found user-generated subVI at the beginning of the error chain that actually had an error accidentally saved into the input error cluster as one of its default values! So now I do exactly what the exam suggested. Start the error chain with an empty error cluster.
Thank you, Bilko. Using a lable instead of the "code" provides a double win for test scoring, as it removes the objection and adds documentation! I'm thinking a text lable rather than an image might be useful, allows copy-&paste to keep names consistent and maybe cut-&-paste as a way of keeping track of which cases have been used and which remain unused.
You might have miss-read about the Error In. If you use a BD Constant rather than a Control on the Top Level VIA ill not ding you for improper error handling. ITS TOP LEVEL so, there should be no wired controls or indicators anyway! 
(Wired controls and indicators are those that are wired to the connector pane) This also gets you around the "Wired Controls not on root BD" ding see The Clearing the Mud Nugget
So, Why would Error In be a control? Are you planing on writing to it via a Local? If so WHY? it will only be read once or, you did something VERY ignorant! I wanted to say "Bad" but it would, in fact, be worse than bad, it would show a practical missunderstanding of LabVIEW to the point that I would hope you won't pass the exam. Will Error In ever be anything other than <F, 0, "\00">? By making it a constant VIA realizes that wiring it to a case structure would only introduce "Unreachable Code" in the True (Error) Case and, it prevents some "Moron User" from actually changing the value before running the top level VI.
Now About those Enum Constants... Didn't you LIST those values in the VI Documentation for the type def so they SHOW UP in the help window for the next developer? And, of course, you did that documentation even before you edited the Items RIGHT? At which point there is no need to put that same info on the callers BD just Ctrl+H and hover over and constant to see the same info
