Certification

cancel
Showing results for 
Search instead for 
Did you mean: 

CLD ATM Problem: How Did I Do?

Hello all,

I hope this is kosher to post.  I've just finished my first CLD practice exam, the ATM problem.  I've attached my solution.  Cany any of you provide feedback as to how this would stack up on the actual CLD?  Would it pass? 

For one note, it uses a queued state machine (QSM) architecture.  I became very comfortable with this at my previous job, but it's not one of the standard NI architectures, though it's very similar.  It allows you to couple states and variant state data.  Would something like this throw off the grader automatically?

My other concern is my use of local variables. Am I following standard practices?

All feedback welcome. Thanks!

0 Kudos
Message 1 of 12
(6,013 Views)

Matt,

 

I didn't check the functionality very closely but it seemed to work so you would probably score well in that regard.  Queued Message Handlers are awesome and if you feel comfortable with that then use it.  I would only start to question the architecture choice if you started to get into OOP (it's always overkill for CLD).  The one thing you missed in terms of functionality is some simple error handler at the end of your program (I forgot this on my CLD as well).

 

For documentation, remember tip strips for all front panel objects.  You should also add documentation for your top level VI and change the icon.  Your comments are pretty sparse, I use and recommend subdiagram labels (right-click structures > visible > subdiagram labels), putting even a simple comment on each case of each structure adds a lot to the readability.

 

For style I would recommend using short names for property and invoke nodes instead of no names, I am not sure if you would actually lose points for this but it makes it much harder to read in my opinion.  Whenever you see yourself needing to use stacked sequence structures you might want to look into using Sub-VIs instead.  The biggest change, I think, would be to use shift registers to keep track of all your controls and eliminating most need for local variables.  If you look at the example solutions they will give a general idea of how to do this.

 

Overall I think this is a really good first attempt at the CLD.  Looking forward, make sure you comment as you go and use shift registers instead of local variables.

Matt J | National Instruments | CLA
0 Kudos
Message 2 of 12
(5,975 Views)

@Jacobson-ni wrote:
Whenever you see yourself needing to use stacked sequence structures you might want to look into using Sub-VIs instead. 

If you're using stacked sequence structures, or even flat sequence structures, on the CLD, you're doing it wrong.

Message 3 of 12
(5,954 Views)

@natasftw wrote:

If you're using stacked sequence structures, or even flat sequence structures, on the CLD, you're doing it wrong.


Really good point.  When taking the CLD it is probably best to just never use either.  

 

After viewing enough people's code (and having my LabVIEW crash from converting a stacked to flat sequence structure because it was too big) I tend to look over improper use of these structures.  But you get your CLD to prove that you can write understandable and maintainable code, in which sequence structures are not needed as often as they are used.

Matt J | National Instruments | CLA
0 Kudos
Message 4 of 12
(5,949 Views)

Documentation: estimate: 2-3/10

- none of the front panel controls have a description and a tip strip

- reinit all invoke needs name displayed. Edit: all invoke nodes lack a descriptive name

- type defed constants have default icons

- every structure needs a comment (every event/case structure case, every loop etc)

- subVI icons not standardised (functional Header + descriptive bottom bit)

- no comment on subVI block diagram

- default icon of main vi

- front panel controls have not been turned into type defs

- no description in main vi documentation

 

Style: estimate 5-6/15

- Changed default value of type defed constants

- queue not named

- excessive use of local variables: use shift registers

- partially covered items (e.g. current account local in step 0 of the stacked sequence structure of the withdrawal complete case)

- wires behind structures

- backwards wires

- use of stacked sequence structure

- hardly any error handling at all: loads of unwired error terminals and nothing is ever done with the errors

- no error handling

- default values out of structures (event/case structures)

- no standard error in/out functionality in subVIs

- unclean program exit using stop vi

- Edit 2: avoid using any sequence structures. There is a time and a place for it but if done properly the CLD ain't one of it

 

functionality: estimate 15/15

- haven't tested it

 

I'm afraid you need to heavily work on your documentation and style. Even with full scores in functionality you would not have come close a passing mark.

 

 

 

 

Message 5 of 12
(5,938 Views)

Thank you all for the constructive criticism.  This is exactly what I needed.  I didn't spend too much time on the documentation (obviously), but I wanted to see how this half-assed job stood up.  From your remarks, not too well.

 

So, what's the beef with the stacked sequence?  I've always thought they were a great way to deal with serial, independent processes.

0 Kudos
Message 6 of 12
(5,923 Views)

mattmunee wrote:

So, what's the beef with the stacked sequence?  I've always thought they were a great way to deal with serial, independent processes.


Use a state machine instead.  It is a lot more flexible and easier to edit.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 7 of 12
(5,917 Views)

LabVIEW being a data flow language should technically not need sequence structures. It is generally considered bad style using them as it is much better using error wires to sequence your code. In particular stacked sequence structures are frowned upon as they allow to pass data to subsequent states making it overall extremly hard to read and generally hard to maintain. And there have been calls in the past to remove them alltogether.

 

If you are using LabVIEW professionally maintainability is key. Consider a complex application that is badly written and that needs changing after you left the company. This will lead to a very disgruntled customer who might need to scrap the application completely and start from scratch ... don't come back to ask for a job reference in this case!

 

Abiding by the style guidelines and documenting properly means that another developer shouldn't take too long to understand what your thought process was and also minimises the risk of introducing notoriously difficult to track bugs like race conditions (e.g. use of local variables etc.). If you want to check how maintainable your code is you can easily check this with a small-to-mid sized application. Give it to one of your peers. Let them look through it for 20 min and then let THEM talk you through your code. If their face is blank you know you've got work to do.

 

I generally try my hardest to achieve in-software-synchronisation without the use of any sequence structures. E.g. through the use of queued states (if you have four operations that need to happen in succession you could use split these operations into four cases and simply enqueue all four states at once: sequentialisation successful).

 

As I said there is a use for (flat!!!) sequence structures. I occasionally use them in FPGA programming.

 

Edit: Considering that "only" 37.5% of the score come from functionality the CLD is an exam all about documentation and style. It proves that you can write your code well, and that if it is not working that someone else can pick it up and finish the job. That's different in the embedded developer exam for example ... there it is 50% functionality. Documentation and style only account 20% there (The remaining 30% are for architecture).

0 Kudos
Message 8 of 12
(5,915 Views)

Mathis_B wrote:

Edit: Considering that "only" 37.5% of the score come from functionality the CLD is an exam all about documentation and style.


And let me add that there is no excuse for not getting all of the documentation points.  You can get them all in 10 minutes (if you are slow about it).

 

Two of my buddies have passed the CLD with only about 1/2 of the functionality done.  So that should tell you where the priorities are.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 9 of 12
(5,906 Views)

I'm joining that club. Everything was implemented but nothing worked properly. Evaluation sheet was an entertaining read: Module X does not work as specified, Module Y does not work as specified, ... (all in all 6 -7 modules).

 

I've even heard that people deliberately left out functionality as the architecture they chose did not make it easy to implement those bits and would have messed up their style.

0 Kudos
Message 10 of 12
(5,902 Views)