What Is OPC? - OPC Client ActiveX, Visual Basic and OPC Server Development

"Our customer no longer has downtime issues thanks to your OPC software. Data Layers will always be the first place I'll look when I have a requirement to connect software to a device or process."

Donal Moynihan, CTO of Crest Solutions, a vision sytems and software company specializing in the regulated industries, Ireland.

What does this mean to you?

OPC - from a pipe dream to an industry standard

With OPCWare Client Developer, you can quickly and easily develop applications and you don't have to learn or understand the underlying OPC technology.

You may just be curious, or perhaps the applications you are working on may require an understanding of OPC. That is why we have included this note. So what is OPC? OPC stands for Object Linking and Embedding (OLE) for Process Control. OPC is a worldwide standard of application interface in industrial automation software and the enterprise systems that support industry.

The OPC specification is a non-proprietary technical specification that defines a set of standard interfaces based upon Microsoft's OLE/COM technology. The application of the OPC standard interface makes possible interoperability between automation/control applications, field systems/devices and business/office applications. Traditionally, each software or application developer was required to write a custom interface, or server/driver, to exchange data with hardware field devices. OPC eliminates this requirement by defining a common, high performance interface that allows this work to be done once, and then easily reused by HMI, SCADA, control and custom applications.

A typical OPC configuration consists of OPC servers and OPC clients. An OPC Server is a software application which provides industrial real-time data from PLCs, DCSs, and other control devices to HMIs and other OPC clients. An OPCWare™ Modbus OPC Server is an example of an OPC server. An OPC client such as an application created with OPCWare Client Developer is an OPC data consumer. It is typically a visualization or database application which present or uses the OPC data provided by OPC servers. With the use of OPCWare Client Developer you can easily enhance any non-OPC application to become an OPC client and connect it to a broad family of existing OPC servers.

OPC is open connectivity via open standards. These standards fill a need in automation like printer drivers did for Windows. OPC provides connectivity in industrial automation and the enterprise systems that support industry. Interoperability is assured through the creation and maintenance of open standards specifications. There are currently seven standards specifications completed or in development. OPC is defined on the website of the OPC Foundation, including these seven standards specifications.

Based on the fundamental standards and technology of the general computing market, the OPC Foundation adapts and creates specifications that fill industry-specific needs. OPC will continue to create new standards as needs arise and to adapt existing standards to utilize new technology.

OPC is a series of standards specifications. The first standard (originally called simply the OPC Specification and now called the Data Access Specification) resulted from the collaboration of a number of leading worldwide automation suppliers working in cooperation with Microsoft. Originally based on Microsoft's OLE COM (component object model) and DCOM (distributed component object model) technologies, the specification defined a standard set of objects, interfaces and methods for use in process control and manufacturing automation applications to facilitate interoperability. The COM/DCOM technologies provided the framework for software products to be developed. There are now hundreds of OPC Data Access servers and clients.

One well known analogy for the original Data Access Specification is printer drivers in DOS and then in Windows. Under DOS the developer of each application had to also write a printer driver for every printer. So AutoCAD wrote the AutoCAD application and the printer drivers. And WordPerfect wrote the WordPerfect application and the printer drivers. They had to write a separate printer driver for every printer they wanted to support: one for an Epson FX-80 and one for the H-P LaserJet, and on and on. In the industrial automation world, Intellution wrote their Human Machine Interface (HMI) software and a proprietary driver to each industrial device (including every PLC brand). Rockwell wrote their HMI and a proprietary driver to each industrial device (including every PLC brand, not just their own).

Windows solved the printer driver problem by incorporating printer supportinto the operating system. Now one printer driver served all the applications! And these were printer drivers that the printer manufacturer wrote (not the application developer). Windows provided the infrastructure to allow the industrial device driver's solution as well. Adding the OPC specification to Microsoft's OLE technology in Windows allowed standardization. Now the industrial devices' manufacturers could write the OPC DA servers and the software (like HMIs) could become OPC clients.

OPC cuts costs for vendors and end users alike

The resulting benefit to the software suppliers is the ability to reduce their expenditures for connectivity and focus them on the core features of the software. For the users, the benefit is flexibility. They can now choose software suppliers based on features other than "Do they have the driver to my unique device?" It is not necessary to create a custom interface and bear the full cost of creating and upgrading through operating system or device vendor changes. Users are also assured of better quality connectivity as the OPC DA Specification codified the connection mechanism and compliance testing. OPC interface products are built once and reused many times; hence, they undergo continuous quality control and improvement.

The user's project cycle is shorter using standardized software components. And their cost is lower. These benefits are real and tangible. Because the OPC standards are based in turn upon computer industry standards, technical reliability is assured.

OPC client with free automation wrapper or custom interface

MYTH: Anyone who can write a Visual Basic "Hello World" application, is proficient enough to use the OPC Data Access automation wrapper with VB. Wrong!

Before the existence of OPCWare Client Developer, many developers tried using the freely available Automation wrapper DLL (typically called OPCDAAuto.dll) to OPC-enable applications written in Visual Basic or other compatible languages, but generally didn't get far. When people say "oh you can write your own OPC client with VB" this is like saying you can write your own OLE database connectivity drivers. Just because it is possible doesn't mean it's always a good idea.

Realizing they weren't getting far with the automation wrapper, many people looked for ActiveX solutions and found lightweight components, many of which are available for free, and some of which are sold as commercial products but are little more than the automation wrapper in disguise. There are also ActiveX toolkits available that claim to make things easy for VB programmers but most fail to do so. People trying to use these ActiveX components found they were limited, and went back to the automation wrapper, because it didn't constrain them in the same way. Thus a common impression is that ActiveX OPC client components are not really worth bothering with, and are of little or no value. This is the logical conclusion and is not surprising given the poor quality of most of them.

We found ourselves in the same situation about four years ago. Frustrated by the amount of code required just to get the automation wrapper to do anything more than a simple read or write, we looked for ActiveX components. We found many, some for free, and some were not free. Some looked like they were slapped together in an hour. Some of the commercial components from well known OPC vendors did a good job of doing one or two things well, such as OPC data binding in VB6, so there was hope. The vendor marketing materials were impressive, help documentation looked good, snazzy looking samples with flashing graphics etc. We call these generic OPC ActiveX controls. But when we looked a little closer we found these components actually fell short of the mark. In every case, we could not get these ActiveX components to do what we needed to do because the range of functionality available in any one was too limited. No vendor was providing a complete OPC client developer's rapid productivity solution. So we decided to develop our own. After our first few successful installations, we shared our components with others, and urged on by the positive feedback we were getting, we launched the first commercially available version of OPCWare early in 2002. The rest as they say is history.

But the story doesn't end there. Many readers have arrived onto this page because they were looking for information about how to use the automation wrapper DLL. OPC server vendors supply this wrapper file (sometimes with and sometimes without a demo application in VB6 to help get started), but then they leave it up to the developer. You may be in that position now, but don't despair. Or you may be looking for an up to date build of the automation wrapper, because the one you have has a peculiar bug such as a memory leak. Even if you can pinpoint the bug, there is no support, nowhere you can turn to get it fixed, because you got it for free. Sounds familiar?

Even if you could have a DLL without bugs, going down this route becomes very cumbersome once dealing with anything other than a simple, single OPC server configuration with just a few I/O points. As the number of I/O increases, the application becomes more and more difficult to maintain, with several lines of code involved in reading an item, several more lines involved in writing an item and still more code involved in managing the configuration.

Furthermore, the automation wrapper (or custom interfaces for that matter) is either totally unusable or almost useless when you need to read and write any significant amount of OPC data with ASP pages, scripting languages such as VBScript, or with VBA-enabled software tools such as Microsoft Excel.

For those who persist, by the time a development project is finished, the developer (or the finance department) might no longer see this exercise as having been free, considering all the time spent just to get that far, and still producing nothing reusable for the next application, and still being stuck with a never ending maintenance nightmare of debugging and software patches. In most cases, it will cost almost as much again for the next application, and again, and again.

This doesn't take into account things like deployment to end users. What about distribution of runtime dependency files, DCOM configuration, coping with unexpected user and software component behaviours? Left to their own devices and without any support, many developers have struggled for days and weeks with these and other issues.

You are probably thinking "I thought OPC was supposed to solve everyone's device, process and software interconnectivity problems, not make them worse. This shouldn't have to be the case, there must be an easier way". Well you are right...read on to find out how you can use the power of OPC to interconnect your PLCs, databases, spreadsheets, web pages and lots more...

The value of a component-based OPC productivity toolkit

High quality, commercial, productivity-orientated, reusable software components is the way to slash development cycles and eliminate continuous maintenance and troubleshooting, reducing total cost of ownership for automation software. Industry studies conducted by the META Group suggest that reused code shows a 75% reduction in defects compared with new code, and reusable components enable the final product to be delivered 40% faster (Source: An article by ComponentSource, the world's leading online software component reseller).

That's where OPCWare Client Developer comes in. Many of our customers have reported development cost and time savings in the region of 95%. Total cost of ownership for the software is also dramatically reduced. Production-grade, functionality-rich end user applications can be produced rapidly by experienced developers or even by relatively inexperienced developers.

"Our product is Linux based and we previously spent a large amount of $$$$ to have a consultant develop a client for Linux. This 'client' did not allow server browsing and all configuration was via .ini files which had to be manually created. In addition, I spent two months integrating this into our existing product. The licensing fees alone were more than the original purchase price of OPCWare Client Developer professional and were per installation computer.

An alternative was required, so I spent a week evaluating several Windows controls and found OPCWare to be the easiest to use and the support was almost immediate when I had a question. In total it took me three days from start to finish to integrate the OPCWareX control into our product. The cost of adding a Windows PC to our customer's facility is more than offset by the unlimited runtime licensing your product allows. OPCWare helped make me look like a genius to our company and will be my first stop for any further OPC development we require. Thanks guys"

Chris Bowen, Senior Software Engineer with Syscon International, a leading real time plant information software manufacturer, USA.

Typically, there is no requirement for any real understanding of the underlying OPC technology when using OPCWare Client Developer. To see it in action for yourself, download your free 30-day evaluation copy of OPCWare Client Developer.

Of course, when using a language other than VB6, it is difficult to find examples (or support) for the automation wrapper. With VC++ or Delphi the custom interface can be used, again examples are available elsewhere. However, even with these languages, it is still necessary to write considerable amounts of code just to be able to read and write a few I/O points, so the value of using OPCWare Client Developer becomes apparent again.

Apart from VB, VC++ or Delphi, it is hard to locate any examples that use either the automation wrapper or custom interface to write OPC client applications. Environments such as PowerBuilder, Matlab, and other ActiveX containers not typically associated with HMI applications spring to mind. These environments are ActiveX containers and can be used to leverage the value of component reusability, but they are not the target market of most OPC server vendors so little or no OPC client support is available for those environments. These are just some of the various scenarios where the benefits of OPCWare Client Developer are really pronounced and apparent.

100% Pure Visual Basic OPC Client - VB Custom Interface Toolkit

We have released the source code for our 100% pure Visual Basic OPC Data Access 2.0 Client application. This application does not use an automation wrapper or any other intermediate wrapper files. It is the first ever pure custom interface implemented in Visual Basic 6 that we are aware of, and is something which is impossible to achieve according to the OPC Specification. Now you can have access to the power of the OPC custom interfaces from Visual Basic. You can get the source code and use it to produce your own powerful OPC Client applications.

Yes, we are aware that there are plenty of samples with full source code available for free that show you how to use VB for writing your OPC client applications, but all of these use the OPC automation wrapper, and are thus based on the automation interface. With these applications, it is necessary to distribute an automation wrapper DLL with your VB application. This file may be called OPCDAAuto.DLL, but many vendors have shipped their own versions with different names. If you check your VB project's references, you will see a reference to OPC Automation, and this is how you know you are using the automation wrapper.

But the OPC DA automation interface is not the same as the OPC DA custom interface. The automation interface was designed to be compatible with scripting languages such as VBScript, and so trade-offs were made. For example, you are limited to using automation-compatible data types, such as the Date type which is familiar to VB6 programmers and gives the date and time with precision to the nearest second. The OPC DA custom interface is not accessible to scripting languages and involves passing parameters containing non automation-compatible data types such as a FileTime structure which gives the timestamp to millisecond precision.

There are several other key differences and advantages over the automation interface, the most obvious being better performance, and perhaps less obvious but just as important is the ability to directly manipulate other interfaces that are implemented by the OPC server such as the OPC security interface. However to use the OPC custom interface has traditionally required using a development language with the ability to handle pointers and to pass non automation-compatible data types as parameters, neither of which VB does. Delphi and C++ do. Samples of OPC client applications with full source code using the OPC custom interface are widely available, and these are written in languages such as VC++ and Delphi. What is unique about VB4OPC™ our VB Custom Interface Toolkit is that it shows you how to handle the OPC custom interface (using pointers and passing non automation-compatible data type as parameters), and all of this is done within VB6. The VB4OPC™ toolkit also shows how you can browse for local or remote OPC DA servers using OPCEnum.exe directly from within a Visual Basic program.

Right now, you can download the 100% Pure VB OPC Client compiled application, and see it for yourself. The download is just an executable file, and there are no other dependencies apart from the standard OPC core components which will be installed with any OPC server. It is literally plug and play. At this time, no documentation is provided with the executable. The comments in the source code explain exactly how this has been achieved. If you want to purchase the VB6 source code for this application, send an email to OPCWare Sales.

OPCWare Client Developer OPC ActiveX Controls - Overview

If the pure custom interface is not productive enough for you, you can take the rapid development route with OPCWare Client Developer, our ActiveX toolkit which offers an alternative OPC interface. OPCWare Client Developer is a suite of ActiveX Controls for Rapid OPC (OLE for Process Control) Data Access Client Development. The OPCWare Client Developer ActiveX control suite includes four controls that are used to browse and connect to OPC servers, and to bind the OPC data to user controls. Each OPCWare Client Developer component is an in-process ActiveX Server component. OPCWare Client Developer brings the power and flexibility of the OPC Data Access 2.0 Automation Interface to automation clients, without the need to learn or use the OPC automation object model, and without dealing directly with COM objects, collections or handles!

This suite of ActiveX components enables simple and complex reading and writing of OPC data between PLCs and HMI applications, databases, spreadsheets, etc. The software works with any devices or PLCs such as Allen Bradley, GE Fanuc, Omron, Siemens, Modicom or Applicom PLCs, TCP/IP devices, Modbus/TCP devices, and generally anything with serial connections via RS232 or RS485. The device or PLC must be connected to an OPC DA 1 or 2 compliant OPC server such as Kepware, Matrikon or Iconics. Note that we can assist and advise in the selection and configuration of a suitable OPC server, or we can develop one for you if none is available.

Our OPCWareGroup control allows you to set up your application to automatically read I/O from your OPC server without looking at or writing a single line of code! You can write to one or more or I/O points simultaneously using a single line of code, referring to the I/O points by their ItemIDS or by their sequential numbers within the OPCWareGroup control (their index, similar to the index of a control array in VB6). So for simplicity, this beats the automation wrapper by a long shot.

For more demanding applications, the OPCWareX component provides an explorer view (similar to Windows Explorer) of your OPC configuration. This powerful control has the ability to manage complex OPC configurations involving an unlimited number of I/O points on an unlimited number of OPC servers. Full programmability is available through the set of methods, properties and events provided with the control.

Both OPCWareX and OPCWareGroup are supplemented by our OPCWareServerExplorer and OPCWareItemExplorer controls to save you ever writing any code to perform those functions when you need to enable your end-users to dynamically change your OPC configurations at runtime.

Features and benefits of OPCWare Client Developer include:

*Binding functionality is only available in VB5 and VB6. Certain events that pass array parameters do not work with VC++. VC++ users will need to use alternate events and methods which are also provided.

The OPCWare Client Developer installation package (which you can download and evaluate for 30 days for free) includes extensive Visual Basic source code examples for simple and advanced applications. Beginner, intermediate and expert VB programmers alike can now quickly and easily leverage the power and flexibility of the OPC interfaces. OPCWare Client Developer has been designed for and fully tested with Windows NT and Windows 2000, but is also compatible with Windows XP, and Windows 2003 Server. The software is expected to work with Windows 98/ME, although we have not tested it and do not normally support it. Support for OPCWare Client Developer with Windows 98 and Windows Millenium Edition is available on request.

In addition to their value as development aids, the Visual Basic source code examples included with OPCWare Client Developer can also be used as OPC Test Clients so multiple OPC servers can simultaneously be configured and debugged.

OPC Client Software, OPC Server Development, OLE for Process Control, Visual Basic, ActiveX, COM, Visual C++, Visual Studio.NET, Visual Basic.NET & Visual C#.NET, Databases & SQL, Real-Time Graphics, Windows NT/2000 Security, Active Directory Services, Human Machine Interface (HMI), Supervisory Control and Data Acquisition (SCADA), Programmable Logic Controllers (PLC), Automation - OEM, New, Refrofit, Commissioning, Validation, Good Automated Manufacturing Practice (GAMP), 21 CFR Part 11 (21CFR11) - Electronic Records and Signatures, Project Management, Feasibility Studies, Cost/Benefit Analyses, Independent Review

Note: Some or all of the terms Microsoft, Windows, Visual Basic, ActiveX, OPC may be trademarks of their respective owners.