01-11-2016 10:49 PM - edited 01-11-2016 10:50 PM
Hi,
Attached is my solution to theCar Wash sample exam, I'd appreciate it if someone would look at my ATM solution and tell me what you think
thanks!
Mohamed Bakr
01-12-2016 08:11 AM
I'd say it is pretty good. There is room for improvement for sure but overall I think it covers almost all the requirements, and it is structured in a simple, but correct way.
First I'm not certain but I think that there was a requirement that when a vehicle is done, and it makes it to the exit, that the software will reset, and allow for another car to be washed. If this isn't the case never mind, but I think having the ability to choose wash settings and click start again is needed.
Here are a few nit-picking issues all of which are minor. I see mixed control styles used on subVIs. I generally only use one style in VIs that are never seen, modern. But using all classic or all silver isn't a big deal either just being consistent might help.
I see a mix of icon, and non-icon view for terminals in subVIs, I'd say be consistent, but personally I prefer the non-icon view. To help this make sure and change this setting in Tools >> Options when you first get the machine.
There is some over lap of wires behind objects, and labels over objects.
Some code could be simplified, like the Determine Wash Cycles VI. In the past I've seen people would use the cluster reference, then use that and query all boolean references in it using a property node. The benefit of this is then getting the value of the buttons, and the text of the buttons that are true, can be don in a for loop, instead of using 9 select functions, and a build array. This is also a more scalable design.
Why do you use Enqueue at Opposite end, instead of Enqueue?
Some boolean operations could be simplified by using a compound arithmetic.
Some unnecessary wire bends.
I think there could be more comments in the subVIs. I think one check will be if every VI has at least one comment. That is one of the default tests in the VI Analyzer.
I don't think you need an uninitialized shift register for reset, that should probably have a constant, so the program startups up consistently each time.
I didn't see any error handling on exit, by that I mean if an error happens is the user prompted? I'd just drop down a simple error handler at the end. Oh and if an error happens, then the code in the shutdown case won't do anything (except release the queue) because an error into those property nodes cause it to do nothing.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
03-01-2016 03:39 PM
OK a few things I see:
As Hoovah said- overall not bad but could be improved
03-02-2016 01:08 PM
Placeholder.txt is just a text file that NI includes
03-02-2016 01:24 PM - edited 03-02-2016 01:39 PM
@Gregory wrote:Placeholder.txt is just a text file that NI includes
I see.
Historically, that sample exam had a requirement to hold "Step Time" and "Station#" for each "Wash Step" in a file. The latest spec omits this requirement. and provides a table instead. I was not aware of the Spec change and, thought I had a valid miss on your submissions functionality.
Your Actual CLD will have a File IO requirement.
Bonus points: How would you modify your code to enclude that requirement?
That is actully a really good bit of practice because you can be sure in the real world you are going to have a conversation like this:
You: Hey boss, that Car Wash App is done, tested and ready to ship!
Boss: The client came back and told us they have a lot of pressure from the marketing team to "Go Green" to differentiate their product. They want to be able to save water. Can you make the step times adjustable?
You: ?
Boss: Also, Their Field Sales Team is finding that a lot of potential clients gust do not have the room for a full sized system so they want to combine station 1 and 2 on a shorter model.