Certification
Sample Exam Solutions for Review
@kbrezina wrote:
@billko wrote:
@kbrezina wrote:
Bill,
Thanks for the feedback, I really appreciate your time!
In hindsight, I certainly missed a few obvious things, such as putting it in a project and handling errors. I do these daily, so I'm a little surprised I missed them.
I definitely made some bad decisions for the sake of time management, such as the default tunnels to help debug faster, the sloppy wiring, and the lack of subVIs.
Nice catch on the "future development" comment, haha. The first thing I did was make an initialize state, and the last thing I did was comment code. By then, I didn't feel comfortable deleting it, so I just flubbed the purpose.
I will definitely use the predefined states for my state machine next time.
I am personally very comfortable with this design pattern, although I realize it does not necessarily fit one designated by NI. Is it unwise to use user event driven queues to influence my state machine without actually wiring the queued data to the case selector?
Again, thank you for the review! I will take all of your recommendations and utilize them on my next practice CLD!
-Kyle
I'm somewhat scatterbrained, so making the states match up with the main topics really helps me to stay organized. Sometimes a step doesn't make sense to keep separate from the one after it, so I combined the two steps into one and noted that the empty case was deprecated and no longer in use. SubVIs kept me organized because they roughly corresponded to a paragraph each. This kept the block diagram nice and tidy.
I don't think it's unwise to use a non-standard pattern - at least in real life - although I will say that the standard patterns are standard for a reason. You don't want to make the grader scratch their head over this one. Use an easily recognizable pattern. I do think the grader will frown at the way you used the event structure.
It's funny - most people dop the error handling last. For me, it's one of the FIRST things that I do. It makes it very easy to figure out where your coding mistakes are. 😉 You don't really need shift registers on your error wires because you should have error handling at the back end of each loop. For the purposes of the exam, I think that exiting in an orderly fashion on any error is good enough to show them that you understand how to handle errors.
When I was practicing for my exam, I was unemployed, so my job was to practice once through every day, with a self-review afterwards. It gives a good idea of your strengths and weaknesses.
I think the best advice I can give you is to practice until it gets boring. I chose one design pattern for all the examples, simply to give me a familiar starting place. It came in handy at exam time because I didn't have to panic about how I was going to approach the project. I just started out setting things up and it was calming because it felt so familiar. By the time it came to the unique stuff, I was in a state of mind where I was ready to tackle the project. By the time I was done studying, I knew my stregths and weaknesses so well that I predicted my score to 1/2 point. 😉
When are you going to take it?
Thanks for the advice about the standard design pattern. The "Producer/Consumer Design Pattern (Events)" is exactly what I was intending to do, and now I can save myself 10 minutes by starting from the template!
I am lucky enough to be able to leverage some of my office time to study, as it's work related. I am taking the exam next week, as long as I feel confident in doing so. I hope to work through at least two more before then.
Thanks again for your help, Bill. I'll let you know how I do!
-Kyle
Good Luck!!! 🙂
I goofed up the because of the SAME THING (.ini file woes). I have to say that this sample try is a totally different animal from the first one. I think this passes without a problem. About the only comment I have is that you finished and I didn't. AND you finished and didn't sacrifice too much on style, either! 😛
That is the Rasberry of Well-doneness.
@kokthiam.chiam wrote:
Hi,
Here is my CLD ATM sample exam for review...
You still have a ways to go.
You have absolutely no error handling. If this was turned into an executable, we'd never know why our application was misbehaving.
You have no error wires running to the states loop.
You have backwards running wires.
There is little evidence of the understanding of dataflow.
Your controls - specifically the latching booleans - need to be in their respective event handler so they can be assured of being read (and reset) when the event is fired.
It's hard to say because I am remoting into the computer that is running your code, but it seems a bit unresponsive. Possibly because of the reason above. Like maybe out of spec kind of unresponsive.
Using the timeout to check for a timeout is not the way to do it. The timeout event should trigger the timeout.
No documentation to speak of.
Seriously, taking the tutorials will help you. You won't pass the CLD by trying to wing it. You need to have a solid understanding of the way LabVIEW works.
@kokthiam.chiam wrote:
Hi Bill,
Thanks and appreciate your quick review. I would like to clarify the reasons for my code, and would appreciate if you can spend some time to point out if I'm wrong.
You have absolutely no error handling. If this was turned into an executable, we'd never know why our application was misbehaving.
> The only error handler that I can think of is probably the account file is missing (not included in the code). Is there anything else that needs to be handled? Eg Should I connect all the error in and error out? If it's an error, what should be performed?
The requirements clearly state that there should be error handling. Probably for the test, a simple graceful exit on error should be good enough. The theory is that just because you aren't expecting errors doesn't mean you shouldn't be ready to handle them. It's the errors you aren't expecting that will get you into trouble. What happens if you took an error in your queue? Some of your error in and out clusters aren't connected to anything. All subVIs should have the ol' error passthrough setup with the error/no error setup. (This I disagree with, but that's the offical comment from an official grader. In this case, we're not talking about "rightness" or "wrongness" but what they want to see.)
You have no error wires running to the states loop.
> This is the same concern with the above
See above.
You have backwards running wires.
> Do you mean wire from right to left? Are you referring to the case structure selectors?
I didn't continue down this path for reasons unknown. I guess I just stopped looking at the style points. I just noticed that the one FG that I opened up had backwards-running wires. But in general, there are too many kinks in the wires. The BD is bigger than it needs to be (and this is because there is scant use of subVIs - except for your functional globals). Lack of subVIs also tend to make your wires crazy bent because the more you open up room for your code, the wilder wires in other cases get stretched. I'm not sure where to put this, but the grader will frown if you wire a typedef'd constant directly into an input. The theory is that if the typdef changes, the constant gets reset to the default values. Always bundle. We ALL bundle... (referring to a cable company commercial). The whole BD is sloppy. Think of it as indents in a text-based language. You can use random indents - the compiler doesn't care - but it won't be easily readable to a human being.
There is little evidence of the understanding of dataflow.
> Erm.. could you please point me some examples of how I can show this better? I don't wire some of the property nodes / sub vis together because I dont need to force the flow sequence.
I officially take this back. There are depencies where they need to be. I look at too many VIs where people don't understand what dataflow is, and at firts glance, it seemed like another one of those VIs. A closer look reveals that you do actually understand the concept.
Your controls - specifically the latching booleans - need to be in their respective event handler so they can be assured of being read (and reset) when the event is fired.
> I put the controls in the while loop, where it will always be read, thus resetting them. Putting them in the event will also work. That's why I didn't put it into the event case.
I actually don't know if you get points off for this or not. The LV help clearly states that this is the recommended way of doing things though. I'm guessing because if they are just floating in the while loop, they may end up getting read first and then you have to wait until the next iteration for a reset. Noticeable if you have a lot of stuff going on in the event case - which you really shouldn't.
It's hard to say because I am remoting into the computer that is running your code, but it seems a bit unresponsive. Possibly because of the reason above. Like maybe out of spec kind of unresponsive.
Using the timeout to check for a timeout is not the way to do it. The timeout event should trigger the timeout.
> Noted. Will this be better if the timeout check is placed in the consumer loop?
I just made the timeout 10 seconds. If the timeout event occured, do the timeout stuff. I made the timeout -1 until I needed it to be 10 seconds.
No documentation to speak of.
> I put little comments here and there and also on each sub vi documentation. Perhaps I need to put more.
Constants should be labeled. Each event should be labeled. Each case in every case structure should be labeled (many of them aren't). Your main vi doesn't have a meaningful icon. (I almost had to put a string on my finger to remember that one.) I think you were fairly good at labeling long wire runs. Try to get as many documentation points as you can. It's the low-hanging fruit, if you will.
