Control Engineering

Link This | Email this | Blog This | Comments (0)

Can I use LabView to program a control system?
April 23, 2007

The answer is yes. To make the system work, requisite hardware is, of course required. LabView has all the bells and whistles needed to implement any control system, and is a good alternative to more traditional methods for creating control application software. I’ve done it more than once, and an army of developers have had excellent success writing LabView programs for large and small control systems, real time, embedded, Internet enabled, motion control, simulations, and so forth until the cows come home. In fact, I know of no application where LabView couldn’t be used. You do need to match the hardware to control bells and whistles you plan to use.

That said, remember that the software was originally designed for data acquisition (DAQ) in an industrial research environment. DAQ, per se, does not require control. Pure data acquisition only requires periodic capture of real-world signal levels, conversion of that information to digital format, and storage on in suitable computer-readable form. Today, however, the number of applications for data acquisition and control (often called “mechatronics”) are far more common than straight DAQ. LabView, from its inception, has had the control capabilities needed for mechatronics as well.

LabView is a product of data acquisition (DAQ) hardware and software vendor National Instruments. In my posting of March 2, 2007, I showed how to use DAQ hardware and software to measure voltage and current. The “USB DAQ device” featured in that posting is an analog input module. It provides only the ability to collect analog signals from the equipment under test. There are three other types of DAQ modules: digital I/O, analog output, and multifunction.

The figure below shows a LabView virtual instrument (VI) I wrote to control a rotary table in a wind-tunnel experiment. The apparatus consisted of a motor driving a shaft through a friction clutch. The experimental model mounted on the shaft, which also drove the wiper of a potentiometer. The ratio of the wiper voltage divided by the excitation voltage across the potentiometer multiplied by 100 gave an output “code” reflecting the model’s orientation to better than a tenth of a degree.

The first thing to notice about the LabView VI is that it’s not text programming. LabView is a graphical programming language. A program consists of objects (the VIs) that perform actions and are interconnected to form the system, just as objects representing electronic components are interconnected to form a schematic diagram for an electronic circuit. In fact, many component symbols are straight out of electronic circuit diagrams. For example, the D-shaped symbols represent Boolean “and” functions. Right-pointing triangles represent mathematical functions, such as subtraction or comparison (“less than” and “greater than”). Square blocks represent more complex actions. The three yellow squares, in fact, are highly complex sub-VIs that I wrote to perform specific operations, such as converting an angle to a code, or a code to an angle. The yellow square marked “E” acquires signals from the angle encoder (potentiometer) and does the division to get the code representing the potentiometer position.

The rectangle marked “Target Code” reads a register containing the code representing the orientation we want the model to reach. The “Current Code” is a register containing the code read from the encoder. If you look carefully, you will see that what looks like a frame around the VI is actually a fat arrow looping around in a counterclockwise direction. This actually does represent a loop that executes the entire VI for each turn (iteration).

Adding control capabilities requires a multifunction DAQ module, which includes analog and/or digital output channels as well as analog inputs.

Multifunction modules provide analog I/O and digital I/O features. The DAQ module I have on hand combines analog input with digital I/O ports, which are enough to cover most control applications. The next step up—adding analog output—is very expensive to cover relatively few control applications.

During each iteration, the VI compares the current code to the target code. If the former is smaller than the latter, the VI sends a signal to a sub-VI (the blue square marked “M”) to drive the motor “up.” If the current code is larger than the target, the VI sends a “down” signal. If they are equal, neither signal goes out, and the motor stops. The VI, of course, also performs a few other chores, such as making sure it doesn’t try to drive the motor beyond the setup’s limits, and creating some displays on the system’s front panel.

The beauty of graphical programming is its intuitive look and feel. If you’re comfortable with electronic circuit diagrams, you can learn to program with LabView. The important things to remember are that LabView is a graphical programming environment in which you create application software (the VI). You then have to compile that software for the particular hardware on which it will run.

While LabView can be used for just about any application, there are some where it might not be the best choice. For example, I prefer Matlab for writing simulation software that requires heavy use of vectors and tensors, and C++ for general-purpose programming. When analyzing data files, nothing beats good ol’ Microsoft Excel. In fact, I often use LabView to build data files in Excel format for later analysis.

Here is an example of a LabView VI I created some years ago to control a model in a wind-tunnel experiment. Source: Masi Aviation, LLC.

Posted by Charlie Masi on April 23, 2007 | Comments (0)