Labview CLD Advice

[AlexA]

Hi Guys,

 

I'm due to sit the CLD this coming week and I was wondering if I could get your insight into it. Here's my current frame of mind:

 

I just jumped into the sprinkler practice exam. Sat down and drew out the various state transitions, highlighted all the important info in the brief such as timing precision, the states that controls should be in during various running states, etc. I thought for a little bit about how best to handle it and reached for what I've been comfortable with developing at my work (for kind of a large scale distributed instrument), a Queued Message Handler.

Questions:

1. By convention, what's the best way to handle sequencing in a queued message handler where you have to be able to arbitrarily exit a sequence to transition to a different state? My thoughts were enqueue at front of a queue and flush remaining elements for priority messages like state changes (into "Setup" state for example). I don't like the idea of a QMH enqueueing to itself, even though it seems like the easiest way to solve the problem. Am I being irrational, or should I break out the actual "Running" state into a Job Queue? If so, how then do you handle the case where the job sequence needs to repeat?
2. Should I be trying to shoehorn data such as the sequence array into a FGV? Or is it appropriate to maintain that data in the QMH data wire?
3. When using a User Event loop for the main message producer in a UI, which loop should be responsible for maintaining control data? Given that sometimes the consumer (message handler) will want to access data that hasn't been explicitly messaged to it in that particular message. Should I just access the control value by property node (everything I've read says no)? Or should every single control change generate an event which sends a "Data Update" message to the message handler which stores that data in it's main data wire. In other words, should the message handler maintain control data  information.
4. Should Controls themselves in a QMH type UI always be in the User Event case they trigger? Should they sit on the Block Diagram by themselves? Should they sit in Message Cases where they're needed (once again back to this question of who controls the data in a QMH UI).
   

I then tried using the LV2012 state machine project example, but it felt weird to me. There's a state which locks while it handles user events... How does that make any sense when you need to check the value of a control on every iteration? Then you have some states reading local variables of controls, while the user event state maintains the control itself... It just feels icky.

 

Finally, I caved and had a look at the example solution. I found it to be really direct. I'm not sure that it's "easily scaleable" as I currently understand the concept. For example, the logic at the end of each loop which decides which state to go into; What if there's another button that the user might want to press (another state), are you supposed to just add chains of selectors ad nauseum? I think I'm getting caught in that trap of overweighting the importance of extensibility ("I must handle everything!!!")

My final questions are:

1. Should I switch my focus to tooling specific state machines to handle these specific problems, rather than to my mind, the more extensible approach of building QMHs? 
2. If I do use enumerated state machines rather than QMHs, should I bother with User Event structures, or just monitor controls directly?
   

Really looking forward to hearing from you guys. Thanks in advance.

 

Alex

 

[Mike Le]

Hey Alex,

 

You're asking a lot of very specific questions that, to me, boil down to stylistic choices.

 

I think the question underlying the specifics is: how much should you try to program the "right in the REAL WORLD" way versus "right for the TEST" way?

 

My response would be: code in the way that lets you complete all the requirements cleanly, within the time limit. The number one problem experienced LabVIEW programmers have with the CLD is the time limit. I know a ton of super experienced folks who failed the exam because they did not adjust their individual styles to match the time limit requirements of the test.

 

If you can complete the examples with a clean application using your typical programming style, and make it as extensible as you would like to in the real world: great! Do that for the exam.

 

If you tackle the practice exams with your usual mindset and coding style, and end up running short on time... then you might need to start sacrificing the "real world" extensibility and priorities in favor of coding to what the test is asking for.

 

As you note, the example solutions are incredibly straightforward and simple. They're definitely something that an experienced coder should be able to crank out in 4 hours. They would probably also present problems in terms of long-term maintainability in the event someone wanted to make modifications or additions in the future. But they're presented as example solutions for a very important reasons: they are actual exam submissions that PASSED.

 

Do all the practice exams, ESPECIALLY the more recent examples of the Car Wash, Boiler, and ATM. The Traffic Light and Sprinkler examples are older and aren't reflective of the current 4-hour exams. Try coding them using different design patterns. TIME YOURSELF. Make sure at the 4-hour mark you've cleared the broken run arrow and left notes for any unfinished code.

 

Sorry I didn't directly answer your specific queries, but I hope this was at least a little helpful anyway.

[todd]

Another vague answer:

 

Don't over-architect it. The example solutions and the user-submitted solutions here:

http://forums.ni.com/t5/Certification/Sample-Exam-Solutions-for-Review/m-p/1824703#U1824703

vary from single-loop control polling, to UE-inside-of-case (think JKI SM), to producer-consumer.

 

Use whatever feels best.

[AlexA]

Thanks for the advice guys. I took it in and sat down and did the Carwash practise exam today. Just smashed it out in a  simple "control polling" state machine. I've attached it below in case anyone wants to have a glance at it. I've also posted it in that thread you linked Todd, so hopefully will get some feedback before this Thursday (the big day!).

Car Wash Prac Exam.zip

[todd]

Things I've heard will lose a small number of points and are easy to change:

  - Use explicit constants in each case of a structure instead of "Use Default If Unwired"

  - Make a simple text icon for the typedefs

[AlexA]

Here's round 2, with the ATM this time. Thanks for all you guy's advice so far! Once again, only the work I could get done in 4 hours. I really need to resolve this question of whether you can use LV's internal templates or not? I assumed I couldn't for this one and built the QMH from the ground up. Would have got this done a lot faster if I could have avoided that.

This one, the commenting is a lot worse. Aside from that, anyone got any structural advice?

 

I used the Queue timeout to decide when to kick the user off, rather than build a FGV timer, would I lose marks for this?

ATM Prac Exam.zip

Edited June 3, 2013 by AlexA

[drjdpowell]

I really need to resolve this question of whether you can use LV's internal templates or not? I assumed I couldn't for this one and built the QMH from the ground up. Would have got this done a lot faster if I could have avoided that.

If it’s in a standard LabVIEW install then you can use it.  I used the QMH template, if I recall.  

[AlexA]

Well, I sat it. Treadmill. With 25 mins to go I would have said I was a happy pass, then I decided to go for the last 10% of functionality. Unfortunately I had made some assumptions about timing in my accumulators and as a result the changes I made brought the app from about 90% functional to probably less than 20%.

I was happy with style and documentation, but I'm pretty depressed as I think I'm gonna fall down on functionality , and all I needed to do in retrospect was change one input. Anway, just had to vent. Also, the LV2012 project templates are badly written. All the red check mark failures in VI analyzer came directly from their dequeue/enqueue/obtain wrappers. I really hope they don't just blindly subtract marks for red checks.