Continuing on with the overview.   This should be Part V of VI as we are getting to the end.  Even a high level technical overview takes some time.   Think what it takes to develop a solid, industrial strength product, even with a well defined standard!  

4.4.5 IOPCSyncIO     Page 77

The synchronous read/write function, often referred to as a Demand Read or Write.  These operations run to completion.  Depending on the type of underlying device and details of the implementation (e.g. which threading model is used) synchronous actions could take a long time to complete or may also prevent any other operations from being performed on the server by any other clients.

4.4.5.1 IOPCSyncIO::Read     Page 77

Reads the value, quality and timestamp from either the CACHE or DEVICE.  Expected behavior is that a CACHE read should be completed very quickly (within milliseconds), where a DEVICE read may take a very long time (many seconds or more).   For this reason Clients are expected to use CACHE reads in most cases. DEVICE reads are intended for ‘special’ circumstances such as diagnostics.

4.4.5.2 IOPCSyncIO::Write     Page 80

Writes values (and only the value) to one or more items in a group. The function runs to completion. The values are written to the DEVICE. That is, the function should not return until it verifies that the device has actually accepted (or rejected) the data.

4.4.6 IOPCSyncIO2     Page 82

Shiny and new with DA 3.0.   The purpose of this interface is to provide a group level method for writing timestamp and quality information into servers that support this functionality. In addition, the ability to Read from a group based on a “MaxAge” is provided. This interface differs from the IOPCItemIO interface in that it is group based as opposed to server based.

4.4.6.1 IOPCSyncIO2::ReadMaxAge     Page 82

Like the SyncIO function, but is only from CACHE.  The MaxAge parameter gives the acceptable “staleness” for each item. The server will calculate the number of milliseconds between “now” and the timestamp on each item. For each item that has not been updated within the last MaxAge milliseconds, the item must be obtained from the underlying device.

4.4.6.2 IOPCSyncIO2::WriteVQT     Page 85

A long awaited feature.   Writes one or more values, qualities and timestamps for the items specified.  Like SyncIO::Write except that Quality and Timestamp may be written. If a client attempts to write VQ, VT, or VQT it should expect that the server will write them all or none at all.

4.4.7 IOPCAsyncIO2     Page 87

These allow a client to perform asynchronous read and write operations to a server. The operations are ‘queued’ and the function will return immediately so that the client can continue to run. Each operation is treated as a ‘transaction’ and has an associated ID.  Asynchronous operations are generally the preferred method of exchanging data.

4.4.7.1 IOPCAsyncIO2::Read     Page 88

Reads the value, quality and timestamp from the DEVICE.

Blogger Note:  In earlier versions of the DA spec, there was an asynchronous read from CACHE, but it gave no performance benefits over a synchronous read from cache (and in some implementations was actually slower!).

4.4.7.2 IOPCAsyncIO2::Write     Page 91

Asynchronous version of the Write, so it writes the value only.

4.4.7.3 IOPCAsyncIO2::Refresh2     Page 94

This operation Force a callback for all active items in the group (whether they have changed or not).  Functionally it is also similar to what could be achieved by doing a READ of all of the active items in a group.

4.4.7.4 IOPCAsyncIO2::Cancel2     Page 96

Cancels any outstanding transactions.  Good clients will do this before shutting down.

4.4.7.5 IOPCAsyncIO2::SetEnable     Page 97

4.4.7.6 IOPCAsyncIO2::GetEnable     Page 98

These set/get the callbacks.   The purpose of the functions is to allow a Connection to be established to an active group without necessarily enabling the OnDataChange notifications. An example might be a client doing an occasional Refresh from cache.

4.4.8 IOPCAsyncIO3     Page 99

Another new interface with DA 3.0  The purpose of this interface is to provide a group level method for asynchronously writing timestamp and quality information into servers that support this functionality.

4.4.8.1 IOPCAsyncIO3::ReadMaxAge     Page 99

4.4.8.2 IOPCAsyncIO3::WriteVQT     Page 102

Asynch versions of ReadMaxAge and WriteVQT.   Again asynchronous operations are usually preferred.

4.4.8.3 IOPCAsyncIO3:: RefreshMaxAge     Page 104

Much like the Refresh functionality, except the MaxAge value will determine where the data is obtained. There will be only one MaxAge value, which will determine the MaxAge for all active items in the group. This means some of the values may be obtained from cache while others could be obtained from the device depending on the “freshness” of the data in the cache.

4.4.9 IOPCItemDeadbandMgt     Page 106

Long awaited modifications to deadbanding.  This interface allows the PercentDeadband to be set for individual items within a group. Once set on an item it overrides the PercentDeadband set for the entire group. This provides a mechanism to set the PercentDeadband on a “noisy” item, which may reside in a group that doesn’t have the group PercentDeadband set. It also allows individual items to be fine tuned with respect to notifications based on an expected range of change.

4.4.9.1 IOPCItemDeadbandMgt::SetItemDeadband     Page 106

4.4.9.2 IOPCItemDeadbandMgt:: GetItemDeadband     Page 108

4.4.9.3 IOPCItemDeadbandMgt:: ClearItemDeadband     Page 110

Fairly self explanatory.  Functions used to deal with item level deadbanding.

4.4.10 IOPCItemSamplingMgt (optional)     Page 112

One of the very few optional interfaces.   It’s a very useful feature, and is kind of a poor man’s buffering.   This interface allows the client to manipulate the rate at which individual items within a group are obtained from the underlying device. It does not affect the group update rate of the callbacks for OnDataChange.  So for example if you have three items in a group with an update rate of 10 seconds, you would get a data callback every 10 seconds (even if the data is changing faster on the device).   With this interface you could set ItemSampling on one or more items.  Say you set one item in the group with a Sampling rate of 2 seconds and buffering enabled.  If that item updated 3 times during the 10 seconds, then on the callback multiple values get returned for that item.

Because the server may need to buffer an unknown amount of data, the server is allowed to determine the maximum amount of data buffered. The server should maintain the same size buffer for each item. If the server determines that its maximum buffer capacity has been reached, then it will begin to push out the older data, keeping the newest data in the buffer for each item.

4.4.10.1 IOPCItemSamplingMgt::SetItemSamplingRate     Page 113

4.4.10.2 IOPCItemSamplingMgt::GetItemSamplingRate     Page 116

4.4.10.3 IOPCItemSamplingMgt::ClearItemSamplingRate     Page 118

4.4.10.4 IOPCItemSamplingMgt::SetItemBufferEnable     Page 119

4.4.10.5 IOPCItemSamplingMgt::GetItemBufferEnable     Page 121

Functions to handle the ItemSampling stuff.

4.4.11 IConnectionPointContainer (on OPCGroup)     Page 123

4.4.11.1 IConnectionPointContainer::EnumConnectionPoints     Page 124

4.4.11.2 IConnectionPointContainer:: FindConnectionPoint     Page 125

These interfaces are improved versions of the DA 1.0 asynchronous handling routines.  OPC Compliant Servers, versions 2.0 and higher, are REQUIRED to support this interface.

4.4.12 IEnumOPCItemAttributes     Page 126

4.4.12.1 IEnumOPCItemAttributes::Next.     Page 126

4.4.12.2 IEnumOPCItemAttributes::Skip     Page 127

4.4.12.3 IEnumOPCItemAttributes::Reset     Page 128

4.4.12.4 IEnumOPCItemAttributes::Clone…129

These interfaces allow a client to find out the contents (items) of a group and the attributes of those items.

I had originally planned to wrap this up in five posts, but it’s getting too long.  I’ll finish off the installation issues, and client side stuff in one last post.  Stay tuned.