11-05-2014 04:39 PM
11-05-2014 04:42 PM
11-06-2014 02:39 AM
Hi Anderson,
thanks for your feedback. A press on the keypad will send a message to the controller. Depending on what the ATM is currently doing the controller is going to send a message back. I did my best to build up the modules in a way that they have one job only which is basically the essence of object oriented programming (even though my implementation is obviously not OOP): Display module displays, user interface takes inputs, controler controls, etc.
Regarding error handling that was expectedly missing as I ran out of time. As I mentioned before, with the practice I recently had I expect to finish all requirements ... the real test will be the escalator exam which I will try on the weekend (this time without having a sneak peak into the requirements + sample solutions before trying).
What I'm unsure about is the level of implementation. Is it ok the way I've done it (Enqueuer API VIs) or do I need to do more e.g. is it sufficient to tell the developer that he/she has to cast the varient into datatype xyz or do I need to drop a "variant to data" node on the BD? Where do I need to extend my documentation (it doesn't feel sufficient), basically: where am I losing easy marks.
I will have a look at you exam when I get home. I have only 2011, 2012 & 2013 installed at work.
best regards
Mathis
11-07-2014 11:54 AM
Hi,
I did now finally get round to looking at you example. Your example showed me generally where I am lacking which is documentation. The 2-3 word descriptions which are followed by a [covers:xxx] are not really understandable. Have you copy pasted the tags from the file? I did find a few typos ([convers...) for which you wouldn't get the marks (user console: [Convers: ID1C]; ATMControl: [Convers: WD1D]). Also [Convers: WD1D and WD1E] (even if it was spelled right) would not give you any marks. It needs to be: [Covers: WD1D] [Covers: WD1E]
You might want to reconsider your architecture. It seems to be a general mix of event structure and queued state machine and sometimes both (dequeueing in the timeout case of an event structure) which obfuscates how the data flows (this might get penalised in the architecture category). There are generally a lot of error terminals missing or unwired which will make error tracking difficult (this might get penalised in style). I have not found any error handling but as those are the last requirements in the list it might have been simply that you didn't get to that point (as you remember, I had that problem)
There are a few things that I would personally not do but I don't know if that would get picked up on. Just as an example: You convert your cluster of buttons into an array and then want to pick out which was pressed after converting it to a number. That means that the lowest significant bit will translate to the number 1, the next to 2, the next to 4, 8, 16 and so on. This makes the case structure really awkward as you will be ignoring the case of two buttons being pressed. Personally I would probably not even go into that detail and simply give the instruction to implement code which filters out which button was pressed.
Hope it helps
best regards
Mathis
11-07-2014 03:20 PM
11-08-2014 02:08 AM - edited 11-08-2014 02:11 AM
Hi,
I did now also have a look at your solution. It looks all very good. More documentation is definitely needed in the launcher. You also need documentation on the BD of the modules describing the function of the modules. You might want to consider hiding the queue communication away in an API as the communcation will definitely change once hardware is brought into the game and a proper API makes it easier to exchange these bits for a developer in the future. Don't forget that the VI documentation shouldn't stay empty. I usually copy paste the comment I made on the BD into there ... just so that it doesn't get picked up on by VI analyzer.
Style wise you should get rid of the default icon numbers which are displayed on all your VIs. This is easy: when setting up LabVIEW go to Tools --> Options --> Front Panel --> untick "Use numbers in icons of new VIs (1 through 9)".
I'm going to upload the escelator example this afternoon, it would be great if you could return the favour and have a look through it 🙂
best regards
Mathis
11-08-2014 10:22 AM
Here now my elevator project.
It took me about 3.5 hours which I think is good considering that I will lose time by not being accustomed to the computer/environment.
For the general structuring. I created a dummy module (template) which I copied across to create the individual modules from it.
I would really appreciate some feedback
thanks a lot
Mathis
11-09-2014 05:33 AM
So there is more of a chance to get some feedback, here now also in LV2013
11-09-2014 09:07 AM
@Mathis_B wrote:
Here now my elevator project.
It took me about 3.5 hours which I think is good considering that I will lose time by not being accustomed to the computer/environment.
For the general structuring. I created a dummy module (template) which I copied across to create the individual modules from it.
I would really appreciate some feedback
thanks a lot
Mathis
They should let you set up the environment the way you like if you arrive early for your test. At least that's how it was for my CLD. Check with the proctor to see how to do this. Some will let you bring a copy of your LabVIEW.ini file. Some will interpret the rules a bit stricter and you will have to bring screenshots of your options settings with you.
My proctor for the CLD was strict and (rightfully so, IMHO) would not let me put anything on the computer before exam time. She did understand about setting it up beforehand though, so she was totally okay with letting me bring some printed screenshots for her approval. I invited her to watch me set up LabVIEW and then I handed over the papers with the screenshots over to her so she could lock them up for the duration of the exam.
11-10-2014 05:07 AM
Hi Bill,
you are completely correct that you can set up the LabVIEW environment as you want it. Nevertheless you are going to use a mouse and keyboard which will feel and react differently, the screen has unfamiliar brightness and contrast settings. The chair isn't what you are used to. The general lighting in the room is different from what you are used to. And there is the extra tension from it actually being an exam situation. All of that will slow you down.
Just as an example. The core part of my CLA exam is the shared.lvlib and the template.lvlib (which I multiply into the actual modules). At my work computer I have a daily practice drill in which I now manage to get this complete within 26-27 min. Just doing the practice exam at home (unfamiliar location to program LabVIEW) meant that it took me 34 min.
If I manage to finish the mock exam in 3.5 hours that gives me at least a fighting chance to finish in 4 hours when it comes to the real exam. And if by some miracle I really have 30 min left by the end ... half an hour's worth of extra documentation hasn't killed anyone yet. I'll find a way to use the time.
Still I hope to get some feedback for my solution 🙂