OPC DA 3.00 Specification Errata

[Matthias Damm]

This topic contains all corrections and clarifications to the OPC DA 3.00 specification found since its publication.

The issues will be queued up for a period of time until a new release of the specification will replace version 3.0.

[Matthias Damm]

Use of error code OPC_E_NOTSUPPORTED

Use of Error code OPC_E_NOTSUPPORTED in the methods
- IOPCItemIO::WriteVQT
- IOPCSyncIO2::WriteVQT
- IOPCAsyncIO3::WriteVQT

The server is allowed to return OPC_E_NOTSUPPORTED if he does not support the writing of Qualities and Timestamps. Version 3.00 of OPC Data Access specification specifies this error as return code of the method. This is an error in the specification. The error code must be item specific for the following reasons:
- The server might support it for some items but not for all
- In XML-DA it is an item-specific error
- The client can select quality/timestamp writing for each item

[Jim Luth]

Problem:
The current specification is ambiguous as to whether KeepAlive callbacks should be sent for active groups without any active items.

Clarification:
The KeepAlive is a function of the Group and as such should work consisistently. KeepAlive callbacks must be sent even if there are no items in the group or if all the items in the group are deactivated.
That way it can be used by clients instead of periodic GetStatus calls.

Pre-conditions for KeepAlive:
* group is active (connection point is attached)
* group is enabled
* no data changes, AsyncRead responses, AsyncWrite responses, or Refresh responses have been sent during the last KeepAlive Time

Expected client usage:
Clients should expect KeepAlive callbacks at the requested rate. However, it is recommended that clients wait at least 150 % of the requested time before they take action. Servers might be kept from sending the KeepAlive due to a temporary high CPU load or due to temporary connection problems.
If KeepAlive callbacks do not occur as expected, clients might indicate this as a problem to the user and/or start to reconnect.

[Jim Luth]

Problem:
If browse is called with maxElements set to a small number to get all Elements in small portions, the items will be returned in multiple browse calls with continuationPoints.
Several servers do not reset the continuationPoint to a NUL string after the last browse call at one branch. That usually causes clients to end up in an infinite loop.
The current specification does not explicitly state that the server has to set the continuation point back to a NUL string.
Clarification:
If the server supports continuation points and the reply is larger than dwMaxElementsReturned, the server will return a non-NUL continuationPoint to to allow the client to get the subsequent chunk(s) in follow on browse calls.
When returning the last portion of browse elements in a series of subsequent browse calls when the reply is not larger than dwMaxElementsReturned, the server MUST set the continuationPoint back to a NUL string.

[Jim Luth]

Problem:
In section 4.4.10.2 IOPCItemSamplingMgt::GetItemSamplingRate
the 3rd parameter to the method is described as:
[out, size_is(,dwCount)] DWORD * ppdwSamplingRate,


Correction:

It should be:
[out, size_is(,dwCount)] DWORD ** ppdwSamplingRate,

[Jim Luth]

Problem:
When a server returns an OPCBROWSEELEMENT structure in a call to IOPCBrowse::Browse() where the szName is a "hint" (by specifying dwFlagValue >= 2 and szItemID =NULL), the specification does not indicate the expected content of the ItemProperties element. Also the DA3 specification does not explain the purpose of the "hint".

Clarification:
Since a valid ItemID is not returned, ItemProperies.hrError MUST be set to OPC_E_INVALIDITEMID

Here is the use case for returning "hint" strings:
Whenever possible the server should return strings which can be passed directly to AddItems. However, it is allowed for the Server to return a ‘hint’ string rather than an actual legal Item ID. For example a PLC with 32000 registers could return a single string of "0 to 31999" rather than return 32,000 individual Item IDs. For this reason clients should always be prepared to allow manual entry of Item ID strings.