Experimental Physics and
Industrial Control System

[email protected] (Kay Kasemir) · Mon, 19 Jun 2000 09:59:18 -0600

At 08:42 AM 6/19/00 -0400, Coles Sibley wrote:
>Has anyone interfaced an OPC system with EPICS?
>
>Coles
> 

Matthias alreasy wrote:
>We have written an OPC Server for CA and Kay Kasemir has written the
>OPC-Client / CA-Server part.

OPC is based on COM (WIN32 RPC for objects).
OPC defines a set of "interfaces" that you are asked to implement
(http://www.opcfoundation.org).

The good news: If it works, it is very easy to use.
Buy an OPC compliant gadget, install it's OPC server,
start the OPC client/CA server and you can now
monitor the values of your gadget via Channel Access.
You also don't need a specific driver for LabVIEW,
Intellution, Wonderware, ...
The single OPC server replaces all those.

Details you should consider as far as I know/see it:

Both the CA client/OPC server and the OPC client/CA server
are not implementing those COM interfaces themselves,
instead they are using libraries from Softing, http://www.softing.com
(See later why this makes sense).
Point: You can get the binaries.
Since this is new technology, you might want to have the sources
in case you have to do debugging. You can also get the sources, 
but those are useless unless you buy the softing OPC client/server SDK
which is necessary for (re-)building the stuff.

A problem with COM interfaces:
Many interfaces are defined by Microsoft.
Example: "ActiveX Automation Server".
We wrote an "ActiveX Automation Server" that is a CA server.
It worked with MS Excel, Visual Basic, ...
LabVIEW 5.1 sais that it can use "ActiveX Automation Servers".
However, it looks like MS didn't clearly specify what's necessary
to be a fully compliant "AXAS", so I had to add additional
interfaces and then NationalInstruments patched their code
to make this communication really work.

With OPC you would hope this does not happen because it is an open project,
all the interfaces are published and well defined.
Almost: There was an interface IOPCAsyncIO.
Then they noticed that something's missing,
so there is now also an IOPCAsyncIO2.
The softing library is nice because it tries to figure out
what the peer can handle and then uses the most recent interfaces.

Point:	There are "OPC compliant" apps that cannot talk to each other
because they implemented a different part of the OPC specs.

OPC is based on COM. Then there is DCOM, the distributed version.
The idea is to make remote communication look like local communication.
This does not work, of course, because over the network there can
be delays or disconnects.
As a consequence, the channel access API is full of methods and means to handle this,
get notification on disconnects etc.
There just cannot be a transparent wrapper that makes remote communication
look like local calls.
Consequently I would try to avoid using OPC over DCOM
because your application cannot really handle disconnects and delays,
instead you experience hangups.

I would conclude that this is an interesting technology well worth
exploring. It can also provide a tremendeous speed increase for test
setups, but we have to see how reliable it is for production systems.

-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System