Click for Printer Friendly Version
This document further explains how the ConnectName and
ConnectObject methods of the OPC ActiveX Data Control (www.opcactivex.com)
work with Subscriptions. This document is in addition to our "When
to use Sync Reads and Subscription Reads" which we advise
you to read before this document.
ConnectName and ConnectObject are two similar methods.
While this document is not designed to replace the Help documentation
provided with the OPC ActiveX Data Control - it is designed to "paint a bigger
picture" as to how these methods work. The intention here being with
this "extra" information you will be able to better plan, develop and
deploy your OPC application.
Terminology
Used
In this document, you will read
about Synchronous (sync) and Subscription communications methods. In the
OPC ActiveX Data Control these different communications methods are used by the
following methods on the OPC ActiveX Data Control:
| Sync |
Subscription |
| ReadVariable |
ConnectName |
| ReadMultiVariable |
ConnectObject |
| WriteVariable |
|
| WriteMultiVariable |
|
Please read the "When
to use Sync Reads and Subscription Reads" document for
detailed explanation of these different types.
Firstly, Dispel the Misconception
Both the ConnectName and ConnectObject methods require
the same parameters. One parameter that is the root-cause of the most
common misconception is the "update rate".
The confusion lies in "where" this update is occurring... let's take a
look at a diagram to get a picture of the system:
From the diagram we can see the client-server
relationship
and the PLC-server relationship. We know that a subscription means that a
given Tag is going to be read on a frequent basis, i.e. every 50ms. The
question is, "where" is this 50ms update occurring?
The misconception is shown
here - this is NOT HOW THE SYSTEM WORKS:
The truth is, this is not where the update occurs. When an
OPC Client subscribes to the Tag, we have to remember the Client-Server
relationship. Remember the Server "does all the work". When subscribing to
a Tag every 50ms for example, then you are telling the OPC Server to
check that PLC address every 50ms.
How does the subscription work?
Firstly, the OPC Server is checking the PLC Device every 50ms (for
example) for a value change. Let's see the correct diagram now:
Take a moment to think about this picture....
The Server
is checking the PLC Address every 50ms. What if that value doesn't change
for a long time? that would be an awful waste of resources and bandwidth
if the OPC Server was to give those values back to the OPC Client every
time. Thankfully, this is not how it works!
The server is checking the Tag for a value change, this is
it's job. When it detects that a value has changed, the server then
"pushes" that value onto the subscribing OPC client.
|
This way, the OPC Client only receives the data when the
value changes. This is a large saving of both processing time
and bandwidth - two valuable commodities.
An Example Subscription Scenario
Let's say that you are monitoring the temperature of a Freezer.
You want an update every 50ms. The value of the Freezer
remains constant for weeks upon weeks before it fluctuates by
a half a degree. At this point, the Server sees the change in
Value and then pushes the value onto the client.
During this period of time where the value did not change, there
was no update from the OPC Server to the OPC Client.
At this point, you are probably wondering how & when you
are notified if the OPC Server or PLC Device go offline...
this will be discussed shortly... |
|
|
Analogy
You are in a restaurant, you are the customer (OPC
client) and the waiter is the person who takes your order
and fetches your food (OPC Server).
When you place your order, the waiter takes your
order back to the kitchen-staff who prepare your food.
Question: do you go to the kitchen every minute to
see if your meal is ready?
The waiter goes back to the kitchen periodically to
see if your meal is ready. If the meal is ready, the
waiter brings the food back to
you. |
|
What is a Call-back and How does it work?
Simply put, a Call-back is when a "Client-based component" makes a
"subscription" to a "Server-based component". The server-based component
maintains a list of subscribed components. In our case, let's call these
components by what they are, i.e. An OPC Client and an OPC Server:
When the values in the server-based component (those subscribed to by
the client) change, it is the responsibility of the Server to "push" this
data onto the client.
Let's step back a second... on the Client and on the Server are the COM
based objects (OPC Server and OPC Client). An object has methods. In OPC,
these methods are used to read and write to Tags, to subscribe to Tags and
for updating Values. There are many other methods too, but those are
irrelevant in this document.
Traditionally, the client makes calls to the server by directly calling
the methods in the Server object. In order to do this, a connection has to
be established first (between the client and the server). During this
connection, the security permissions will be checked to make sure that
only "authorized" users have access:
|
this applies to both Synchronous (readVariable etc.) and
Asynchronous (connectName etc.) method calls
|
The client also has methods within it. When a value changes in the
server, the Server makes a method-call on the client and passes the data
value in as a parameter. Upon this method call, the "ValueChanged"
event fires on the client. The client now knows that a data change has
occurred and has the value, quality code and timestamp. Before this
method-call can be made, a connection has to be established and again, the
Client is secure in that it too will only allow authorized users access:
|
used by a callback with a subscription. i.e. ConnectName or ConnectObject
methods
|
What do I need to do?
Just as Files have NTFS security permissions, COM based objects do too!
Therefore you have to configure the security permissions to allow the
objects to interact with each other. Each object is defined with a
"Windows NT User Account" or the "System Account". It is these accounts
that require the permissions to be set.
If your OPC Server and OPC Client are on different computers, then you
have to give each computer access to the other:
- Client can access the Server (in order to read/write to Tags and
subscribe etc.)
- Server can access the Client to push the data back when the data
changes
Full step-by-step instructions for configuring your DCOM settings are
available here.
Possible Situation:
Let's assume that the OPC Server has been configured to permit the OPC
Client (on a different computer) to allow access to it's OPC Server COM
object. The OPC Client is able to do Sync reads and Sync writes to the OPC
Server with success. Why? because the OPC Client is calling methods on the
OPC Server (and passing parameters) and retrieving the value within the
method.
Now the OPC Client wants to subscribe to Tags within the OPC Server.
The client makes the various method calls on the OPC Server and
successfully establishes a Subscription. The OPC Server now begins polling
the PLC for the tag value. Upon reading the PLC Value for the first time
which counts as a "value change" the Server then attempts to Push this
data back to the client. At this point the client will not receive any
values. Why? because the server has not been given permission to access
the COM object on the client.
Potential Issues
By now you are probably asking how to notify your application when the
OPC Server goes offline, or when the PLC Device itself goes offline. These
are two very good questions that have to be addressed.
If you are using the TOPServer (http://www.toolboxopc.com/) then you
have many features at your disposal for easier handling of this type of
situation. One method allows you to simply subscribe to the
"<channel>.<device>._system._error" tag. This is a
boolean tag:
- 0 = no errors; the PLC communications indicate the PLC is online
and available
- 1 = error; PLC cannot be contacted and appears to be offline
Other solutions are available using the TOPServer's unique
features. Please refer to the TOPServer dedicated website for a list of these
features at www.toolboxopc.com.
If
you are not a TOPServer user, then you may wish to consider the following
options:
- convert your asynchronous subscription reads to Sync reads only
[applies to a very small number of projects and will have
performance drawbacks]
- do a Sync read to one Tag every 5 seconds or so... [preferred]
Option #2 requires the least amount of work
and will offer the best performance. You can leave your program
to continue using the Asynchronous Subscriptions reads. In addition to
this, you will do a manual Synchronous read to a single tag using the
READVARIABLE method. Click here
for an example of how to use this method.
The ReadVariable method uses a return-code to tell you the
result of this method call. If an error occurs, you will be notified so by
this return code. A return code of 0 (zero) means that no errors occurred
and the method was successfully actioned. Using this information, you
could write a VB routine to simply:
|
Dim lngResult,
returnQuality As Long
Dim
returnValue As
Variant
lngResult = opcData1.readVariable("myTag",
returnValue, returnQuality, 0)
If
(lngResult <> 0) Or (returnQuality
<> 192) Then
'something is
wrong, do something
End If
|
Options available to you include (but are not limited to):
- disabling the ActiveX control (.Active property = False) and then
wait for an amount of time before re-enabling.
- disabling the subscribed tags and continue polling the device with
the Sync reads until a good result occurs
... either way, you should periodically try reconnecting to the device
until you make a good connection.
In Summary
As we have seen in this document, the OPC Client and OPC Server are
both COM objects. COM objects are secure in that only authorized users can
access them and that both the OPC Client and OPC Server are run as NT
Users. In order to achieve a full client-server relationship between the
OPC Client and OPC Server, then both COM objects (on all computers) must
be configured accordingly.
Both the ConnectName and ConnectObject methods subscribe to Tags in the
OPC Server. The server's job is to periodically retrieve the latest value
of a Tag every xx ms. When a value has changed, the server "pushes" the
updated value to the client.
Subscriptions only work when both the Client and Server have access to
each other.
