Viewpoint News, December 2011

Part 3: More Action Engines for the Data Logger App

by James Campbell - jac@viewpointusa.com

Last month’s issue of this newsletter reviewed the requirements for the Data Logger application we are building in this ongoing series to show good practices for LabVIEW app development and preparation for the Certified LabVIEW Developer CLD exam.

The architecture being developed here can be used by many types of applications, not just data logging. The ultimate goal is to have a LabVIEW Project that you can download and run.

This month’s issue develops more action engines for the app and starts to discuss the architecture.

More Action Engines

The next subsections describe more of the actions engines we will use in this app.

Configuration Manager

The application configuration is saved in a file so the app can recall the configuration used by the app the last time it ran as well as update the configuration after it is changed in one of the app screens.

LabVIEW has built-in tools for managing configuration files. One is the INI-style VIs in the ‘Configuration File VIs’ under the ‘File I/O’ pattern. Another is in the ‘XML’ palette under the ‘File I/O’ palette. Specifically the ‘LabVIEW Schema’ palette under ‘XML’ is easy to use, since it converts clusters to an XML string and the reverse. The ‘XML Parser’ palette is more general purpose but requires good understanding of the DOM objects and xpath syntax. The pros and cons of the ‘LabVIEW Schema’ VIs are that they are easy to use, but a cluster in the app must match exactly the contents in a config file, which can make difficult handling different versions of the configuration file. The pros and cons of the ‘XML Parser’ VIs are that they are flexible (e.g., they avoid the issue of exact matching between clusters and file contents since you are in control of parsing element by element), but that flexibility requires more programming and additional care in managing DOM references (e.g., closing all references properly).

For the CLD exam, the ‘LabVIEW Scheme’ VIs are fine and they will be used for this app too.

Reviewing the requirements (see November enewsletter), this app needs some arrays of channel information with arbitrary length depending on the number of channels that might be used in the application. In addition, there are some “scalar” items, such as the data logging filename, and the heartbeat time interval in seconds. Here’s an image of a possible cluster:

Channel Calibration

Measurements are often made in basic units of volts that are converted into the physical units of the measurement, such as distance, pressure, and electric field strength. For this app, a linear equation converts the measured units into the physical units. More complex conversions, such as the polynomials used for thermocouples, will be left for another day.

Source code for the Example AEs

Since several Action Engines have been developed so far, a ZIP file for the entire LabVIEW project can be found at http://www.viewpointusa.com/newsletter/2011_Dec/Data_Logger_App_Project_Folder_LV9.zip. This project contains some test code to help verify proper functioning of the AE Manager VIs. These VIs need LabVIEW 2009 or above.

Beginning the Architecture

App Responsiveness

Since this app has requirements that the user interface be responsive during the execution of the data acquisition and allow the acquisition to maintain periodic sampling at the heartbeat, we will need to use either a state machine that moves through each state quickly or use a producer-consumer pattern with an event structure in the producer loop.

Data Acquisition Approach

The data acquisition could be approached in several ways. Here are a few to consider. This list is not comprehensive.

• Make acquisition one of the states if we choose the state machine approach.
• Use the timeout event on the event structure at the heartbeat interval and put the acquisition code in this frame.
• Use one or more parallel loops outside the producer-consumer framework and pass data to the producer-consumer framework via queues or Action Engines.
• Make the consumer loop into a queued state machine that makes transitions through an acquisition state rapidly so as not to hold off any other pending events detected in the producer loop. Likewise any producer loop events can’t hold off the acquisition.

At the moment, the third bullet seems to make the most sense. There will be more to follow on this topic next month.

Summary

The Data Logger app development continues with additional Action Engines needed to meet the requirements listed in the November issue (see November enewsletter ). This Data Logger app is a good example for the types of “applications” typically seen in past CLD exams. Next month, the app development will continue with laying out the architecture.