Faced with a data acquisition or control task that absolutely must occur within milliseconds, would you entrust it to Windows? Because few people would dare answer yes, National Instruments (NI) developed LabVIEW RT, a version of the graphical language that runs time-critical applications deterministically on a dedicated CPU card.
Isn’t Windows Good Enough?
Not everyone needs LabVIEW RT. For many PC-based data acquisition tasks, whether a system delays the next sample by tens or hundreds of milliseconds makes little difference. This relaxed requirement on speed holds true especially for jobs that measure process variables such as temperature.
Meanwhile, engineers familiar with the time and cost savings that arise from programming and running data acquisition applications on PCs are pushing into more demanding areas. In doing so, they run into the shortcomings of Windows.
Consider one engineer’s experience related by Jim Balent, product manager for LabVIEW RT. Control loops of 10-ms were needed. The engineer ran Windows NT on a dual-Pentium machine and, by disabling everything possible and keeping LabVIEW to one process, achieved loop times of 8 ms-but not consistently. Every 5 min or so, the loop time inexplicably jumped to more than 30 ms. The cause never was determined, but perhaps it was due to low-level kernel tasks or NT housekeeping.
In more technical terms, the Windows response time isn’t guaranteed; it isn’t deterministic. This weakness is well known, but the alternatives aren’t cheap. Developing custom hardware and software involves considerable engineering resources.
To reduce the engineering load, you can purchase board computers and commercial real-time software, but total system cost can easily reach tens of thousands of dollars. And even when working with a commercial real-time operating system, programmers must learn a new, arcane command set.
These alternatives obviously require specialists. Now, thanks to LabVIEW RT, generalists from any discipline can program in a familiar environment yet gain the benefits of real-time performance.
Review the Basics
First, consider the hardware required for a LabVIEW RT system. User programs execute on a CPU card that holds a data acquisition module for real-world I/O. The CPU comes either on a PCI card for use in conventional chassis or as a two-slot PXI assembly for use in NI’s PXI racks or a CompactPCI crate.
Among the card’s key components are a 133-MHz AMD 486 DX5 processor along with 8 MB of DRAM plus shared SRAM for communications between the host system and the CPU card. Three I/O daughter cards are available, each a port from NI’s E Series designs. The first features 16 SE/8 DI inputs at 12-bit resolution and single-channel digitization to 500 kS/s along with two analog outputs and eight digital I/Os. A second configuration increases resolution to 16 bits but drops speed to 100 kS/s. The third is dedicated to high-speed digital I/O with 32 points.
Creating a real-time application is barely different from writing LabVIEW programs, but differences do crop up, especially at run time. In short, you first write a program or virtual instrument (VI) in LabVIEW in the RT development system that runs on the host under Windows 95/98/NT. Then you instruct that package to download your application onto the RT card.
When activated, that program executes under a real-time executive on the processor. If Windows crashes or hangs up, the embedded VI keeps going. You can even soft reboot the PC without disrupting VI execution, but a hard boot resets the board.
In this first version, the real-time engine is built around Phar Lap’s ETS, a Win32-compatible kernel enhanced with services such as communications to the development system. Interestingly, users have no way of knowing, or any need to know, which kernel is in use. The documentation makes no statements in this regard. Remember that LabVIEW handles all real-time details. This cloaking also makes it possible for NI to upgrade to another executive without requiring you to change any code.
Next, examine aspects surrounding execution threads and priority levels. You can select from among five execution systems, not counting the user-interface thread that, on the RT board, serves as the communications thread. Each system has five priority levels, bringing to 25 the total threads available.
When you create a diagram, LabVIEW defaults by putting all blocks into the standard execution pool with normal priority. Some users we spoke with are happy with those results and feel no need to tweak thread and priority assignments.
The RT card also can execute multiple applications simultaneously. However, you must be sure that by setting the priority of tasks in one VI too high, you don’t force lower-level tasks in an unrelated application to sit idle waiting for processor time.
To handle asynchronous events, you can either set up a polling loop or program in an Occurrence VI, which can trigger on a data acquisition event and act like an interrupt. Since LabVIEW supplies only one level of priority, one occurrence can’t interrupt another that’s already running, regardless of its importance.
According to Mr. Balent, the RT card can respond to an occurrence in 750 æs. With polling loops, users often insert a Metronome or Stopwatch VI to cause the VI’s thread to pause and allow other tasks to execute. With this software timing, jitter in the loop is 10 æs maximum. But by using hardware timing based on a card’s timer/counter, you can bring jitter into the nanosecond range.
LabVIEW does not provide a method where a VI can wait for less than 1 ms. As a result, a VI with a wait mechanism can’t execute any loop faster than 1 kHz.
The Process in Depth
Let’s examine the programming process in more detail. Within the RT development system, you either create or load an existing VI-but you can’t run it here. Instead, when you instruct the development system to run the VI, it initializes the RT board, and along with your program, it downloads a special version of the NI-DAQ device driver and the real-time engine into DRAM.
The fact that these embedded VIs don’t run under Windows has several implications. They can’t call Windows services such as ActiveX nor can they read/write to system resources like the printer, disk drives, or the monitor. The system only supports the I/O on the daughter card, so applications have no access to serial or parallel ports, Ethernet cards, or IEEE 488 interfaces that might be resident in the host system.
With the exception of VIs that call Windows resources, all others are available in the development system for use in embedded applications. Keep in mind that when you run analysis VIs on the card’s 133-MHz 486 CPU, you might perceive their performance as sluggish.
Another bottleneck concerns getting data on and off the board. Many analysis VIs work with arrays or large files. But with a peak host-RT transfer speed of roughly 200 kB/s, you’re better off dedicating the RT card to collecting process data and control applications rather than complex analysis procedures.
If all you need is a graphical user interface (GUI), the development system can display any indicators and interactive controls you programmed as part of the embedded VI. However, the executive gives the GUI communications task a lower priority than any real-time tasks. As a result, if a high-priority thread dominates board resources, the interface might seem to lock up.
In contrast, you can shut down the development system, use the host for another purpose, and then restart that application. Upon startup, it determines that a VI is running on the RT board. If it can find the VIs on the local hard disk that correspond to the code you downloaded earlier, it automatically synchronizes the user interface, which again becomes an active GUI.
Placing all graphics activity off the RT card has another effect: When estimating the size of applications that fits in the 8 MB of DRAM, don’t think in terms of desktop LabVIEW applications. Before the development system downloads VIs, it strips out unnecessary information such as the block diagram, controls, and indicators and actually sends down only pure VI source code.
That memory holds a fairly complex application according to Mr. Balent, who estimated that an application that takes 2 MB in its desktop version requires perhaps only 500 kB in RT memory. Even so, users report a minor distraction waiting the 20 s or 30 s needed to download a large application.
Adding Host Power
To do anything more than setting controls and reading indicators, you must write a host application in standard LabVIEW which is bundled with the RT software. Such an application can, for instance, save results to disk or perform extensive post-acquisition analysis. Once execution starts on the RT card, a host application can’t dynamically add or remove VIs; the only way to download VIs is through the development system.
Keep in mind you can’t run a copy of the development system and standard LabVIEW on the same machine. It would be nice to create some VIs in the host version and immediately download them for testing to the RT card without first exiting the host version and starting up the development system for VI downloading.
To get a host application communicating with the RT board, even to display a process variable, you must pull data from the card. One option uses a set of LabVIEW RT VIs, most of which peek and poke through the card’s 1-kB shared memory. These VIs entail the lowest communications overhead and are well suited for time-critical jobs. To transfer large files, you must break them into chunks.
Many users working with large files would willingly give up some performance to avoid the hassles of peeks and pokes. They can fall back on two sets of VIs already part of standard LabVIEW that work with the RT card’s shared memory and shield them from protocol details and memory-management operations.
First are Transmission Control Protocol/Internet Protocol (TCP/IP) VIs, which work over a network. Second come Server VIs, which are based on TCP/IP data transfers but hide that fact from users and are even easier to program. With this technology, a host LabVIEW application views RT hardware as just another networked machine on which it can invoke VIs. And unlike with TCP/IP, here a host application can pass control parameters to VIs executing on the RT board.
Program documentation indicates that overhead for TCP/IP is higher than for peeks and pokes, and for VI Server it’s even higher. However, for larger blocks of data, all three schemes operate roughly equally.
(Ful)filling the Wish List
LabVIEW RT opens up entirely new application areas for PC-based data acquisition and control. The users we spoke with (names supplied by NI) were enthusiastic about the product, especially having the ability to write real-time programs in a familiar language and run them on a desktop PC.
Nothing’s perfect, though. Rather than list criticisms, these users tend to point out features they hope for in later releases-and NI is listening very closely to these requests.
One obvious desire is for more horsepower by replacing the 486 with a Pentium. It’s no surprise that users would like more memory to accommodate larger applications or hold other on-card I/O functions such as direct communications over a TCP/IP link.
Indeed, the most frequent request is for more and different kinds of I/O that you can either plug onto the RT board or otherwise connect to it. Besides the analog and digital I/O now on the three modules, some users would like, for instance, to interface to imaging systems or generate motion outputs from the real-time kernel. Others would prefer a standardized connector to develop specialized I/O.
And rather than be pinned down to running the RT card in a PC or PXI chassis, some users would like to see the capability available on other form factors. They believe that PCMCIA cards, PC/104, or other similar vehicles would allow them to use LabVIEW RT applications in the field more easily or implement portable instruments based on that technology.
On the software side, one user in the scientific community indicated that he’d like to see the development system running under Linux. He explained that the people he works with begrudgingly use Windows only because it’s the sole choice for a desired application-in this case, LabVIEW RT. They’d much prefer to run it under an operating system they have more confidence in, such as Linux.
About the Author
Paul G. Schreier is an independent marketing consultant and technical writer specializing in data acquisition, DSP, and PC-based engineering tools. He has worked as the chief editor of EDN magazine and was the founding editor of Personal Engineering & Instrumentation News. Mr. Schreier earned B.S.E.E. and B.A. degrees from the University of Notre Dame and an M.S. in engineering management from Northeastern University. His address is 25 Washington Rd., Rye, NH 03870, (603) 427-1377, e-mail: [email protected].
Return to PC-Based Test Online – Return to EE Home Page
Published by EE-Evaluation Engineering
All contents © 1999 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
November 1999
