Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA™ Operations Management Interface

Overview of the OPCClient object

  • Last UpdatedJul 19, 2024
  • 2 minute read

The OPCClient object is a key member of the core set of AutomationObjects within the System Platform infrastructure. The OPCClient object is a DeviceIntegration (DI) object that allows access to a running OPC communications driver. A third-party OPC communications driver can provide data points to Galaxy application objects through the OPCClient object.

Note: The OPCClient object is compatible with all OPC communications drivers that are compliant with OPC Data Access v2.05 or later standards.

There is a one-to-one relationship between an instance of the OPCClient object and a running OPC communications driver. If you want to reference data points in more than one OPC communications driver, you must configure and deploy more than one OPCClient object. For example, you would need to configure one OPCClient object to communicate to an ABTCP OPC Server and another one to talk to the ABCIP OPC Server.

An OPCClient object supports the following operations on I/O points for the OPC communications driver:

  • Subscriptions, which are implemented via scan groups. For more information, see Scan groups and the OPCClient object.

  • Read transactions, which are implemented via block reads. For more information, see Block reads and writes.

  • Write transactions, which are implemented via block writes. For more information, see Block reads and writes.

    Important! If you are using this object to communicate with an OPC communications driver, you must properly configure the OPC communications driver before deploying this object.

Items in a scan group, block read, or block write are "dynamic" in that they are created or activated dynamically during runtime.

For a block read, if the quality of a dynamic attribute changes, but a data value update is not received from the data provider, the current time of the hosting AppEngine is used as the new time stamp. If the data quality transitions to GOOD because a data update was received, the value and time stamp passed in with the data update is used for the attribute.

For a block write, the time stamp of the attribute is updated to the time stamp provided by the set request. If no time stamp is provided, the current time of the hosting AppEngine is used. If the quality of an attribute changes because of a failed set request, the current time of the hosting AppEngine is used as the new time stamp.

TitleResults for “How to create a CRG?”Also Available in