CLA Self Test

I recently passed the CLA exam while I was at NI Week '08. Preparing for the CLA exam is difficult because there are no sample tests available on the NI website. From looking at the test requirements and at the Advanced I materials, it became obvious to me that in order to pass the CLA exam I would have to be able to code a parallel-loop architecture. So I came up with the following self-test to help me prepare for the exam. It helped me quite a bit and so I am posting it here as an aid for others seeking the CLA certification.

But first, a disclaimer or two. First, this is a test that I came up with before I took the CLA exam and so it should not be a violation of the NI non-disclosure agreement to post it. Second, successfully completing this exercise does not mean you are ready to take the CLA. It just means that you are on your way. Failure to complete this exercise is a good sign that you are not ready to take the CLA. Study the architectures described in the Advanced I material and try again later!

Now on to the test. Create a front panel with a single numeric indicator and four boolean buttons. The buttons should be labeled "Count", "P Error", "C Error" and "Stop". The back panel should consist of a producer-consumer architecture with an event structure in the producer and a state machine in the consumer. One case of the producer event structure should generate a user-defined error with the error message "Producer Error" (use the Error Cluster from Error Code vi). One case of the consumer state machine should generate a user-defined error with the error message "Consumer Error". The error wires of the producer and consumer loops should be merged using the Merge Errors vi before they reach an error handler. The vi should have the following behavior:

• When the the vi starts the indicator should show zero and all buttons should be popped up
• When the "Count" button is pressed the indicator should increment by one.
• When the "Stop" button is pressed the vi should shutdown gracefully without error.
  
• When the "P Error" button is pressed the producer error should be triggered. The vi should shut down gracefully and display the "Producer Error" message.
• When the "C Error" button is pressed the consumer error should be triggered. The vi should shut down gracefully and display the "Consumer Error" message.

One note about the P Error and C Error buttons. The only thing that those buttons should do is introduce an error into your vi, one in the producer and the other in the consumer. The point of the exercise is to see how your architecture responds to those errors, and to see if the correct error gets reported. The vi should shut both loops down gracefully if an error happens in either loop. So it is cheating if you introduce code that shuts down the loops in the same cases where you generate the errors. In real life you don't know where the errors will strike. In this exercise you do know, but it is your job to pretend that you don't.

Another note about shutting down "gracefully". By that I mean that if an error occurs your vi should go through the same shutdown procedure that it would if the Stop button had been pressed.

And that's it. If the "Count" and "Stop" buttons operate as expected your basic architecture is sound. If the "P Error" and "C Error" buttons work then your error reporting and shutdown strategy is robust.

Here's an extra-credit exercise. The error chains from the producer and consumer get merged as they exit the loops. Swap the terminals that they attach to on the Merge Errors vi. For instance, if the producer error chain goes to "error in 1" and the consumer goes to "error in 2", switch it so the producer goes to "error in 2" and the consumer goes to "error in 1". Re-test your vi. Does it still behave the way you expect?

Even more extra credit. Did you fill out the tip strips on all front panel objects? Fill in the VI Documentation under VI Properties? Create a custom icon? Label significant wires? Put comments in each case of each case structure? Did you create the vi in a LabVIEW Project? The key advice here is to not forget everything you had to learn for the CLD exam. Style and documentation are still graded in the CLA exam, even if they aren't weighted as heavily as they are in the CLD exam.