Print page

Email page

Software glue

ControlDesign.com

Visual Basic for applications lets OEMs connect control systems, specialized software, and operator interfaces together with ease.

By Rich Merritt, Technical Editor

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. While 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,” says Walther. “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, VP 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, while the language may 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 nearly three 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, 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. “With an event scheduler, you can monitor for either a time or process event and trigger any VBA action,” says Vanslette.

The Promise of VBA
So, if OEMs master writing VBA scripts, what can they do with it? Lots of stuff, it seems. “The battle cry of VBA is that you never have to say no,” says Ryder. “If an OEM wants streaming video in an OI or needs to communicate with SAP, he just obtains the software, embeds it in an OI, and manipulates it with VBA scripts.” That means if the needed software is VBA or COM enabled, a VBA script will connect it. That’s a big if, but VBA/COM is being added to more and more software packages.

The interface process is not entirely simple, because VBA scripts still have to be written, but connecting software packages is much easier with VBA than without it. Phil Morrow, executive vice president, Kesler Engineering, an East Brunswick, N.J.-based supplier of ActiveX packaged software that monitors fired heaters and fractionators, says that before VBA they had to write custom interface drivers for every control system at a cost of about $50,000 per project, plus they had to maintain interfaces through changes and upgrades.