OPC Q&A

Are subscriptions and asynchronous operations similar?

Both OPC subscription, and OPC asynchronous reads/writes require a callback from the OPC server to the OPC client. In this sense, they are quite similar, and a subscription can be considered a special case of the asynchronous OPC communication.

The asynchronous read/writes, however, are "one-shot" transactions, initiated individually by the OPC client. The subscription is created inside the OPC server by the OPC client just once; since that moment, the OPC server itself takes care of communicating with the device, and reporting changes to the OPC client. The OPC server does this until the OPC client explicitly unsubscribes.

I can browse the OPC server but I am not getting any data values - why?

Assuming that you device is not offline and the server can communicate with it correctly, then, with OPC "Classic", this may be a DCOM configuration problem. Browsing is initiated from the OPC client, whereas subscriptions require callbacks that go in an opposite direction. It is a common mistake to forget about configuring DCOM for an access that goes FROM the OPC Server BACK TO the OPC client.

If your OPC client supports it, try to invoke a synchronous Read, because it has similar execution characteristics as a Browse. If the sync read works, but async Read and subscription update do not, the DCOM is the most likely reason.

Is the OPC server communication with the PLC exception-based?

It depends on the protocol exposed by the PLC.

In many cases, the OPC server willo periodically poll the PLC and read the values. It the compares them with the cached (old) values it already has. If there is a difference (with an optional use of a deadband), the OPC server will send report the change to the OPC client(s). The subscription mechanism between the OPC server and OPC client is always exception-based.

Some smarter protocols support COV (change of value) reporting, and an OPC server for such protocol can take advantage of this, and will not poll unless necessary or required.

Many modern PLCs have an embedded OPC UA server, and then of course there an "internal", very efficient communication between the PLC program and the OPC UA server.

Is there a guarantee that a written value will make it down to the PLC?

The OPC specification has error and success results defined for the Write operation. If the PLC protocol supports a write acknowledgement, the OPC server will interpret it, and when the acknowledgement is negative or is not reeived, it can indicate a problem to the OPC client. Of course, if the protocol does not support a write acknowledgement, such indication is not possible,

It is also a common practice to subscribe to the same item, if it is also readable. A successfull Write will eventually be reflected in the new value of the item, sent by a callback to the OPC client.

Is there a limit on number of items in an OPC group?

The OPC "Classic" specification does not define, and does not expect any aritifical limit (besides the fact that the item count is a 32-bit DWORD). The OPC server may have internal limits given by the resources available. However, the limit should not be expressed in number of items per group, because the OPC client has no way of knowing the limit, and if the client decided to overcome the limitation by creating more OPC groups, the demand on the OPC server would be even higher. If the OPC server must limit the number of items it can handle, it should do so using a limit that is server-wide, or per-client; but not per OPC group.

We have been notified of OPC servers that limit the number of items in an OPC group (such as Yokogawa); there are some, but it is certainly not typical. Such behavior poses a big interoperability issue, because OPC "Classic" does not define a standard way for servers to communicate their operation limits to the clients. This problem is resolved in the new OPC UA specifications.

What is OPC-UA?

OPC-UA means "OPC Unified Architecture". It is a newer set of OPC standards (over the original OPC "Classic" standards, based on Microsoft COM/DCOM).

OPC Unified Architecture is is not tied to Microsoft, and is based on Web services. It combines the various original standards into a common model, and brings in many new features.

What is the "6 Minute DCOM Timeout"?

Distributed Component Object Model (DCOM) calls may take a long time to time out if the network is down, or if the server is unavailable. The actual DCOM timeout depends on a number of factors, including which network protocol DCOM is using and whether the server or network went down before or during the call. In some cases the timeout may be up to 6 minutes. DCOM makes use of RPC, and although RPC does allow some amount of control over call timeout, the programmer cannot normally take advantage of it because DCOM does not give access to the underlying RPC binding handle.

Industrial automation typically requires quicker recognition of a communication problem, and faster remedial actions. Clever OPC clients may overcome DCOM limitations by using special techniques.