Visual programming gets your data-acquistion system up and running in hours or days, instead of the months needed to use traditional coding in Basic or C. MS Windows is the most popular environment, but its interrupt latency can threaten data integrity in high-speed and control-system applications.

Visual programming--also known as graphical, diagrammatic, or iconic programming--for data-acquisition systems works in exactly that fashion. In visual programming, the blocks are preprogrammed software modules that appear as icons on your display. You select and connect icons representing sensor inputs, ADCs, and display outputs in a logical sequence. Some of the icons, such as displays, are standard for any application, but others correspond to hardware specific to your measurement system. Clicking on an icon opens a dialog box containing a range of properties for that icon's function. For an ADC card, you type in properties such as channel number, sample rate, and voltage range. Other icons enable you to insert a wide range of math functions to operate on input signals, such as statistical, algebraic, and frequency-domain operators. Finally, and what gives visual programming its greatest impact, you have icons for building a highly impressive user interface for your system. Sliders, pushbuttons, gauges, meters, and graphs offer you unlimited scope in devising a front panel just to your taste.

[Picture 1] In an ever-increasing number of applications, power MOSFETs and insulated-gate bipolar transistors (IGBTs) are displacing traditional bipolar power transistors. The MOSFETs and IGBTs use less silicon for a given rating and require vastly lower drive power. To choose between the two devices, you must evaluate several criteria and consider how your design will drive and provide protection for the devices.

The overriding benefit of visual programming for data-acquisition systems is the speed with which you can set up a system to take measurements. Traditionally, you could expect to employ the services of a software engineer for a couple of months to code in Basic or C before taking a single measurement. With visual programming, you can reasonably expect to reduce the two months spent coding to two days programming visually. The major gain results from the virtual eclipse of a software programmer to make the system run. Experience shows that scientists, hardware engineers, and system developers can easily exercise visual-programming software in the same way they would string together the hardware itself.

This feature makes visual programming motivational, fun, and naturally appealing, especially when compared with conventional coding, which is irritating and has little to do with the primary objective of acquiring data.

Additionally, visual programming benefits a wide range of users from the lone technologist to companies developing commercial applications. A technologist's priority is to gather data with minimal sidetracking; commercial developers have an overwhelming desire to reduce time to market.

Visual programming has existed for over a decade. One of the first products, National Instruments' LabView, mainly set out to simplify the programming of rack-and-stack IEEE-488 instrumentation systems. Over that decade, volumes of PCs running MS Windows have outstripped IEEE-488 systems, and, now, the major business for visual programming is operating PC plug-in and standard bus cards.

National Instruments' highly developed LabView remains a leading-market product, although most self-respecting PC-card vendors now offer a competitive product.

Table 1 surveys a selection of visual-programming data-acquisition software products. At first glance, it's not easy to distinguish product offerings. (Ref 2 reports on a basic bench test of seven of the products listed.) One basic difference is that some products, such as LabView, are stand-alone programs, and later products, such as Keithley's Visual DAS, are adaptations of MS Visual Basic. Also, price does little to distinguish products, and $995 is a popular number. Prices shown are for software to develop applications, although some vendors offer lower cost run time-only versions. Implementations using MS Visual Basic are lower cost, although you need to add around $199 for Visual Basic.

One product-to-product variation worth investigating is the range of software device drivers that each vendor supplies. Some vendors provide drivers for only their own range of plug-ins, which effectively obliges you to use their data-acquisition hardware. In contrast, an increasing number of third-party hardware suppliers offers MS Visual Basic and Visual C++ drivers that provide more of an open-system environment to developers using these programs.

Another important factor is the effectiveness of the driver. There's no simple to way to compare drivers, and you need to thoroughly evaluate performance before committing to a visual-programming or hardware product.

Although visual programming largely negates the need to be a software programmer, C designers need not fear for job security yet. First, writing software drivers for I/O hardware remains a prime requirement. Drivers involve significant coding, and writing your own can easily consume a man-year of effort. Second, although running data-acquisition systems under MS Windows is very appealing, Windows introduces a heavy cost and physical-size overhead and imprecise timing to the system.

The cost overhead results from the need for a posh PC to run MS Windows and a visual-programming environment. To run Hewlett-Packard's HP-VEE, for example, the company recommends a 33-MHz 80486 PC with a 1024x768-pixel SVGA display, a 16-Mbyte RAM, and 15 Mbytes of hard-disk space. In comparison, a C program would certainly run on an embedded 20-MHz 80386 processor card with less than 1 Mbyte of ROM and EPROM.

Relying on an MS Windows environment to control system timing is far from ideal for some data-acquisition setups. In practice, MS Windows relies on a PC's 55-msec interrupt latency, which is insufficiently deterministic for high-speed data-acquisition or control systems. (Interrupt latency is a measure of the time between an interrupt's asserting that data is available and the point when the CPU reads the data.) MS Windows was never intended to drive speed-conscious hardware and can't hope to compete with dedicated code running under real-time operating systems.

A further justification for retaining some traditionally programmed C-coded data-acquisition software in- volves safety-critical control-system applications. Without a great deal of beta-site testing, you can't be sure that either MS Windows or the visual-programming environment won't decide to display an obscure dialog box that halts a process at a critical point. With your own C code, you are still required to beta-test, but, overall, there are fewer unknowns in your own control software.

Programming know-how helps

Although visual programming claims that the user does not need not traditional programming skills, some programming experience can benefit your work. Also, some familiarity with MS Windows features such as Dynamic Data Exchange (DDE) and Dynamic Link Library (DLL) is important. Briefly, DDE is a standard MS Windows message-handling system for importing or exporting data between applications. A DLL is a Windows program providing functions that other Windows programs can use when driving I/O hardware, for example.

According to Stephen Salmon, software-design engineer with Arcom Control Systems, "There's no doubt visual programming enables most technologists to swiftly make a system produce results, although users' initial attempts may produce inefficient and inelegant solutions."

Comparing learning curves using different approaches, Salmon decided that, after two years of coding in C, he was competent enough to design software for data-acquisition systems. Moving on to LabView, he found that he could produce an equivalent system after a matter of days. (Because Visual Basic offers developers more program visibility, using Visual Basic takes a few days longer.)

Salmon advises visual-programming users to think carefully through their early applications and attempt to simplify their designs. He reports that new users typically employ several individual channels from input to display rather than introducing multiplexing. Unnecessarily duplicating sequential-and repetitive-event icons, instead of using for and while loops is another common overcomplication. Littering the display with icons rapidly eats memory that is needed to run a system and can limit operating speed because the program has to interpret the superfluous icons in the run mode.

Salmon also draws attention to the effect of Windows' inherent interrupt latency on operating speed. In many cases, a system's read rate is sufficiently slow that interrupt latency is not significant, as in a temperature-logging system that takes readings every few minutes. But, for high-speed data-acquisition or -control systems, it's important to know precisely when measurements occur, as in real-time logging.

In an ever-increasing number of applications, power MOSFETs and insulated-gate bipolar transistors (IGBTs) are displacing traditional bipolar power transistors. The MOSFETs and IGBTs use less silicon for a given rating and require vastly lower drive power. To choose between the two devices, you must evaluate several criteria and consider how your design will drive and provide protection for the devices.

To minimize the effects of interrupt latency, Arcom uses a special form of virtual extended-DLL driver (VxDLL) with its range of hardware, called a "SuperDriver." VxDLLs operate at low-level "Ring 0'' in an MS Windows environment, predictably trapping interrupts and enabling I/O interfacing independent of the host program (Fig 1). Any Windows-based program that supports DLL or DDE, such as Visual Basic, Visual C++, or LabView, can call Arcom's SuperDriver code.

Arcom has compared the interrupt-latency performance of its SuperDrivers with other MS-DOS and the Windows VxD drivers using a 40-MHz 80386DX CPU. Results show a range of latencies for each driver: MS-DOS mouse device driver running under Windows -100 to 400 µsec, Windows terminal emulator -40 to 65 µsec, and Arcom's Super- Driver-25 to 50 µsec.

Microstar Laboratories use a different approach to minimizing interrupt-latency effects. The company's PC plug-in data-acquisition boards include an on board processor, memory, and a real-time operating system called DAPL. This on board intelligence handles the time-critical aspects of an application and frees your data-acquisition hardware from delays and resource demands imposed by Windows. Running under the company's DASYLab visual-programming software, the processor typically achieves a task latency of <500 µsec.

References

1. Johnson, Gary W, LabVIEW Graphical Programming: Practical Applications in Instrumentation and Control, McGraw-Hill, New York, NY, 1994, includes disks, $45.

2. Eglowstein, Ira, "Friendly Acquisition," Byte, July 1994, pg 147.