questions about CLD

[phyyu]

Hello guys,

I am preparing CLD exam, I have questions here, hoping get some answers.

1. Should I have to use the project? The template of example exam only have a main VI and subVIs folder and controls folder, the requirement don't mention the project, but some threads here mentioned the project is a mandatory structure? Confused..

2. All the example exams using state machine, which is simple and useful. Is it good enough for state machine to solve all the CLD level questions? Is it possible to solve a queued problems with a standard state machine structure?

3. As to the documentation, what size is appropriate? Should I mention all the details in it or just a couple lines to describe?

I attached my practice of sprinkler controller, please help me to check the documentation is enough or not. (And style as well)

Many thanks!!

[crossrulz]

1.  You should use the project, if nothing else but for you own sanity.  Some of those sample exams are from a very long time ago before the project came out.

2.  I found a simple state machine will solve 99% of the CLD exams out there.  But as always, use what makes the most sense.  If a QSM is the better way to go, use the QSM.

3.  VI Description is mandatory (just a couple sentences describing what the VI does).  Tip strips for the front panel controls are mandatory.  Otherwise, just give quick descriptions of what the algorithms are doing.

[Demo_and_Equipment]

Hi,

Projects are not required for the CLD, but they are for the CLA.

Per our preparation materials, keep the documentation short and to the point.

Agreed with  above.

[phyyu]

Is it means that doesn't matter I use the project or not? Is it possible some credit for using it?

[Rodéric]

It is  better to use the project IMHO. Even if you don't get points for that...

The CLD is designed in a way that a QSM will be a good option, you also should consider Even Driven Producer Consumer, or JKI state machine, or any other design. As far as architecture is concerned for the CLD use the KISS principle (Keep It Simple Stupid), just use the design you use for every project (if it's a good one^^)

As for documentation just make sure that every VI is documented (at least 1 comment) on his block diagram AND VI properties=>Documentation. Don't spend too much time on documentation for the CLD (much more for the CLA)

[JÞB]

Save some time at the end to run VI Analiser and correct any high priority hits.  As a matter of fact start using VI Analizer often on your own code so you become familliar with what troubles it will report - and avoid those style issues during the exam- they will cost you points. 

[phyyu]

Thank you for reply!

I learned to used the VI analyzer, which is really helpful to find out the spell problem, wire bend, object overlapping, tunning problems... And my back diagrams are always too large, i hope it is not a big problem (I try to keep the extension only in one demension,such as some extension to the right)

[phyyu]

Thanks for reply.

I hope my real exam can be solved using simple state machine...I also prepared with the event producer/consumer, QSM anyway, wish that is enough.

[JÞB]

---

@phyyu wrote:

Thanks for reply.

I hope my real exam can be solved using simple state machine...I also prepared with the event producer/consumer, QSM anyway, wish that is enough.

---

As long as you've mastered at least one design pattern you will likely be able to meet the test software requirements.  Mastering more than one design pattern will put you well ahead of the average "first time CLD examinee".  You might still fail but you have the tools to pass

[crossrulz]

---

@phyyu wrote:

Thanks for reply.

I hope my real exam can be solved using simple state machine...I also prepared with the event producer/consumer, QSM anyway, wish that is enough.

---

Let me just say that 99.9% of the CLD-like situations I run into in the real world are easily solved with state machine or producer/consumer.  If you are good with those two, I don't see you having any problems assuming you can code fast enough.