Planning during CLD

[helssoa]

I recently failed my CLD exam with a lousy 45%. The paper I took was most similar to the Boiler Controller practice paper except it was unfortunately a lot more complex. Mine had an extra page of requirements and the front panel had a lot more controls/indicators. None the less it was similar in that it was very procedural (the design responded to a string of user interaction which, when followed, produced a result). I think my failure was due to lack of planning and understanding of the requirements before beginning implementation. I read the paper once and although I did not completely understand what I was trying to achieve I began coding. What is the best way of planning? I would say state transition diagram but what if the requirements are so complex with a large number of inputs/outputs like that one I was presented with? How can a state transition diagram remain readable in this situation? Ideally I want to be able to plan within 30 minutes and understand exactly what I am trying to achieve before coding. I want to be able to continue to complete the implementation by referring to my plan only (i.e. not the spec). Some examples of a plan would be good. Many Thanks.

[DavidMaidman]

I passed the CLD exam and would advise the following.

1) Read the requirements

2) Build the interface and document - this will give you documentation points plus increase you understanding of the requirements

3) Implement a simple producer consumer architecture with events documenting as you go - implement the simple stuff first (initialise GUI, stop loop) and document as you go. This will tick the boxes for style and give extra points for documentation.

4) Only now start to code main functionality. You should have a good understanding of the requirements by now and you should already be set up to implement a good style. Start at the beginning of the requirements and add one functional requirement a time testing and documenting as you go.

You do not need to finish all requirements to get a good mark - if the style is there and it is well documented then you should do well. If you don't get the style right then you will struggle with the functionality anyway.

Hope this helps

David

[RobCole]

Planning up front is a very good idea. Look at what you are to accomplish and see what structure you need to do it. My CLD exam did not need producer-consumer and was very linear in what had to happen. Build modularly. Each funciton within its own block. Add a function/requirement - test it. Then move on. Always keep a functional/running version of the program. If you run out of time, submit the last running version. This will give you a lot higher points for functionality than if the VI is broken.

I certainly agree on document as you go. I tend to document first (this section does this... this section does this... etc.). It helps with the design.

The program I had to build had user interaction to start the process and that was it. No event structure at all.

Have fun coding.

     Rob

[FraggerFox]

The best way is to first extract small set of requirements, and create SubVIs, or LV2Gs. One those are done, you just need to put them inside a state machine and make a transition to the required state depending on the requirements. I used this method, and I was easily able to clear the CLD within the alloted time with a decent score 🙂

[helssoa]

I'm pretty sure a producer consumer design pattern will not be most efficient for all problems. This design pattern is chosen when you want the design to respond quickly to user actions (sometimes this may not be possible for a state machine design pattern if a state takes a long time to execute for example in a data processing state). Most often, this is not the case and a state machine design pattern would be more fitting because it has less overhead with initializing, queuing, dequeuing etc. Also it gets tricky using producer consumer to keep all controls/indicators accessible to both loops. You end up having to use variables. Thanks for your response I think it is a good idea to build, test and document as you go.