Software Glue

Visual Basic for Applications Lets OEMs Connect Control Systems, Specialized Software, and Operator Interfaces Together With Ease

By Rich Merritt

Share Print Related RSS
Page 1 of 3 « Prev 1 | 2 | 3 View on one page

15th AnniversaryDuring the year, as part of our 15th anniversary celebration, we've republished content that originally ap­peared here over that period. Our final installment for 2012, as it appeared in the June/July 1999 issue, is then-editor Rich Merritt's report on the emergence and growing pains of VBA in the industrial space as an easier way for controls engineers to develop operator screens in Windows-based systems. Some developers saw its value right away. Others fretted over a new terminology to learn, and concerns about robustness.

OEMs developing Windows-based software for their control equipment — and system integrators building open-architecture PC-based control systems — are beginning to use Visual Basic for Applications (VBA) in increasing numbers. Although few use VBA for actual control functions, OEMs are discovering VBA makes it easy to develop operator interface (OI and HMI) screens, establish communications with PLCs and other devices, and integrate one or more software packages from outside suppliers.

In most cases, OEMs can concentrate on developing their core-competency software, such as machine tool or extruder controls, and use VBA for the rest of the system. There are, however, many other OEMs not using VBA, perhaps because VBA can be difficult to understand.

Cyberbabble Reigns Supreme
VBA suffers from the same problem as most of today's PC software. The terminology needed to describe it can be difficult to get a handle on. Explanations of VBA often use terms — API, COM, OLE, OPC, ActiveX, objects and ODBC — we don't fully understand.

Is this a problem? It can be. Daryl Walther, product marketing manager at Rockwell Software, Milwaukee, says some of Rockwell's customers think VBA is too complex. "For this reason, we don't force our customers to use VBA if they don't want to," Walther says. "Although our RSView32 and ProcessPak software have VBA embedded, customers can still use conventional fill-in-the-blanks configuration procedures and interfaces to get a system up and running. VBA is there to give more technical customers an extra tool."

Some providers believe acceptance of VBA depends on the person. "IT specialists, production engineers, process engineers and plant management are likely to build and use applications glued together with VBA," says Phil Ryder, vice president of sales and marketing, OSI Software, San Leandro, Calif. "In many cases, they are already comfortable with it because VBA is integral to Microsoft Office products." He thinks VBA is less interesting to control engineers because it has never been hardened for use in control. "If there is an error in a display, it is an annoyance," explains Ryder. "An error in a control strategy can cause a disaster."

Other software suppliers feel because many end users are not computer programmers, they hesitate to use VBA. "VBA is used mostly by system integrators and OEMs," says Ralph Rio, Cimplicity HMI software marketing manager, GE Fanuc, Albany, N.Y.

The major advantage comes when there's someone on staff who knows how to write VBA scripts. Such a person can add functions more quickly than ever before. And, as it turns out, VBA isn't all that difficult to understand, once you cut through the cyberbabble.

Writing Scripts
In typical fashion, Microsoft has taken the original BASIC language and made it complex and difficult to understand. However, though the language might seem complicated, in a very few instructions it can perform functions that would have required major software projects not long ago. A few VBA instructions can obtain data from another company's database.

Perhaps this explains why [as of 1999] nearly 3 million Visual Basic (VB) software development packages (VB is the language in which you write VBA scripts) have been sold. VB has become the world's most popular development language, so it can't be that hard to use.

A major advantage of VBA and COM is that Microsoft's Intelli-sense (built into VBA) makes sure you cannot execute an incorrect object call. If a programmer wants to use a third-party object called SPC, he would first load it onto a hard drive. Then, in a VBA development package (Figure 1), he'll define the object by name. The very instant that he types the "." in SPC., Intelli-sense finds the object and returns a list of functions, subroutines, methods and properties contained in the object. If he makes a mistake calling SPC., errors will be flagged when he tries to run the script.

Paul Vanslette, vice president of research at Intellution, Norwood, Mass., thinks it's pretty easy. "All Intellution objects, including embedded ActiveX controls, are directly accessible from a VBA script," he says. "There is no need for another command language or special Invoke function to pass data between the application and VBA. Just type in the object name and you have access to all the object's properties and methods through Intelli-sense."

Scripts can be run in response to process exceptions, alarms, pushbutton inputs or timed sequences (Figure 2). "With an event scheduler, you can monitor for either a time or process event and trigger any VBA action,"  Vanslette says.

Page 1 of 3 « Prev 1 | 2 | 3 View on one page
Share Print Reprints Permissions

What are your comments?

Join the discussion today. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments