CLD Exam Feedback

[jgcode]

[cross-posted to LAVA]

Howdy

If anyone has any spare time to review these attached CLD submissions I would be very grateful.

I am looking for specific feedback on coding to NI exam requirements. 

I sat all exams under strict conditions.

The disk hierarchy layout, architectures and coding style is based on the examples/content in the Intermediate I course (now named Core 3).

In terms of the implementation, I choose to use Multi-Functional VIs over LVOOP, due to time constraints.

IMHO I find myself taking a bit longer to code using LVOOP.

Also, as these examples are small apps (<4hrs) and the lifecycle of the code is essentially zero, I don't think I would have gotten any huge benefits.

I decided time was the most important factor. 

However, the globalness of the MFVI is not used (except for the Error Module) as all the other module calls happen in a single loop, so a simple LVOOP implementation for the purposes of encapsulation and scope would be easy - there would be no statefullness issues in these examples. I would have made the Error module a Singleton using a DVR in a private FGV method.

This raises a question: How best to document a Class (or other Library) to NI exam requirements?

As there is normally a lot more subVIs (e.g 8 methods = 8xFP, 8xBD, 8xVI Properties) for a Class versus a MFVI (1xFP, 8xBD (Cases), 1x VI Properties) and there is also Class Documentation (under Class >> Properties) as well.

This means a lot more time on documentation. 

What does NI expect? 

Cheers

-JG 

Message Edited by jg-code on 06-07-2010 03:35 AM

[ricky chauvin]

I'm afraid I have no useful feedback.

I just want to say thanks for uploading this, Im actually impressed that it makes perfect sense.  I've obviously learnt alot more than I realised!

[Daklu]

---

jg-code wrote:

IMHO I find myself taking a bit longer to code using LVOOP.

Also, as these examples are small apps (<4hrs) and the lifecycle of the code is essentially zero, I don't think I would have gotten any huge benefits.

I decided time was the most important factor. 

---

I'm sitting for the CLD this Friday and I made the same decision.  OOP/MVC feels more natural to me than traditional LV patterns that follow a structured programming approach, but given time constraints and without the ability to use my active object template and reuse modules it's just too much to try and fit into 4 hours.  I've actually found it somewhat difficult to shift from thinking in terms of objects and modules to thinking in terms of data and procedures.

---

jg-code wrote:

This raises a question: How best to document a Class (or other Library) to NI exam requirements?

As there is normally a lot more subVIs (e.g 8 methods = 8xFP, 8xBD, 8xVI Properties) for a Class versus a MFVI (1xFP, 8xBD (Cases), 1x VI Properties) and there is also Class Documentation (under Class >> Properties) as well.

---

Can't say what they expect, but I did notice that on their sample solutions they didn't document the FPs of the sub vis.  Controls and indicators don't include a tip strip and description.  For sub vis I'm planning on giving the vi a description, document the BD as necessary, and if I have time go back and do the FPs.  My main FP will include tips and descriptions for each control.  I'll also include a description in any classes or libraries I use.

One of the requirements that isn't quite clear to me is,

    "Be easily scalable to add more states / features without having to manually update the hierarchy." 

So our app needs to be scalable without making any changes to sub-vis?  That seems pretty restrictive--in my Car Wash solution I used a state manager sub vi to monitor the timing and control the state transitions.  Obviously any new states are going to require changing the state manager sub vi.  Am I violating that requirement?

Message Edited by Daklu on 06-07-2010 10:35 AM

[tbob]

The statement about scalability is to encourage you to use state machines, enums, and other things that make it easier to add on.  Of course some vi's will need changing, but keeping that to a minimum will score points.  For example, using an enum for case choices or states is scalable because you can add a new item and with just one button  the enum will be updated in every subvi that uses it.

If you have to change your state manager, that is just one vi.  Better than having to change a whole slew of subvi's.

[GregFreeman]

---

tbob wrote:

For example, using an enum for case choices or states is scalable because you can add a new item and with just one button  the enum will be updated in every subvi that uses it.

---

just to clarify, Type-def enum ;). Won't update everywhere if you dont do that and you will see coercision dots like no tomorrow.

Message Edited by for(imstuck) on 06-07-2010 03:13 PM

Message Edited by for(imstuck) on 06-07-2010 03:14 PM

[jgcode]

Hey Daklu

Goodluck with the exam, let us know how you go!

I am with you - I feel like I have to program a little differently to get the certifications, then what I do in normal life e.g. I prefer to spend more time on design, use LVOOP, write test VIs, make use of templates (e.g. JKI State Machine), use reuse libraries (OpenG, my own) etc...

I believe all the above can lead to a more robust solution.

But from these examples I have done, I guess I am impressed that I can create a nice solution quite quickly using these more traditional techniques...  (Enum/Variant Producer Consumer - Events, MFVIs, FGVs etc...).

This gets me thinking about whether they are suitable in certain conditions?

Although I have to admit I have shied away from using them altogether lately. 

[Daklu]

---

Goodluck with the exam, let us know how you go!

---

When I worked through the sample exams I finished coding the Car Wash in ~2:45 and the other two took about 2 hours each, so I wasn't overly concerned about the time.  Heh... Having now seen a real CLD problem, I don't think the practice exams are fair representations of the real thing.  The practice exam requirements are far simpler than the problem I was given.

I spent the first 20 minutes reading through the requirements and making notes.  I would have liked to have spent more time doing that and sketching out a design, but it was about then that I realized time *was* going to be an issue.  At 3 hours into the exam I ran the vi for the first time and started fixing bugs.  By 3:30 I had the core functionality and some of the extended functionality working.  I started making some changes to meet the remaining functional requirements, but ~5 minutes into that process I realized the changes were going to be fairly significant and I would likely have a broken app when time expired, so I reverted and worked on cleaning things up and documentation instead.  I still ran out of time before I could document what I would do if I had more time.

It may be that NI intentionally gives more work than can be done in four hours.  The requirements are complex enough that it wasn't easy to understand the application details by simply reading the document and there isn't enough time to do a detailed design.  Software development in general is an iterative process, yet four hours isn't enough time to do any useful iterating on the exam.  So with no time to do detailed design and no time to iterate, it felt a bit like using a lottery to choose a spouse--you move forward and hope it works out.

Did I pass?  No idea... had I been able to get all the functionality working I would feel a lot more confident.  From what I've read the grading can be pretty subjective.  It may come down to how grumpy the grader is feeling that day.

---

I believe all the above can lead to a more robust solution.

---

I agree--more robust and more scalable.  I write test tools for internal customers, and since they don't pay me directly they *always* have (unspoken) grand ideas about what they want the tool to do next.  Flexibility beyond what the customer is specifically asking for right now is deeply engrained in the way I work.  Switching over to the assumption that the requirements document will be the same tomorrow as it is today is a pretty big leap for me.

---

This gets me thinking about whether they are suitable in certain conditions?

---

Yeah, I think there are conditions where they are suitable.  You've heard the saying, "Fast, cheap, good. Pick two?"  The software development correlary could be, "Fast, robust, flexible. Pick two."  If you take flexibility off the table the more traditional techniques are good solutions.

[jgcode]

---

When I worked through the sample exams I finished coding the Car Wash in ~2:45 and the other two took about 2 hours each, so I wasn't overly concerned about the time.  Heh... Having now seen a real CLD problem, I don't think the practice exams are fair representations of the real thing.  The practice exam requirements are far simpler than the problem I was given.

I spent the first 20 minutes reading through the requirements and making notes.  I would have liked to have spent more time doing that and sketching out a design, but it was about then that I realized time *was* going to be an issue.  At 3 hours into the exam I ran the vi for the first time and started fixing bugs.  By 3:30 I had the core functionality and some of the extended functionality working.  I started making some changes to meet the remaining functional requirements, but ~5 minutes into that process I realized the changes were going to be fairly significant and I would likely have a broken app when time expired, so I reverted and worked on cleaning things up and documentation instead.  I still ran out of time before I could document what I would do if I had more time.

It may be that NI intentionally gives more work than can be done in four hours.  The requirements are complex enough that it wasn't easy to understand the application details by simply reading the document and there isn't enough time to do a detailed design.  Software development in general is an iterative process, yet four hours isn't enough time to do any useful iterating on the exam.  So with no time to do detailed design and no time to iterate, it felt a bit like using a lottery to choose a spouse--you move forward and hope it works out.

Did I pass?  No idea... had I been able to get all the functionality working I would feel a lot more confident.  From what I've read the grading can be pretty subjective.  It may come down to how grumpy the grader is feeling that day.

---

Cheers for posting your feedback. I was in the same boat as you. My spec had a whole lot of mostly non-related functions. So I developed the GUI, built the architecture then began to implement each functionality. Hoping that most functions would work and any I did not have time to complete would not effect the functionality of others. I also did little to no documentation. I passed, but IMO it was not elegant solution (although I likely thought it was at the time). That approach was flawed (from inexperience really). 

I just re-sat it for fun the other day (as per cross post). This time I built the GUI (to get a feel for the app), designed the modules, coded,tested and documented the modules (I did this as LVOOP). I then built the architecture, integrated the functionality. I had only about 20 mins to go and it was all working. I finished up documenting the GUI and the Main VI. With only a ~5 mins left I had not implemented the "Stop on error" requirement but created a Class and method VIs, created the interface and documented the BD saying what it was to be designed as a Singleton and what its function was and integrated that into the code.

But this was much more intense then the exams, I tracked my time on the all exams, but I really was cruz'in in the samples, in the re-sit I felt the pressure of worrying about not having enough time to finish!  

But IMO this approach was definitely more solid. I did miss a few small things in the design that I had to account for in the code, but I wrote an explanation as to what I'd done and why (stating time as a reason) and said it could be refactored in the future. I would be confident that if I could not have finished integrating all functions, the coding would have still been done in the modules and maybe demoed in some test VIs to get some points.  

---

Yeah, I think there are conditions where they are suitable.  You've heard the saying, "Fast, cheap, good. Pick two?"  The software development correlary could be, "Fast, robust, flexible. Pick two."  If you take flexibility off the table the more traditional techniques are good solutions.

---

The only problem I have found is that always can bite you in the butt, either now, a month or years down the track when an upgrade is required. If you try to accommodate a client's smaller budget with inflexible code, they get pretty angry when you tell them you need a pretty much a rewrite to do this/that later on - although they were the ones that agreed to it in the first place.

On the flipside, designing the project so that it is very flexible takes time. Time that they don't want to pay for: "I pay you to code, what is this design stuff?" Adding business to software really throws a spanner in the works! 🙂  All part of the fun of working in the industry I guess?

[Ian_Ren]

What is "Minimize the use of excessive structures, variables (locals / globals) and Property Nodes". Using a property node would make "Respond to front panel controls (within 100 ms)" really easy. Will you lost points if you use "Property Node".

Set CLD Exam aside, is using property node such a bad practice in LabVIEW coding?

[tbob]

It said "minimize" not avoid.  Property nodes are slow.  But if you have to set an LED to blink, you have to use a property node. Just don't use them randomly.  Don't use them where a simple wire would work.  For setting a control's value, use a local variable instead of a property node since it is much faster.  You won't lose points for proper use of property nodes, but you will for unnecessary use of property nodes.

Aside from CLD, property nodes are generally frowned upon when used to set a value (Value or Value(sgnl) property node).  The other uses, like setting blinking or disabling and such are perfectly acceptable.