04evaluation1

An Evaluation of LabVIEW 5.0 and HP VEE 5.0 Part 1

The two best examples of test and data acquisition-related graphical programming are LabVIEW 5.0 from National Instruments and HP VEE 5.0 from Hewlett-Packard. Version 5? Has it been that long? In fact, it has been 10 years since LabVIEW Version 1 appeared.

As the leading products for graphical test programming, a great deal is expected from these packages. Are they up to it? Are they worth the money and especially the time required to really master them? In short, can you use these tools to solve tasks better, faster, and less costly? If so, we’ve got something.

You will be the ultimate judge. But before you make your final decisions, here’s what we uncovered about both programs, including some eagerly awaited features. And our evaluation doesn’t forget the people who may be looking at graphical programming for the first time.

Part 1 of this evaluation focuses on LabVIEW 5.0. Part 2, which will appear in the May issue of EE, will discuss HP VEE 5.0.

Multithreading

Users of Windows 95, 98, and NT, Sun Solaris 2, and Concurrent PowerMAX will be able to write applications that take full advantage of LabVIEW’s new multithreading capability. If you have a single processor in your computer, LabVIEW will preemptively multitask areas of your application that can execute independently or in separate threads. This is similar to what these operating systems do when they share processor time between separate applications.

If you have multiple processors in your system, the tasks will be able to run on separate processors. The tasks are preempted according to the priority assigned to the sub-virtual instruments (VIs) of each task.

Although the number of threads available is limited, it is definitely an advantage to programmers who want to speed up their code and assure the tasks in an application are given the attention they deserve, without monopolizing the processor. To take advantage of multithreading in LabVIEW, a programmer can specify that subVIs run in separate execution systems.

The User Interface execution system accommodates the user interface. When you toggle a switch or rotate a dial, the user interface system handles the processing of that event and allows the other threads to continue without being bogged down. Programmers who have seen their application slow to a snail’s pace while the user adjusts a control will be happy to hear this news.

In addition to the user interface system, a VI may be assigned to operate in five other execution systems: standard, instrument I/O, data acquisition, other 1, and other 2. Normally, VIs default to the standard system.

The instrument I/O and data acquisition execution systems were named to suggest, but not dictate, functional groupings of VIs. The other two have less descriptive names, but are, nonetheless, full-fledged execution systems.

Except for the user interface system, which has one thread, each system has two threads available for queuing tasks. Each thread is responsible for executing one task at a time, such as a Code Interface Node, while the other thread performs a separate task in parallel.

You can start making VIs that have a real-time aspect to them, especially if you have a dual processor system. Multithreading is a very complicated subject if you intend to become an expert. But for most situations, LabVIEW will simply and automatically improve the performance of your VIs with no work on your part.

For those of you using a Mac, Windows 3.1, HP-UX, or Solaris 1, the operating system does not support multithreading so you cannot expect closed-loop, real-time performance of any significant speed. In these operating systems, a LabVIEW application is single-threaded, and the LabVIEW execution system cooperatively multitasks VIs as it always has.

On the Mac and under Windows 3.1, LabVIEW cooperatively multitasks with other applications by yielding some time to them as it sees fit. Under HP-UX and Solaris 1, the operating system controls preemptive multitasking between LabVIEW and other applications.

Undo

The long-awaited Undo option has arrived. This, by itself, is enough to justify upgrading to LabVIEW 5. There also is a Redo command. LabVIEW automatically remembers the last several changes you made and allows you to step back and forth between them to correct mistakes. You even can use this feature if you forget what you were doing and simply want a reminder.

The default maximum number of undo steps is eight, but this number can be changed in each VI. You may run into memory problems if you give yourself too big of a safety margin. Of course, you still want to periodically save your changes to disk to guard against crashes.

There are a few cases in which a VI will lose its undo information, and they have to do with changes made to a called VI. If the connector pane pattern or the data type of a control in the connector pane of a subVI is changed, the calling VI will lose its undo information.

Undo information in calling VIs also is lost if:

  • A strict type definition’s appearance is changed.

  • A custom control’s data type or strictness is changed.

  • A type definition is changed to a custom control.

  • A data type or name of a control is changed.

  • A control is added to or removed from a global VI.

This may seem like a long list, but considering that the cannot-undo list previously included everything but changes made in the icon editor, this list is acceptable.

ActiveX Container

If your operating system is Windows 95, 98, or NT, ActiveX allows you to use any combination of applications you want to solve your programming problem. Want to run a LabVIEW VI from Excel? Want to use a Visual Basic program to load results from a VI into a data base? ActiveX allows you to activate programs and exchange information with other applications from the comfort and safety of your LabVIEW block diagram—or vice versa.

ActiveX seems to be the solution to many limitations you may have found in previous versions of LabVIEW. The online reference reads like an object-oriented programming manual. But even for newbies, the examples of ActiveX Automation are easy to follow and create the feeling of doors opening and walls disappearing. What could be better for a programming environment than access to other programming environments?

Instrument Wizard

The Instrument Wizard makes it easier to use LabVIEW right out of the box. It is to the world of instruments what the DAQ Wizard is to plug-in boards.

The Instrument Wizard offers several features for self-administration of instrument drivers. Using it to add and remove instrument drivers provides some level configuration control since all drivers will be located in the same directory. Their location in the instr.lib directory also means that they will be available on the Instrument Drivers palette of the block diagram.

Users who prefer to keep their custom VIs outside of the LabVIEW directory for backup purposes may see this as a minor nuisance. But remember that the function palette can be customized to select another directory to store instrument driver files.

The Instrument Wizard wants to load the instrument drivers from the Instrument Driver CD. If you download your drivers from the net or get them from some other source, it is up to you to put them in a subdirectory under the instr.lib directory.

The Instrument Wizard also generates application examples that use the newly downloaded instrument drivers. You can use these application examples to communicate with your instrument shortly after the driver is downloaded. Also, the example is just a regular VI, so it can be customized to suit your application. And the Instrument Wizard will scan connected devices to let you know what instruments are connected to your GPIB or COM ports or installed in your VXI chassis.

The DAQ Wizard also was upgraded to include analog output, digital I/O, and counter/timer capabilities. And the DAQ Wizard now is available for the Mac OS.

Programmatic Menu Bars

Another significant enhancement to LabVIEW is the capability to customize the menu of a front panel. Unlike most other programming environments, the menus in LabVIEW are designed primarily for the programmer. Typically, users should not access these menus. They must be disabled, or users should be instructed not to access them. Unfortunately, users unfamiliar with LabVIEW have a tendency to go straight to the menus because that is the normal thing to do with windows-based applications.

Until now, all user inputs to a LabVIEW application came from gadgets on the front panel. Buttons, knobs, dials, and listboxes had to be arranged, colored, and sized to attract attention.

With programmatic menu control, the programmer can rely on the user’s familiarity with menu bars to assist in gathering inputs. Programmatic menu bars will not, and should not, replace all other user input controls, but are definitely a welcome addition to the existing suite of LabVIEW controls.

Many new features are associated with this function. You will want to take advantage of the capabilities to place a checkmark next to a menu item and to dim a menu item. You can use these menu attributes anywhere in your program to determine whether or not a particular action should be taken. You use the Get and Set Menu Item Info functions to accomplish these actions.

Feel free to experiment with the simple parts of menus, then examine the examples. By the time you become an expert using menus, you will be able to dynamically change their appearance.

Graphical Differencing Tools

Team programming is a challenge. No matter how tightly you try to regulate the version control of files, there always will be times when the bookkeeping gets sloppy or the programmers forget the rules and make changes that later have to be removed or documented.

The graphical differencing tool introduced in Version 5.0 should appeal to novices, experts, and everyone in between. One major detail: the Graphical Differencing Tools only are available in the Professional Development System or the Professional Developers Toolkit. The Full Development System does not have these tools.

There are three different flavors of Graphical Differencing Tools: Compare VI Hierarchies, Compare VIs, and Source Code Control>>Compare Files. The Compare VI Hierarchies tool compares two versions of a top-level application VI. The window allows you to select the two VIs from anywhere in the accessible file system. The two VIs are judged to be either the same or different.

SubVIs are categorized as Shared, Added to the first VI, or Subtracted from the first VI. Descriptions are given of the differences, and a Show Differences box can be clicked on to bring up the two VIs (tiled for easy viewing) and to open the Differences window.

In the Differences window, individual miscompares are listed. Then, when double-clicked, the relevant portions of the panel or block diagram are highlighted, and the differences are circled in red. There is a demo of the differencing feature which consists of a Compare VI Hierarchies example.

The Differencing Tools have some limitations—an effect of LabVIEW’s inability to load two VIs with the same name. For instance, in comparing VI hierarchies, the first VI is loaded into memory as usual, but the second is put in the temporary directory and renamed to have a cmp. prefix. This is done for only the top VI in the hierarchy so any subVIs in the second VI that have the same name as subVIs in the first will not be loaded or renamed. Instead, the second VI will link to the subVIs loaded by the first VI. This just sounds like another good reason to maintain version control in the first place.

With the Compare VIs tool, the choices of VIs to compare are limited to those VIs already loaded into memory. This means that if you want to compare two VIs with the same name using this tool, you must rename one of the VIs and have them both open before you choose the Compare VIs option from the Project menu. This is an inconvenience, but one that LabVIEW users have grown accustomed to over the years.

Translation and Documentation Tools

After spending many hours struggling with the task of documenting a rather large LabVIEW 3.1 application, it is a pleasure to see the new insta-documentation feature of LabVIEW 5.0. This feature outputs information to a printer, an HTML file, an RTF file, or a plain text file.

In the past, the most difficult objective was to organize a project’s documentation for easy reference. For lack of a better solution, the documentation for each subVI ended up in alphabetical order in a 3-ring binder. A much better option would have been a set of HTML pages organized in a hierarchical manner.

Unfortunately, there was no HTML then. And even if there had been, screen captures of front panels and block diagrams would have been required as well as the HTML to document each VI.

Now LabVIEW can generate an HTML file for a VI with a mouse click here and there. Then it’s up to the programmer to link the pages together. Instead of a clunky, overstuffed binder with the pages falling out, you have ready-made, point-and-click documentation complete with color images of the front panel and block diagram if you want them. Certainly, this feature brings smiles to the faces of programmers and users alike.

For folks who intend to market their software in foreign languages, there is a documentation feature that exports the strings for a VI to a file. That file then can be edited to replace the strings with their translations to other languages and imported back into the VI. This can be done in the edit mode or programmatically by using the VI Server functionality that facilitates Distributed Computing. In contrast to changing the strings manually or selecting them via attribute nodes, this solution seems much less time-consuming and cumbersome.

Distributed Computing Tools

The write-up that introduces the new features of LabVIEW 5.0 paints a picture of ease and efficiency regarding the creation of distributed systems. It seems more likely that distributed systems always will be fairly complicated, and there always will be difficulty associated with running blind on those computers that you have scattered far and wide.

However, there are some handy new VIs in LabVIEW 5.0 that help execute VIs on other systems on a network. Provided you carefully study the examples of VI servers and clients, you have a chance at creating LabVIEW applications that will run on your distributed systems. The distributed system will not design itself, but the new tools will help you in the design process and keep you from having to delve too deeply into the details of Transmission Control Protocol (TCP).

LabVIEW 5.1

This version of LabVIEW includes a few more new features and a great many of the add-on products as standard. The most notable new feature is the capability to create a front panel that automatically resizes one or all of its objects as you resize the panel’s window.

You also can have a panel’s window automatically resized in proportion to the screen’s size. You have to be careful when using these features because some things do not actually resize, such as text fonts.

The Application Builder, the Professional G Developers Toolkit, the Picture Control Toolkit, and the G Math Toolkit now are among the add-on products. There also is a more integrated interface to HiQ and MATLAB and the capability to create and record sounds.

On Windows platforms, there are ActiveX enhancements including a new 3-D graph and the capability to create text-based printouts that use font attributes such as style, font, size, and color-things that are extremely difficult, if not impossible, to do under program control with existing text indicators.

A revolutionary new real-time version of LabVIEW, called LabVIEW RT, now is available. It runs on Windows-based PCs or PXI computers just like the regular LabVIEW except that it allows you to download VIs to a new RT Series processor board that interfaces with special RT Series data acquisition and control boards.

This finally solves the real-time problems associated with using operating systems that are not real-time. The iteration rates now can be guaranteed while taking advantage of the ease of programming with LabVIEW.

Summary

As usual, we were delighted to learn of the new features in LabVIEW 5. Again, National Instruments has taken a great product and made it even better. Of all the new features, we appreciate Undo and the Documentation Tools the most. The others will have their place as projects demand, but Undo and ready-made documentation are the most universally appreciated features.

Disclaimer

This article was written by the authors as private individuals and not in conjunction with JPL.

Click here for An Evaluation of LabVIEW 5.0 and HP VEE 5.0, Part 2.

About the Authors

Ed C. Baroth is the technical manager of the Measurement Technology Center at JPL. He holds a bachelor’s degree in mechanical engineering from City College of New York and master’s and doctorate degrees in mechanical engineering from University of California, Berkeley. (818) 354-8339, e-mail: [email protected].
Chris Hartsough has a long and varied background in computer systems development, methodology, and systems test. Currently, he is working with web-centric applications to develop a framework that supports the use of visual tools with mainstream database, office, and web products.
Amy Holst is a staff engineer in the Telecommunications Equipment Section of JPL. She currently is developing flight and support equipment software for the Spacecraft Transponding Modem, a next-generation spacecraft radio. Ms. Holst graduated from UCLA with a B.S. in aerospace engineering and has worked at JPL for more than six years. 
George Wells graduated from Cal Poly Pomona in 1969 with a B.S. in electronics and immediately started working in the Instrumentation Section at JPL. For the first 20 years, most of his work involved building custom data acquisition and control systems. Since the Measurement Technology Center was established in 1991, all of Mr. Wells’ work has been based on off-the-shelf computers, plug-in boards, and external signal conditioners using LabVIEW to customize applications.
Jet Propulsion Laboratory, California Institute of Technology, 4800 Oak Grove Dr., Pasadena, CA 91109.

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.

April 1999

Sponsored Recommendations

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!