OPC Core Components
The OPC Core Components are required for the DCOM server access to work. They are usually installed with OPC server installs. However, often only the 32bit version of the core components.
The 64bit OPC Core Components need to be installed if either the server or a client run in 64bit mode.
The OPC Core Components setup files are included in the OPCDA.NET distribution. See Deployment for details.
.NET OPC DA Interface
The OPC DA specification defines a (D)COM server with an unmanaged code interface. .NET client applications can access OPC DA servers only through a wrapper layer. The required functionality for such a wrapper layer is provided in .NET but it takes quite a bit of code to handle all function calls correctly and convert the data from/to proper .NET data types. This is what the base layer of OPCDA.NET is doing. There is a method for each OPC DA server function, allowing the .Net application complete control.
The OPC DA server access functions are in two classes:
| OpcServer | In the OpcServer class are server management functions. Each client needs an OpcServer object for each OPC server that has to be accessed. A client could have more than one OpcServer objects for a particular OPC server but this doesn't offer much advantages. |
| OpcGroup | In the OpcGroup class are the data access functions. OpcGroup objects have properties such as the update rate. Clients can create multiple groups with different parameter values to optimize performance. Groups can be inactivated and quickly activated when the client application comes into a mode where the data from this group is needed. |
The OPC DA specification is designed for performance over ease of use. The names of accessed items are specified only in the AddItems functions and the read/write functions use the integer handle that is returned from AddItems. Using integer handles for the item identification is efficient but it requires a sequence of call to access an item, e.g. read an item value from the server.
- Connect to server
- Add a group
- Add item(s) to group
- processing loop with item read/write calls
- remove group
- disconnect server
With the power of today's computers, efficiency is not as important any more as it was when the OPC DA specification was created. OPC DA V3 added read/write functions in the server class that allow simple access to items by their name. This may not yet be of much help because there are not yet many OPC DA V3 servers installed and most clients have to work with OPC DA V2 servers. OPCDA.NET provides QuickUse classes with methods for simplified item access. The SyncIOGroup and RefreshGroup classes handle the group management internally, allowing the user to access the items by name.
Asynchronous server access
OPC DA specifies features for asynchronous server access and data change callback handling that can improve performance dramatically. Asynchronous read/write functions only post a request to the server and return immediately. The result (the value and/or error information) is returned in a callback from the server to the client application. The client application stays always responsive, even if it's single threaded.
With data change callbacks the client application only has to add a group with items and a data change callback handler and the server makes a callback to the client whenever an item value changes. No polling is required and the client gets changed values with lowest latency.
Asynchronous server access requires a little more management than synchronous read/write access. Callback handler need to be created and callbacks need to be activated for the group. Callback can contain multiple item values and the callback handler needs to associate the values with the correct items. This is done with a client handle. In the AddItems call the client application can specify an integer client handle value for each item and the server returns in the callback this client handle with the item value.
The OpcDataBind class simplifies the data change based update handling considerably. The user only needs to make a Subscribe call to bind an OPC server item to a Windows control or user class.
Server callback can cause Windows security permission issues. For the callback the role of server and client are exchanged. The client is the COM server for the callbacks and the server is the client. It may take special configuration steps to grant the required permissions.
Browse
The client application has to specify the correct fully qualified item ID (path name) in order to be able to access the items. These item IDs typically have to be determined by browsing the server, either in the client application for dynamic applications or in a developer tool for application that work with a predefined set of items.
The browse interface is the most problematic and compliance issues are most likely here. Browse support was optional in OPC DA V1 and OPC DA V3 defines a different browse interface that is a bit easier to use. However, it still handles only one level and the client application has to iterate through the branches to find all items.
OPCDA.NET provides methods in the QuickUse classes that return the complete tree structure in a single method call.