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.
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.
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," Ryder says. "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.
Environmental Specialties Inc. (ESI), Raleigh, N.C., builds environmental chambers and provides HMI packages for the chambers using Fix Dynamics from Intellution. Dave Hodgins, control engineer at ESI, says VBA allows them to add capability to the Fix system, on the fly. "Before Fix, we only had access to functionality stored in a package's database," he says.
This was a significant change for ESI's customers. Without this scalability, ESI's end users had to purchase all the capability they might need for future enhancements up front. Otherwise, adding a single point or block to an existing database could cost up to $5,000. It used to be that an end user would have to buy a 300-point HMI package at the outset," Hodgins says. "Now, they can start with 75 points and add on according to their growth."Figure 3: Activex AT Your Service
Source: Software Toolbox
An Objective Look
Software Toolbox, Charlotte, N.C., produces ActiveX objects that can be purchased by OEMs for a custom control system. Using this approach, an OEM can create an operator interface for an extruder control system with four objects—bar graph, trend chart, and extruder graphic, plus a communications ActiveX control that handles the dirty work of talking to the PLC — from Software Toolbox's Instrumentation and Symbol Factory libraries (Figure 3).
John Weber, president of Software Toolbox, says this gets you development licenses for the libraries, and the runtimes are free. "That is the big advantage for the OEM," he says. "The OEM owns the application, and does not have to pay any further royalty or licensing fees for these components."
The symbol libraries have reduced time-to-market considerably for some OEMs. Sierra Therm, Watonsville, Calif., builds conveyorized furnaces, and uses ActiveX controls from Software Toolbox to build their HMIs. "Most of our customers say that our software is much better than the competiton, some of who have hired consultants to write their HMIs in Visual C++," says Fritz Watson, president of Sierra Therm. "Customers say we have more features in our HMI. More important, we can change things or add custom features when needed much faster than in Visual C++."
Most VBA-enabled OI software packages have similar toolbox packages, so users can script in ActiveX meters, pushbuttons, switches and other OI monitoring and control functions. "Using a package such as our ActiveX ToolBox (Figure 4) allows OEMs to rapidly develop custom OI screens from a library of ActiveX controls," says Russ Agrusa, president of Iconics, Foxborough, Mass. "OEMs who get really good at writing VBA scripts can build their own ActiveX OI containers."
OSI's Ryder cautions that it is extremely difficult to build a full-featured ActiveX control container. "Most of the licensees of VBA have not done this," he says. "They simply link in VBA and force the user to use Microsoft forms to contain the controls. It is extremely easy, however, to build ActiveX controls that go in these containers."
Some OEMs just pluck a routine or two from a VBA library to take care of tough problems. Metro Weighing and Automation, Taylor, Mich., purchased ActiveX drivers for Modicon's Modbus and Allen-Bradley's Data Highway Plus. "We programmed everything else ourselves in Visual Basic," says Tim Harrison, president. "But we bought the two ActiveX PLC controls. It would have taken us forever to write them ourselves." Metro makes vibratory feed systems. They use a PLC for hard control and a PC for HMI, supervisory control of the PLC, and for the I/O interface. "It's much easier to interface scales and other intelligent systems to a PC than it is to connect them to a PLC," Harrison says.
Awaiting Further Developments
At the moment, most OEMs are not taking full advantage of VBA. Not all OI software companies adopted VBA either. For example, Citect, Wonderware and Object Automation haven't yet released VBA-enabled OI software.
One reason may be that loop-integrity problems have been reported with VBA, meaning scripts can lock up for no apparent reason and without warning. Until it's fixed, software companies like Citect remain wary. Larry Keefe, marketing manager for Citect, Charlotte, N.C., says Citect OEMs can still link to ActiveX, COM and VBA software without using VBA scripts. "For absolute process integrity, we prefer to use our own scripting language or Visual Basic to link software packages, especially in control applications," he says.
Wonderware, Irvine, Calif., will join the VBA party soon. "Wonderware does not offer VBA, but this is not due to any problems with VBA," says Carl Henning, director of FactorySuite marketing at Wonderware. "In fact, we will be embedding VBA in a future release."
In defense of VBA problems, Agrusa says Iconics has not seen any looping problems. "But VBA is a programming language, and the current VBA v. 5.0 supports only single threading, so it's possible to write a script that could lock up in a tight loop," he says. "Version 6.0 of VBA will support multithreading, so this should cure loop lockup problems."
Microsoft released v. 6.0 of VBA on April 28,  and it has multithreading. It also has support for COM add-ins (from Windows 2000), digital signature support (to identify the source of VBA code), encryption and more development features. Tim Davis, vice president of marketing for USDATA, Richardson, Texas, says they have already added v. 6.0's multithreading capability to USDATA's Xfactory software.