Certification
CLD ATM Mock Exam - Review
Solved!
Hi All,
I am planning to take up CLD next week. Find my solution for ATM machine attached. Please review at let me know your comments.
PS: LV version used is 2014.
Hi All,
Please find my solution for Car Wash attached. Kindly give you comments.
PS: LV version used is LV 2014
Thanks,
Sree
Sorry, I didn't know that. Thanks for letting me know. I will post it there from next time.
Regards,
Sree
@Senthil_Prakash wrote:Hi Ranjani,
I reviewed your code whenever ' Vehicle Out of Position' is ON Wash Entry status should be 'Wash Vacant' that makes the sense since there is no vehicle Wash Vacant should be the Status but in your code it showing 'Wash in Progress' it shows
This is incorrect from both a requirements viewpoint as well as a logical one. You don't want another car to be able to enter the wash if there's one already in it!!!
There is no requirement for the "Wash Vacant" light to come on in any condition other than when the car has exited the wash, or if the "Stop Program" button has been pressed. (Or upon starting the application, of course.)
The picture shows the appropriate behavior.
Okay, let's get to it! 😄
Style:
I don't see anything particularly egregious.
Wires running in through the top of your case structures and running under the sub-diagram comments may get you dinged.
The "Wash Entry" indicator somehow got partially hidden under the while loop. I mentioned this because you should be careful that creating space in your block diagram often leads to stuff you need to clean up.
I'm not a fan of using constants to initialize things. I'd rather define them in a global so that if I want to change the values, I don't have to hunt through the VIs to figure out where it was initialized. This also makes it possible to easily load values from an initialization file such as an xml of ini file in the future. This affects scalability.
Main while loop shift register is uninitialized.
There are a few wires that aren't "optimized". They are fine to me, but I think the graders use the VI Analyzer so they will show up there.
Project well organized, and it exists. (You'd be surprised at how many mock exams are posted that have no project!)
The use of subVIs where appropriate is a welcome sight.
Typedefs and stuff. All good.
Use of AE - thumbs up!
Demonstrated knowledge of newer features - you are up to date:
Use of conditional terminal.
Clusters as icons.
Error Handling - appriopriate for the scope of the test.
This has the overall look of being made by someone for whom the CLD will be a formality. Do you have your CLAD? That's a requirement for the CLD.
Functionality:
Page 4, Start:
Note The High Pressure Wash step is the default wash. If the user did not select High Pressure Wash, or if the user did not select any options, High Pressure Wash must be added to the options programmatically after the use clicks Start.
"High Pressure Wash" is not being added to the options if the user has not selected it, but has selected anything else on the menu. The easy fix is just to add it by default, regardless of anything else that happens. No need for any kind of fancy logic for this one. I think I just set the value of the button TRUE for cosmetic reasons and didn't even bother reading it. I just made the option TRUE when deciding what to do.
Documentation:
Yay, you actually put a lot of thought into this!
The use of both label and sub-diagram labels is a favorite of mine, particularly as you use it in your For Loops and your Case Structures.
You organize your state machine states even better than I do.
I guess that's it!
Senthil and Bill,
Thank you for your feedbacks.
Bill,
Your feedbacks were really helpful. I have few questions stated below. Please give your suggestions.
Style:
"I'm not a fan of using constants to initialize things. I'd rather define them in a global so that if I want to change the values, I don't have to hunt through the VIs to figure out where it was initialized. This also makes it possible to easily load values from an initialization file such as an xml of ini file in the future. This affects scalability."
I am bit confused about this point, are you mentioning about Functional Global or LabVIEW Global Variable? Can you give an example?
"There are a few wires that aren't "optimized". They are fine to me, but I think the graders use the VI Analyzer so they will show up there."
I haven't thought much about this. I will try to optimize my code hereafter.
"This has the overall look of being made by someone for whom the CLD will be a formality. Do you have your CLAD? That's a requirement for the CLD."
Yes, I have taken up CLAD 🙂
Functionality:
Regarding High-Pressure Wash, I got little confused with the question and missed it.
Documentation:
Should I add documentation to all "Typdef/Control descriptions" (in .ctl file properties) also?
Should I add Description and Tip Strip to subVIs controls or is it sufficient to add it only to main VIs controls?
Thanks,
Sree
@SreeRanjaniSG wrote:Senthil and Bill,
Thank you for your feedbacks.
Bill,
Your feedbacks were really helpful. I have few questions stated below. Please give your suggestions.
Style:
"I'm not a fan of using constants to initialize things. I'd rather define them in a global so that if I want to change the values, I don't have to hunt through the VIs to figure out where it was initialized. This also makes it possible to easily load values from an initialization file such as an xml of ini file in the future. This affects scalability."
I am bit confused about this point, are you mentioning about Functional Global or LabVIEW Global Variable? Can you give an example?
Sure, in a case like this:
I'd rather put these constants into a global.vi so that I know where to change the values if I need to. This also makes it far easier to implement a config file because all you need to do is read the file and write the values to the global. This is a good way to use globals - i.e., write once, read many.
"There are a few wires that aren't "optimized". They are fine to me, but I think the graders use the VI Analyzer so they will show up there."
I haven't thought much about this. I will try to optimize my code hereafter.
Yeah, this had nothing to do with your code. Just test advice. 🙂
"This has the overall look of being made by someone for whom the CLD will be a formality. Do you have your CLAD? That's a requirement for the CLD."
Yes, I have taken up CLAD 🙂
Functionality:
Regarding High-Pressure Wash, I got little confused with the question and missed it.
Requirements are tough to interpret, sometimes, especially when they are not written as a "formal" requirements doc. If you have trouble understanding a requirement, MENTION IT IN THE CODE AS A COMMENT! You stand a good chance of getting at least partial credit if you explain that you were confused and why. (More test advice.)
Documentation:
Should I add documentation to all "Typdef/Control descriptions" (in .ctl file properties) also?
I waffle back and forth on this all the time in real life. For the test, I would put them in.
Should I add Description and Tip Strip to subVIs controls or is it sufficient to add it only to main VIs controls?
I believe the main front panel should suffice.
Thanks,
Sree
Oh, one other thing I didn't notice first time 'round. Try to resolve all the coercion dots that you can.
Bill,
Thank You for your comments. I will document my assumptions to avoid confusion hereafter.
