cd1212-retro
cd1212-retro
cd1212-retro
cd1212-retro
cd1212-retro

Software Glue

Dec. 11, 2012
Visual Basic for Applications Lets OEMs Connect Control Systems, Specialized Software, and Operator Interfaces Together With Ease
During 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.
About the Author
In 1999, Rich Merritt was technical editor for Control Design.

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.

Figure 1: Development Environment
This VBA script calls an object that will search for the most recent completed batch and display the results.Source: OSI

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.

Figure 2: Calls and Runs
During operation, VBA scripts are called and run, like a subroutine. Some software can call VBA scripts from screen pushbuttons or at specific times of day.Source: GE Fanuc

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 En­gineering, 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
This OI screen for an extruder control system was built from four ActiveX controls. The VBA script that drives the application requires two routines.
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."    

Figure 4: Pick and Place
OI software package toolboxes contain ActiveX functions such as gauges and meters. Source: IconicsTo use the libraries, an OEM must also purchase a Microsoft developer's license for VB5 or 6, for about $500. "For a total investment of $2,250, the OEM has a toolkit that can be used to build just about any kind of HMI, and then they can distribute runtimes royalty free," Weber says. "An OEM who ships 200 machines per year pays only about $11.25 per machine for purchased software."

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.

A Brief History of VBA

Microsoft developed VBA as a way to communicate among its own programs. Bill Gates proposed a software architecture that would replace macros in 1988. It took Microsoft five years to do it. VBA first shipped in 1993, embedded as part of Excel, and now is shipped with all Microsoft Office 97 and Back Office programs. VBA allows the programs to move data effortlessly from one package to another.

When software is VBA-enabled, it means that the developer has obtained a license from Microsoft and has embedded VBA into its product to make it compatible with all other products that have VBA or conform to Microsoft's Component Object Model (COM). To date, nearly 200 software vendors have obtained VBA licenses. Probably hundreds more conform to COM.

COM defines a standard way for software to share information. Although this is somewhat oversimplified, you might think of a COM interface as a big subroutine call. Remember Programming 101? In a GOSUB subroutine call, you passed a list of parameters to a subroutine. The subroutine executed its function and returned an answer. COM objects are just like that, but a bit more complex.   

COM objects are invoked (called) in a VBA script (program). Objects can be as simple as a pushbutton on an OI screen that invokes a VBA script to get information from a database. Objects can also be large containers (entire programs) that have embedded ActiveX or OLE functions.

ActiveX and OLE functions are COM subroutines that perform complex functions, such as real-time I/O or device drivers. They are sometimes purchased from third-party software suppliers.    

COM also supports standard process control industry technology such as OPC (OLE for process control) and Open Database Connectivity (ODBC).   

The major difference between VBA and BASIC's GOSUB calls of 20 years ago is VBA enforces standardization. If any software uses COM and VBA, it is automatically compatible with any other similarly enabled software.

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, [1999] 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.