Specifications

RSLinx – Training Guide B - 17
Figure 2-6 - Typical OPC Architecture
Local vs. Remote Servers
It is expected that OPC Server vendors will take one of two approaches to networking:
1. They can indicate that the client should always connect to a local server which
makes use of an existing proprietary network scheme. This approach will
commonly be used by vendors who are adding OPC capability to an existing
distributed product.
2. They can indicate the client should connect to the desired server on the target node
and make use of DCOM™ to provide networking. For this reason all of the
RPC_E_* error codes should also be considered as possible returns from the
functions below.
OPC Server Browser
The Interface of the OPC Server Browser (IOPCServerList) is specified as part of the
OPCCommon document.
Overview of the Problem
The issue is, "How does a client program show the user what OPC Servers are available on
a particular machine?". OPC Servers now register with the system via Component
Categories. This allows the Microsoft ICatInformation (IID_ICatInformation) Interface on
the StdComponentCatagoriesMgr (CLSID_StdComponentCategoriesMgr) to be used to
determine which OPC servers are installed on the local machine. The problem is that this
does not work for remote machines because the Component Categories Manager is a DLL
and the ICatInformation interface only works in-process. As a result there is no easy way
for a Client (including the Foundation supplied Automation Wrappers) to obtain a list of
OPC Servers installed on a remote machine.
OPC Automation
Interface
OPC Custom Interface
Local or Remote
OPC Server
(Shared by many clients)
Server Data Cache
Physical
Device/
Data
OPC
Automation
VB
Application
C++
Application