Viewpoint News, October 2011

Part 1: CLD-based LabVIEW Application Design Considerations

by James Campbell - jac@viewpointusa.com

Last month kicked off a series covering preparation for becoming a Certified LabVIEW Associate Developer (CLAD) and Certified LabVIEW Developer (CLD), with emphasis on the CLD.

The idea for this series came about since Viewpoint presents these topics at various LabVIEW User Group Meetings (LV UGMs). NI creates the CLD exams to demonstrate competency in application development using best practices, so knowing these practices (fluently!) is important in passing those exams.

Even if you don’t want to take the CLD exam, these best practices are good to know even for everyday use. We will build an app as we go and files will be available for download.

The test is not easy. Do not be cavalier. This series can help.

Observation from Past CLD Exams

We have learned that the CLD exams have some common traits. These anecdotes come from the many exams our own certified engineers at Viewpoint have taken as well as stories from other CLDs at the LV UGMs.

Here are the common traits of CLD applications, in no particular order:

• Time is tight (know your stuff and manage the clock)
• Requires design flexibility to allow for “more of same” without rework (modular design)
• Need to know elapsed time (timer functionality)
• Must respond quickly to user input on the front panel (no blocking)
• Manage application configuration via a file (INI-type file)
• Requires moving from one condition to the next (state machine)

What are the impacts of these traits on your implementation?

Tight Timeline

The CLD exams may be straightforward, but they are not easy. The one constant theme I hear often is the lack of time to complete the app. Practice, practice, and practice. Divide up your time into sections (15 minutes to read the specification, 20 minutes to design, and so on), and stick to it during the test. And, know extremely well the tools and methods being discussed in this series.

Design Flexibility

This requirement is very architectural in scope and covers good programming practices such as Action Engines (NI calls them Functional Globals), state machines, producer/consumer loops, queued message handling, and so on. These items will be discussed in more detail in future issues.

Timer

The CLD requirements might require that the app do something for a specified amount of time. For example, the app might need to stay in a certain condition (washing the car underside) for a period of time (5 seconds). Or, the app might want to monitor a (simulated) sensor at some period (read the water pressure twice a second).

So, knowing the timer functions in LabVIEW is important. For example, the ‘Elapsed Time Express VI’ does not block code execution whereas the ‘Wait (ms) Function’ does. Click here for an Action Engine timer and test case VI example.

These VIs need LabVIEW 2009 or above.

Responsiveness

Responding to the user inputs in a timely fashion is always good programming practice since otherwise the user thinks the app has hung or crashed, gets frustrated, and starts pushing all the buttons, putting the app in a very weird place when (if?) it comes “alive” again.

For the CLD exams, there are two typical ways to assure responsiveness. One uses event structures inside a produce/consumer design pattern. Another creates a state machine that frequently (say every 100 ms) polls the front panel controls for changed states (i.e., the user pressed a button or changed a number). Depending on the app requirements, the latter approach could work nicely, but the former is more flexible since it can encompass a state machine or queued message handler as well.

Configuration File

At least some CLD exams require the ability to configure the app to run in a certain way upon startup and the ability to edit and save this configuration for some future execution.

For the CLD exams, there are two typical ways to handle configuration files. One method uses the INI-style VIs on the ‘Configuration File VIs’ palette. The other method uses the XML VIs under the ‘XML>>LabVIEW Schema’ palette. Both are under the ‘File I/O’ palette.

State Machine

At least some CLD exams require the app to run from one task to the next. The state machine design pattern is an excellent choice for such a requirement. For example, the car wash practice CLD exam moves the car through the various positions in the wash cycle, each one pausing for a specified amount of time. Another CLD example implements a soda machine, which must recognize that money is being entered, release the soda bottle when the required amount is available, and eject any change due. In fact, the state machine for this soda dispensing example is described at http://zone.ni.com/devzone/cda/tut/p/id/3024.

Summary

The stage is set for starting an example application using the traits discussed above. Next month, the requirements for the app will be presented and the application architecture will be chosen.