Certification
Review my CLDs?
Okay so I only looked at the ATM and you forgot to attach the PDF requirements but here are some general comments.
You mixed terminal views on the block diagram. I highly prefer the non-icon viewed terminals, but several subVIs have terminals as icons. I'd recommend you be consistant.
Minor but I prefer block diagram terminal labels to be on the left for controls and right for indicators, and to have their labels be transparent not white. I doubt you'd get marked down for this.
Lots of un-needed wire bends.
Several wires going the wrong direction.
Several objects on top of each other making it hard to read at times. In general things seem to be too tightly spaced.
Many subVIs could use cleaning up. Align terminals, minimize bends, align front panel controls, resize FP and BD windows to fit the contents better.
The Initialization section, doesn't need the sequence structure. Get rid of it. Same with the clean-up sequence structure at the end.
There aren't any tip strips or descriptions on the front panel controls on the main UI.
You used a default icon for the main VI.
There is at least one property node that could be eliminated by using the control terminal to read the value.
There is room for more comments on the block diagram but I think you had an appropriate amount.
Overall I think you did a pretty good job. Using classes isn't something you see often on a CLD. The majority of developers find the 4 hour time limt the biggest issue. Coding up several classes is something that takes extra time, which is why it is probably not used often. But you must feel comfortable going this way, and you seemed to get the needed functions done.
Danielle,
The functionality of your code is great, but remember the CLD is graded on documentation and style as well as functionality. I will speak to the ATM project because I did that practice exam as well and remembered the basics of what it was supposed to do.
For documentation remember that Front Panel controls should have associated tip strips and each VI should be documented (Ctrl+i is helpful for the CLD). I always suggest that every time you drop down a structure, immediately add a sub diagram label where you explain what each case or frame of that diagram does. I will also parrot every single programming professor by urging you to document as you code.
I think style will be what you should focus on most in preparing for this test. Always try to avoid overlapping structures and crossing wires as much as possible. If you have LabVIEW Professional development system you will have the VI Analyzer Toolkit which I would recommend using this when reviewing your own VIs.
It is okayso sacrifice a bit of functionality to improve the readability of your VI. I found the following in your VI.
It only takes a minute to fix a lot of those wires to make it look a little better.
Your functionality was good, knowing you only have 4 hours the only change I might make would be to change your main while loop to a state machine with an initialize state consisting of the first sequence structure, a running state for your event structure, and a terminate state for your last sequence structure. This is a pretty minor change but would let you view the entire VI on one screen.
Just keep calm and remember that full functionality is not a requirement to pass this exam.
So far I only had a look at the atm. As the others already said:
Documentation: estimate 2-3/10
- default icon on launcher
- no summary help print
- a lot of structures without comment
- top level vi documentation is too weak as documentation. You are rectifying your architecture rather than describing the rough layout of the architecture
- no documentation of controls in launcher (Description + tip strip)
Style: estimate 10-11/15
- wires often not straight
- backwards wires
- unconnected error terminals (e.g. format into string in display message.vi)
- you used default values on structure outputs (event cases, case structures)
Functionality: estimate 15/15
- I haven't tested it
total estimate: 27-29/40
too close too call. My gut feeling is that you probably wouldn't have got this one.
Try to finish coding about 30 min to the end and really concentrate on documentation and correcting style (If you are comfortable with using VI analyzer it can help you to find possible problems). In these last 30 min you can probably easily gain 5-10 points in style and documentation while if invested in coding you can be grateful if you manage to get another 2 points. After all it is a race for points and functionality is only worth 15/40. So if you would get full marks in style and documentation you would only need 3 points from functionality. My peers considered functionality so unimportant that they never even bothered to check it when I asked them to look through my practice exams.
Main advice: Don't panic about functionality. If you submit a fully working piece of code with lacking documentation and bad style you will fail. If you have a piece of code which has half of the functions implemented and good style and documentation you will likely pass.
edit: re error handling: what you are trying to do is not part of the requirements. If it is not a requirement I strongly suggest to keep away from it as it is wasting time that you could otherwise spend on doing things which ARE part of the requirements (including documentation and style). As I said, it is a race for points and you are not going to get brownie points for having an elaborate error handling that wasn't asked for.
Hi Danielle,
on the top level diagram. File -- > print
select the top level vi and make a html help print and don't forget to link it in the vi documentation help path. It's worth a point.
cheers
Mathis
