It seems to function correctly (as far as I remembered the specs).
With regards to style one of the best testing tools is the VI Analyzer.
By using this on your code I found out that you had at least one reversed wire and several unnecessary bends.
Also I would advise you to take a marging with your responsiveness.
On some of the exams you might need 2 states to do/perform a certain action.
In that cas you could use a wait vi with a constant = 50 wired to it, just to make sure you're "in time". ( I know a lot of people won't agree on this, but at least you'll meet that spec).
One thing that is also a bit unclear is the responsiveness to the stop button.
The time between pressing the stop and quitting the app could be more than 100 ms in your case (as far as I remember).
If you have a new test available, then please let me know.
The main advice would be to try as much as possible and define certain steps in your head depending on which kind of application you get..
I'll post the boiler example soon. I just finished it Thank you for your time !!!
Thanks for encluding the requirements in the zip. Did you know you could have added them to the project? (Yep- any file can be in the lvproj)
Documentation: Tip strips should be user oriented. "Press to start the selected sequence" is user oriented "Selected Sequence" is not user focused
A BD cleanup on the logging AE would help (but I like the AE usage a lot!)
Did you really need a wire label on error? the color is unique.
Yup nit picky- take the exam. nicely done!
Averna Automated Test Systems
One thing that I did see (which could cost you points) is that not each case of each case structure has a description/comment in it.
Normally you should try to put in each case you have (doesn't matter if it's in a subVI or the main VI) a short description of what should happen.
On the highest level (your main VI) this will also give an explanation of what should happen in your states.
This will help you think about what you're actually supposed to do in your code.
Some of the benefits of doing this:
- Could give you extra style points
- Could give you extra documentation points
- Could help if a function performs only partially according to specs (as long as you also note that in the free label/comment)
- No description nor tip strip for your controls in the logging subVI.
- Constants should have their label visible (even if they are states or commands/controls for you FGVs)
- Try to also create an icon (text only should also be ok) for your type definitions.
Just finished the ATM example, my first post didn't work so well, hopefully this one works. I spent the last hour trying to add documentation and get the write to file part exactly right. I get extra spaces in my text file which doesn't affect the overall functioning of the program but bugs me. Thanks in advance for comments.
Have you already found done some debugging on why you have those empty lines?
I think we best start over there.
I am going to take a simple guess:
You probably spent a lot of time on the reading and writing from/to file part?
It would have been easier and more comfortable for you to just have used the read and write to spreadsheet file VI's at both sides. (with 2D Arrays inputs and outputs)
One small hint: Your issues come from the differences between these two implementations.
At one side you have the low level parsing. At the other side you use the high level "write to spreadsheet file" VI.
Hi ThiCop, thanks for the reply. The read from file part was done fairly easy, I saved the write to file part for the end because I wasn't exactly sure how to execute and wanted to get the rest of program functional. I spent my last hour adding documentation and trying to get the write function just right. I'll look at implementing the read and write to spreadsheet vi on both sides.