Part 1, which appeared in the April 1999 issue of EE, focused on LabVIEW 5.0. Part 2 addresses HP VEE 5.0. And once we dissect HP VEE, we dive into an in-depth comparison of the features and shortcomings of both graphical programming languages. (Click here for comparison information.)
By way of explanation, for the past year we have not worked on projects where HP VEE is the tool of choice. Instead, we have been working with tools most of which are provided by a large software vendor in the Pacific Northwest. So it was with some trepidation that the latest version of Hewlett-Packard’s Visual Engineering Environment (VEE) Version 5.0 was installed. But unlike some vendors, where a new version produces chaos, HP’s transition to 5.0 was flawless.
Working with Version 5.0 of HP VEE is like going home after you have been away for a long time. The glasses, cookies, and milk are all just where they should be. All the components are in the old places; they all operate in the old way. Everything works as you expect. On careful examination, there are new things on the lists of choices, and these are the improvements that you can learn and use when you have time.
HP understands that timing is important. The dramatic performance improvements between Version 3 and 4 broke some Version 3 programs. These programs had inadvertently counted on the performance parameters of Version 3 and did not check on completions in some instruments. Consequently, code that ran fine on Version 3 failed at the higher speed performance of Version 4.
In Version 5, you have the option to run at the speed of either Version 3 or 4. In short, the new version runs faster, but it can be made to run slower for legacy code.
There is a collection of features that singly are interesting and useful, but when taken together can transform the way you do business in your testing. They are the interfaces to the outside. Yes, there always have been ways to run programs and send data to other processes. That has not changed, although it now takes on new significance. HP VEE has entered the world of the ActiveX components.
ActiveX
For those who have avoided the ActiveX development pains, ActiveX is both a software interface style and an approach to componentization to provide function/data/service sharing. The paradigm provides a structured interface of properties that are (approximately) data, methods that are (again approximately) functions, and events that are function callbacks.
Each time an event occurs, the ActiveX routine calls your specified function. For example, for an ActiveX input text box, each time a change occurs, call my function named IsValidData. In the HP VEE context, it is like the OK button’s side connector. When the event of OK-button-pushed occurs, run the stuff attached to this connector.
Why is the adoption of an interface protocol worth so much space in a product review? Simply because it makes HP VEE a player in the evolving information processing world. So, what are the most vexing problems we face in instrumentation information processing? Complicated data analysis, information storage, and printed presentation of results top the list.
HP VEE provides some data-analysis capability. But when your need outstrips what is provided, you must do one of two things: bite the bullet and lay down some not-so-intuitive HP VEE code or export the data to another program. Often the other program is an Excel spreadsheet. The interface is not very hard, but it is not clean either.
With the new ActiveX interfaces, you can run Excel from inside your HP VEE program, put the data where it needs to go, and let Excel produce the result. Clean, contained, and no little files lying around.
Data from multiple instruments can be placed in the same spreadsheet, and multiple spreadsheets can run at the same time. Built into the Excel environment is access to databases so that calibration information, for example, can be incorporated into the analysis without getting HP VEE involved.
If it can be done for Excel, it can be done with any other program that exposes ActiveX automation server interfaces-which is just about everybody these days. As an aside, you could use Microsoft Outlook98 (or other ActiveX mail package) and have your HP VEE program send e-mail (including e-mail to a pager) when specific conditions are found. This would not be a lot of work and, when done, could be used by all the HP VEE programs in your shop.
Database Technology Using ActiveX
Information storage in instrumentation systems always has been a pain. Of course, if you don’t need historical data, the bit bucket works fine. If you do need to keep the data, you may end up with files everywhere.
With good documentation discipline, all the file formats are defined, and everyone uses the same data names so you can easily see how the data is used. File names are consistent and unambiguous, backups are made regularly, and test reruns are fully managed. Right.
Why not use a database? It’s a pain, that’s why. With the new ActiveX interface, it is still a bit of a pain, but not as big as it was. Using Microsoft’s Active Data Objects, you can connect to a database with as much ease as a Visual Basic programmer. You won’t have a big, complex database schema: just a time stamp, a few identifiers, and your data.
In your HP VEE program, you create a text string that has a few magic words in it, like INSERT, and your data. You send the string into a command User Function you have set up which, in turn, hands your data to the database.
Which database? If you keep everything simple, which is what we are after, almost any database that supports Open Database Connectivity should work fine. Now your file-format documentation is the database’s problem, your information technology folks are smiling, and your documentation load is cut way down.
Regarding pretty printed presentations, HP VEE provides excellent real-time and near-real-time displays. Publication is not HP VEE’s intent. Using the ActiveX linkages, you can use tools like Excel, Word, PowerPoint, or most any other vendor’s offerings to create the reporting template. HP VEE can directly insert data into the report.
Visual Basic for Applications
But wait, there is more. For no additional cost, HP includes support for Visual Basic for Applications (VBA). Using HP VEE, you can create ActiveX components and turn the whole paradigm we were just discussing inside out.
Instead of having HP VEE in control and inserting data into a spreadsheet, you can have the spreadsheet run an HP VEE user function when the spreadsheet needs data. It actually gets more interesting. Any program that supports VBA can easily use HP VEE functionality to obtain data for that program’s own needs.
For example, Adobe Illustrator (and CorelDRAW in the next release) incorporates VBA. Diagrams can be generated or altered from the values supplied by the VBA program. The Illustrator VBA program can use ActiveX components that are written in HP VEE to obtain data. Because access is provided to display properties available and the geometry of the drawing, shapes can be altered. If ever needed, you can provide as-built drawings for a part literally built with HP VEE.
In summary, HP VEE is an effective participant in the Microsoft ActiveX paradigm. This opens the door wide to using a variety of tools and services that were not previously easily available. It offers the possibility of exploiting the productivity gains afforded by HP VEE in support of a selection of software that wasn’t feasible before.
Are there any cautions? Yes. First, not all data types are supported; you need to stay mainstream. Also, ActiveX components, while easy to interface, may have their own interesting properties. The best approach is for the HP VEE engineer or programmer to work with someone who has used the ActiveX component before. It is probably even worth getting a few hours of an outsider’s help when tackling a feature-rich interface.
Web Interfaces
Is that all there is to 5.0? By no means. Some support has been provided for web interfaces. Neither complex nor complete, the interface actually makes good sense. Without much effort, you can look at HP VEE in either the diagram view or panel-only view.
The interface will be attractive for three classes of users. The first is the HP VEE engineer or programmer who needs to get a quick look into an HP VEE program without traveling to the site. If the problem is simple, it may be possible to have the local personnel fix it with simple instructions, or the module could be downloaded, fixed, and uploaded.
The second class is the HP VEE support team. For example, provision is made for single-stepping a User Function over the network.
The third group includes those who need to keep an eye on a test. With reasonable design of the panels, the occasional refresh on a web browser could let someone remotely monitor an HP VEE-controlled activity.
Support for UNIX
What about the UNIX folks? Nothing has been taken away from them. Many of the enhancements in 5.0 are mirrored in the UNIX world and their equivalent capabilities where appropriate.
Some features of the UNIX X-windows are not available under Windows. You can run a User Function on a remote machine, for example, and have the display show up on a third machine, perhaps half a world away.
Summary
If you are using HP VEE, get Version 5.0. If you are not using a diagram-based language for instrumentation and test, why not? The productivity gains are huge.
(This is an in-depth comparison of the features and shortcomings of both graphical programming languages.)
So how does LabVIEW 5.0 compare with HP VEE 5.0? We can’t seem to discuss one without bringing up the other.
Similarities
They both do data acquisition, analysis, and operations display. They both have ActiveX and web processing. They both use graphical programming, but they do it differently. They both can offer productivity improvements of up to 10 times conventional programming.
Both come from a data acquisition system vendor, and it shows. The principal focus of these programs is not programming; it is data acquisition and analysis. They are both comprehensive computer languages, not simply applications. They both can be used for small, simple tasks. But if that is all you ever need to do, they both may be overkill.
Differences
For use with PC-based interface cards, the industry seems to have selected LabVIEW over HP VEE, primarily because LabVIEW permits you to control the cards effectively. The focus of HP VEE has been and remains on controlling fully capable instruments, such as scopes, signal generators, RF equipment, and instruments that connect to computers using GPIB or RS-232.
Yes, LabVIEW does work with GPIB and RS-232, and HP VEE does work with interface cards from Computer Boards and Data Translation. We are talking in general terms.
LabVIEW follows the data-flow paradigm of programming rigorously. HP VEE is loosely based on data-flow diagrams with a large measure of flow-charting sprinkled with a little decision table.
LabVIEW provides high productivity for implementers and requirements suppliers who have a basic familiarity with data-flow diagram paradigms. HP VEE sometimes is more accessible to requirements providers because everybody knows how to prepare flow charts. LabVIEW’s Instrument Wizard is intended to help fill the gap and make it easier out of the box.
HP seems to have claimed a domain for HP VEE because it does what it does and does it well. Where it does not do some function easily or well, such as real-time process control of a device, HP VEE provides a convenient and natural interface to the specialized software that solves the specific problem.
LabVIEW, on the other hand, appears to expand the domain, incorporating into its language the many features requested by their users, such as multithreading and real-time process control.
Easy Recommendations
If you have a room full of HP equipment, use HP VEE. If you have a Mac, use LabVIEW.
Not-So-Easy Recommendations
If you have a mixed bag, try them both. Both vendors provide evaluation copies. If you expect to buy new equipment, ask if the interface boards or instruments you’re interested in have LabVIEW or HP VEE drivers. You will be surprised how many other manufacturers of data acquisition equipment are including LabVIEW or HP VEE drivers.
There appears to be more third-party support for LabVIEW than for HP VEE. In fairness, third-party support for HP VEE is substantial, if not as broadly based.
Conclusion
In summary, ask someone who uses either product. We guarantee that they will be happy to talk to you. We’ve never known anyone who uses either LabVIEW or HP VEE that wasn’t willing to talk openly and honestly. If you can’t find anyone to talk to, contact us.
Disclaimer
This article was written by the authors as private individuals and not in conjunction with JPL.
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]. On a personal note, I regret that this is the last article I will submit to EE as technical manager of the MTC. It has been fun, and I certainly have enjoyed the 10 articles we submitted over the last six years. I have accepted another position at JPL, and I’m turning over operations of the MTC to Jim McGregor. Expect evaluation articles from him in the near future.
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.
May 1999