OPC (OLE for Process Control) is an interface specification for data communications that is popular in industrial environments. It is faster than DDE, and has more features, but its complex programming requirements and specialized use mean that it is not usually supported by non-industrial software.
OPC connections are always client-server. Setting up the Cascade DataHub to use OPC is simply a matter of configuring it to act as a client or as a server. If acting as a client, it will automatically attempt to find or start the OPC server that has been configured, and then start receiving data. If acting as a server, it will automatically respond to requests from any OPC client on the system.
The OPC protocol uses the concept of an item as a way to structure data. Every item has 6 required properties: Value, Timestamp, Quality, Access Rights, Scan Rate, and Canonical Type. As users of the data, we are mostly interested in Value, Timestamp, and Quality. Items can also have up to 30 optional properties, such as Description, Engineering Units, High, Low, Alarm Level, and so on. For example, an item might represent a temperature reading on a tank like this:
|Timestamp||Apr 27 16:27:24.300|
|Description||Temperature of Tank A|
The OPC DataHub maintains an item and all of its optional properties as separate data points. The item's 6 required properties are maintained internally, but the DataHub displays the information corresponding to the Value, Timestamp, and Quality in the Data Browser under the columns Value, Date and Quality.
This relatively simple picture becomes more complex when we learn that the OPC specification allows a property to be an item in its own right. This implies, in turn, that properties can have properties. Some OPC servers implement properties as items, and some do not. Normally when an OPC server does treat properties as items, those items have only the 6 required properties and you don't get an infinite recursion.
This has implications for configuring the OPC DataHub and working with data sets. If an OPC server implements properties as items, the DataHub could potentially have access to many more data points than for an OPC server whose items are not properties. For this reason, the OPC DataHub makes it optional to pick up all items that are properties.
It also affects the results of a filtered connection to an OPC server. Filters set up in the OPC DataHub are based on items. If your OPC server implements properties as items, and if you choose to pick up all items that are properties, any filter you run apply to those items as well.
DDE (Dynamic Data Exchange) is a well-established mechanism for exchanging data among processes in MS-Windows. There are three DDE commands for establishing communication with Windows programs such as Excel. Which of these commands you use depends on how you plan to control the flow of data between the spreadsheet and the OPC DataHub.
DDEPoke writes a data value to the OPC DataHub. For example, to send a value from an Excel spreadsheet to the DataHub, the DDEPoke command is run from within an Excel macro. For more details, please refer to Section 9.2.2, “Method 2 - Writing Excel macros that use the DDEPoke command”.
DDERequest reads a data value from the OPC DataHub. To get that value into Excel, for example, the DDERequest command is run from within an Excel macro. For more details, please refer to Section 9.1.2, “Method 2 - Excel Macros using DDERequest”.
DDEAdvise creates a connection, called an advise loop, that updates a new data value automatically. The advise loop is a unidirectional link, established by a client program that wants to receive data from a server program. The client continues to receive new point values as long as the two programs are running, or until the advise loop is terminated.
You can use DDEAdvise to read data from the OPC DataHub by configuring the DataHub to act as a DDE Server. For an example using Excel, please refer to Section 9.1.1, “Method 1 - Drag and Drop using DDEAdvise”.
Likewise, you can use DDEAdvise to write data to the OPC DataHub, by configuring it to act as a DDE Client. For an example using Excel, please refer to Section 9.2.1, “Method 1 - Configuring DDEAdvise loops in the OPC DataHub”.
For more information on DDE, please refer to Appendix G, DDE Overview.
The OPC DataHub uses TCP to communicate over a LAN, WAN, or the Internet. You can join two or more OPC DataHubs together over TCP and share exact copies of the data through data tunnelling. Tunnelling means that the data and any updates to that data on one DataHub are exactly tunnelled across the network onto any other DataHub that is connected. Once a tunnelling connection is established each participant maintains and updates an identical data set, as simultaneously as the TCP connection will permit. For more information on tunnelling, please refer to Section 19.3, “Tunnel/Mirror”.
The DataHub APIs for C++, Java, and .NET lets any TCP-enabled program interface with the DataHub.
Copyright © 1995-2010 by Cogent Real-Time Systems, Inc. All rights reserved.