I passed the CLD exam a couple weeks ago, and I'm writing about that experience. I've talked about the NI courses and the NI sample problems. Now I want to show you my test prep guide.
Before I copy it down, let me describe it. I had two goals. First, I suspected that the 4 hour limit would be tough for me, so I wanted to lay out what I should be doing and when. Second, I researched the test extensively. Aside from reading the NI-provided preparation materials, I read online articles and what people wrote about it (for example, on the NI forums or at LAVA). I wanted to efficiently summarize that information.
So, here it is. If you copy it to a two-column document, it fits on a single piece of paper.
1. Open LV if not already open.
2. Read through the problem.
3. Create a blank project and save it.
4. Ctrl-H so I can see the help box.
a. Reminds me to comment everything.
5. Create a blank VI.
a. Turn off automatic tool selection.
b. Select nothing on the front panel and change the font style to bold. This makes all subsequent creations boldface.
c. In the block diagram, open the function palette and search for something.
i. It takes time for the list to populate.
d. Click on the icon to change it.
i. It takes time to load the icon editor.
6. Read through the problem again, in detail.
a. Define the basic objects.
i. These will likely be custom controls.
ii. Start creating some base objects.
1. Reference the GUI.
b. Define what the different state conditions are.
i. The graders look for a state machine, event structure with states, etc. Looking for specific states is a good place to start.
c. Decide on the basic architecture to use. NI states that “exams are based on a sequencer-type application” and “timing is an essential aspect.”
i. State machines: obvious solution, but not suited for storing sequences or (maybe) GUI events.
ii. Queue-based events: commonly used, stores sequences, limit the processing in the event case.
iii. Producer-consumer: possible choice for some CLDs, not great for non-user interface events.
d. Timing
i. Execution: Regulates loop execution (ie – state machine) – may introduce jitter or unresponsiveness.
ii. Software: Measures elapsed time with stop/reset/pause options. Use func global, subVI, or express VI.
iii. Others: Event case timeout, synch VI timeout.
e. Create a top-level VI using a design pattern. Probably a state machine, producer-consumer, or something like that depending on the problem.
i. Take up the full screen width so you know your space – shrink it later.
f. Save it and verify it’s added to the project.
7. From the provided screen shot, design the basics of the front panel.
8. Style checklist
a. Avoid local variables.
b. Property nodes <> indicator or control values.
c. Type defs!
d. No coercions or default tunnels.
e. Make subVIs.
f. Readable code!
9. Error handling
a. Wire error terminals.
b. Wire error clusters to “no error” case.
c. Stop top level VI on error (all loops)!
d. Use simple error handler on program exit.
e. Monitor errors from parallel loops.
10. Documentation
a. Documentation for the VI & subVIs.
b. Free labels on wires.
c. Labels on block diagram items.
d. Label the actual loops (yes you can).
e. Label constants.
f. Tip strips on GUI.
g. Consistent icon scheme.
h. Be brief & to the point.
11. Test
a. Functionality
b. Weird behavior from user.
12. Final check through.
a. Close the project.
b. Reopen it.
c. Open the top level.
i. Make sure there are no errors.
ii. Verify that it runs correctly.
d. Double check documentation on every VI.
e. Make important terminals on subVIs required.
f. Run VI Analyzer if time permits.
===========================
I'll have just one more posts on this subject: the actual test day experience. That should be up in a couple of days, and then on to other topics.
No comments:
Post a Comment