LabVIEW
Car Wash CLD Sample Exam Solution
Here are my thoughts....
Your solution is functional, so there are points for that right away. Where I think there could be some more work is the architecture. The exam requirements state that the design must be "easily scalable". To me that means new states or cycles can be added without much messing about on the block diagram. If you notice, there are only certain... lets call them Properties of each cycle type. You could have an array of cycle properties such as cycle time, cycle position switches, cycle name, and flags for standard or deluxe. Then you could reduce your cycle handling to a single state that just indexes through the cycle array and executed the next appropriately flagged cycle.
I noticed a Select node in each of your cycle states with constant True and False wired to it. That is a total of three elements plus two wires that should have just been a Not right off of the Boolean palette.
You stop the program with a Stop button, yet you allow the user to close the window. You should consider a Panel Close? event in your event structure to handle a use trying to close the window so that you can execute a graceful stop.
There is no VI Description filled out for your main VI. You should also have an icon for the main VI. The suggested front panel shown in the exam has an icon.
When your VI is running, you have the scrollbars, toolbar, and menu bar shown. None of those serves any function for the application, so they should not be shown at runtime.
The Stop button that is used to stop your application is reset with a Property Node. Not that there is a performance issue here, but it is generally not good practice to do that unless you are forced to. Consider just using a Mechanical Action of Latch When Released instead of Switch When Released. That way you do not need to force the reset to the False state. Of course, I would rather see something like a Stop state writing to the While Loop conditional terminal. Also, you could have used a Local Variable to write the initial state of the Sim Switches instead of the Property Node.
The graders like to see code comments describing your algorithms. I would say that you need more of those.
A 10 msec timeout on the event structure is a bit hyper. Nothing in the system runs that fast, and the only thing you are waiting for is the user. You could actually have a -1 wired there if you add an event case for the Stop button and Panel Close. It will greatly reduce the CPU cycles (again not that there is a huge performance issue here).
Come to think of it, the 20 msec wait for next multiple timer is a bit hyper too. Your timing requirements are on the order of seconds. You do not need to loop that fast.
In general I prefer to have the Event Structure outside the State Machine. Either that, or I use the Event Structure as the State Machine (in place of the Case Structure). That way, if you need to respond to the user interface, you can do so without waiting to cycle back to the Idle state.
This one was not listed in the requirements, but it would be very helpful to see the clock. A cycle countdown timer or elapsed time indicator is so helpful to the user and the grader. It confirms that things are working properly and the the application has not sieved up. Users like to see something "alive" on the screen.
To end on a positive... good job remembering to Disable the Purchase Selection buttons once the user clicks one. I got ding'd for forgetting about that back when I took the CLD in 2003.
Ravens Fan wrote:
Whereas 99% of the world uses .zip
Yeah, and 99% of them press the "Buy Later" button in WinZip.
I'd only add that you should run the error cluster through your sub VIs and property nodes.
