 |
 |
 |
 |
 |
 |
|
How the OPC Data Control uses OPCEnum.exe Introduction This document compliments our DCOM Configuration tutorial by providing additional detail about how the OPC ActiveX Data control browses for available OPC servers on local and remote computers. Who should read this? This document should be read by the following people:
Pre-requisites The following assumptions been made: About The Reader
About The Software
How OPC Works in conjunction with COM to identify unique OPC Servers OPC Servers are COM components, more specifically they are COM servers. COM components each have their own unique identification in the form of a Globally Unique Identifier (GUID), an example of which is shown below: {6E617103-FF2D-11D2-8087-00105AA8F840} Every unique OPC server application has a GUID that is unique to that server. A quick note on terminology. You will also see the terms CLSID and AppID. These are merely "uses" of the GUID. A CLSID is a "Class ID" and is a GUID used to uniquely identify a component or class. An AppID is an "Application ID" and is a GUID used to uniquely identify a software application. For the purposes of this discussion and in high level OPC server discussions, you can use the terms GUID, CLSID, and AppID interchangeably to refer to the unique identifying string like the one above for a particular OPC server. Usually you can find out the GUID for a server from the OPC server vendor. With the OPC ActiveX Data Control's Browse Demo that is installed with the product, you can inspect any properly installed OPC server on your computer and obtain the GUID. The above GUID is for the Software Toolbox TOP server OPC server. Not too friendly looking is it? not to panic, because COM components can also have a "human-friendly" name too which is called the Program Identifier (ProgID). The ProgID that corresponds to the GUID above is: SWToolbox.TOPServer All COM components are registered in the Windows NT/2000 Registry in several places specified by Microsoft. All OPC Servers make a standard set of registry entries specified by the OPC Data Access Specification. If an OPC Client wants to find OPC Servers, then a search through the Windows NT/2000 Registry must be made. Let's see this in an example: Situation: Browsing for a list of OPC Servers on the local computer (using OPC Data Access 1.0 method) When browsing for a list of OPC Servers, the following would happen: Access the Windows NT/2000 Registry Search through the Windows NT/2000 Registry for all OPC Servers - in OPC DA 1.0 all OPC servers made an entry under their GUID List the OPC Servers in your application As you could imagine, searching through the entire Windows NT/2000 Registry would not be a fast operation and could take several minutes to complete. In the OPC Data Access 1.0 Specification, this is how the list of available OPC servers on a target machine was obtained. Starting with the OPC Data Access 2.0 specification, an improvement was made. On Windows operating systems there is a tool called the Component Category Manager. This tool provides a way to organize COM objects in the registry by category to allow for quicker retrieval. Each unique category name in the Component Category Manager has a unique GUID associated with it. Starting with the OPC Data Access 2.0 specification, GUIDs were assigned for 2 categories: OPC Data Access 1.0 Servers {63D5F430-CFE4-11d1-B2C8-0060083BA1FB} and OPC Data Access 2.0 servers {63D5F432-CFE4-11d1-B2C8-0060083BA1FB}. All OPC servers are required to make registry entries that associate themselves with the appropriate Component Category GUIDs for the OPC Data Access specification(s) they support. An OPC client can query the Component Category Manager for all servers that it has associated with the OPC category GUIDs. This lookup is much faster than a walk through the entire registry. The only problem with this approach is that the Component Category Manager is an In-Process DLL, which from a practical point of view means it can only be accessed by applications running on the LOCAL machine. The solution to this shortcoming in the Component Category Manager is where we introduce OPCENUM.EXE. What is OPCENUM.EXE? OPCENUM.EXE is an executable that is usually found on computers with OPC software; such as OPC Servers or OPC Clients. The purpose of OPCENUM.EXE is to provide an interface into the local machine's Component Category Manager that can be accessed by remote OPC clients over DCOM. OPCEnum.exe provides several useful methods
So, when looking for a list of OPC Servers on the local machine, the following would happen:
Where is OPCEnum.exe on a computer? OPCEnum.exe needs to be installed on each computer that has OPC servers that you wish to access remotely. Most OPC servers install it in \Winnt\System32 and properly register it. The OPC ActiveX Data Control also installs a copy. If you do not have a copy on your remote machine, you can copy one from your local machine and place it into the \Winnt\System32 directory. After you have done this, open up a dos window and type opcenum.exe /regserver and press enter. There is no visual feedback of the success of this step, but it is important to do if you are manually installing OPCenum.exe on a machine. How OPC ActiveX Data Control uses OPCENUM.EXE The OPC Data Control ActiveX uses the OPCENUM.EXE program in a very specific manner. It is imperative for your own understanding that you carefully review this next section if you plan to use the OPC ActiveX Data Control to connect to a remote OPC server and you want to insure robust operation. Hint: The following section outlines the reasons behind the answers to most of the technical enquiries we receive with regards to connecting the OPC Data Control ActiveX to remote OPC Servers. Firstly, the difference between GUID and PROGID Remember the difference between the GUID and PROGID?
Besides the obvious differences between the ProgID and GUID, there is another important non-obvious difference between the two. The GUID is the most "reliable" form of identification you should use. Why? because this is actual ID of the COM object - you can't have a COM object without a GUID that uniquely identifies it. You can have a COM object without a ProgID or friendly name, though if an OPC server didn't have a ProgID, it would most likely not pass the OPC compliance test. Also, there is a performance difference:
"But wait, once i find the OPC server once, i'm done" - not true - many calls between OPC clients and servers include the GUID of the OPC server in the calls. You wouldn't want to have to do a ProgID to CLSID lookup every time you make a call would you if you were writing the guts of an OPC client. Summary: For these reasons we advise and recommend that you use the GUID (aka CLSID/AppID) of your OPC server in your OPC client application code to refer to the OPC server, particularly if the OPC server is on a different computer from the OPC client application. How OPC Data Control works with PROGID and GUID All of this comes into play when you look at how the OPC Data Control ActiveX will work when accessing a local or remote OPC Server. The ability to connect to a remote OPC Server does depend on the security settings you have configured for DCOM (see Dcom Config Tutorial). Having the right GUID or ProgID will do you no good if you don't have your DCOM security settings right. A comparison is shown in the table below when contacting an OPC Server (locally or remotely) and when using the PROGID or the GUID/CLSID.
Final Analysis From this document, you should now understand:
From here, you may wish to review our DCOM Configuration Tutorial which will take you step-by-step configuring the DCOM Settings for both the OPC Server and the OPC Client. Having proper DCOM security settings is a key step towards successful OPC client to remote OPC server connections.
|
|
Copyright Software Toolbox, Inc., 1996-2002, All Rights Reserved Worldwide.
|