DOC

OPCClient Object

By Annie Roberts,2014-09-16 15:27
25 views 0
opcclient object jsonobject swfobject selectobject objectdock activexobject createobject objectmapper swfobject.js

OPCClient Object

    The OPCClient object functions as the ArchestrA OPC Data Access Client for third-party OPC (OLE for Process Control) Data Access Servers. The OPCClient object provides functionality similar to OPCLink.

    For more information, click on a Help topic.

    ; Overview

    ; Run-Time Behavior

    ; Configuration

    ; Run-Time Object Attributes

    Overview

    The OPCClient object is a key member of the core set of AutomationObjects within the ArchestrA system infrastructure. The OPCClient object is a DeviceIntegration (DI) object that allows access to a running OPC Data Access (DA) Server. A third-party OPC DA Server can provide data points to Galaxy application objects through the OPCClient object. Note The OPCClient object is compatible with all OPC Servers 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 DA Server. If you want to reference data points in more than one OPC DA Server, 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 DA Server:

    ; Subscriptions, which are implemented via scan groups. For more information, see

    Scan Groups.

    ; Read transactions, which are implemented via block reads. For more information, see

    Block Reads and Block Writes.

    ; Write transactions, which are implemented via block writes. For more information,

    see Block Reads and Block Writes.

    Important! If you are using this object to communicate with an OPC DA Server, you must properly configure the OPC DA Server 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 run time.

    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.

    For general information on objects, including relationships, deployment, and alarm distribution, see the Integrated Development Environment (IDE) documentation. For information on configuration options for object information, scripts, user-defined attributes (UDAs), or attribute extensions, click Extensions Help in the Help file header.

    Related Topics

    Run-Time Behavior

    Configuration

    Run-Time Object Attributes

    OPC Data Access Server Security Settings In order for the OPCClient object to connect to a third-party OPC DA Server, certain security settings are required on the third-party OPC DA Server node.

    Note These same settings must be applied to OPCEnum if the OPCClient is to use the server name instead of the progID.

    If the OPC Server is a Wonderware DAServer, no additional configuration is required. The recommended settings are explained as follows. All of these setting can be set with Windows utility DCOMCnfg.Exe.

    1. Run DCOMCnfg.Exe.

    2. In the list of applications, select the OPC DA Server and then click Properties.

    Note Under some conditions, the third-party OPC DA Server may not appear in the list of applications. In this case, you will need to create server specific AppID and run DCOMCnfg.Exe again. For information on creating AppID for COM objects, see the Microsoft documentation.

    3. Click the General tab.

    4. In the Authentication Level list, click None. (The default setting is "Default.")

    The authentication level informs the component object model (COM) how much authentication protection is required, and it can range from authenticating the client at the first method call to encrypting parameter states fully.

    5. Click the Security tab to configure who is allowed to launch permissions and access permissions to the server.

    The launch permissions control the list of users who are granted or denied permission to launch a particular server.

    You can control the list of users who are granted or denied access to the methods of a particular server by setting access permissions. You can add users or groups to the list, specifying whether access permission is being granted or denied. You can also remove users from the list.

    When setting access permissions, you must ensure that both SYSTEM and Everyone are included in the list of users that are granted access.

    6. Select Use custom access permissions and Use custom launch permissions.

    7. For each of them, click Edit and then add "Everyone" and "System" to the list of users allowed to access and launch the server.

    8. Click the Identity tab to configure the identity of the server.

    An application's identity is the account that is used to run the application. The identity can be that of the user that is currently logged on (the interactive user), the user account of the client process that launched the server, a specified user, or a service. Thus, you can select from one of the following three options:

    o The interactive user

    The interactive user is the user that is currently logged on to the computer

    where the application is running. If the identity is set to be the interactive

    user, all clients use the same instance of the server if the server registers its

    class factory as multi-use. If no user is logged on, the application will not run.

    If the server has a graphical user interface (GUI) that the client needs to see,

    you should use interactive user for the application's identity. However,

    choosing this identity carries some security risks because the server runs

    under the identity of the logged on user without the logged on user's

    knowledge or consent.

    o The launching user

    This is the default setting for the application identity. When the launching

    user is chosen for the application's identity, each client account gets a new

    instance of the server, and each server gets its own WinStation. Because of

    the separate server instances, launching user is the most secure identity

    setting. However, there are limits on resource consumption. Also, any GUI

    the server displays will not be seen by the client. Although this is the option

    selected by default, we recommend to avoid selecting this option.

    o This user

    Specifying a particular user (and the user's password) is the preferred

    identity for COM servers. The reason this identity is preferred is that no one

    has to be logged on the machine where the server is running for the server to

    run, and every client talks to the same instance of the server if the server

    registers its class factory as multi-use. If the server has GUI, then you should

    not choose this identity; if you do, the user will not be able to see the user

    interface. Running as a fixed user account is more secure than the interactive

    user identity because this identity can only be assigned to the application by

    someone who has the specific user's password.

    Related Topics

    Overview

    Scan Groups

    A scan group, or device group, is a collection of user-defined attributes that have a common update interval. When you configure the OPCClient object, you will need to specify at least one scan group in order to deploy the object. Within each scan group, you can specify data items to use as the object attributes. At run time, items for a scan group will be updated with the latest values from the OPC DA Server according to the update interval. From other objects and from scripts, you can reference the attributes (items) you configured for the OPCClient object. For example, you might configure the input source for a FieldReference object to reference an item for one of the scan groups. Thus, the FieldReference object input source would be receiving data from an OPC DA Server via the OPCClient object.

    Tip You can use any OPC client tool to browse a field device's address space for item names. The reference syntax for a OPCClient object data point is:

    <objectname>.<scangroupname>.<itemname>

    The <objectname> is the name that you choose to give to the OPCClient object.

    The value of <itemname> depends on the type of OPC DA Server you are connecting to. For information on how to reference data points in the OPC DA Server, see the server documentation.

    Run-time object attributes allow you to monitor errors related to the data quality for item values in a scan group.

    Related Topics

    Overview

    Block Reads and Block Writes

    Block Reads and Block Writes

    A block read is a set of user-defined attributes for which you want to retrieve values in a single transaction. Instead of the I/O points being on advise, as with a scan group, the attributes are updated once per transaction. A block read must be initiated from a user or script via the BlockRead.TransactionTrigger attribute.

    A block write is a set of user-defined attributes to which you want to write values in a single transaction. Only values that are new for the attribute since the last transaction are written to the OPC DA Server. A block write must be initiated from a user or script via the BlockWrite.TransactionTrigger attribute. You cannot trigger another transaction if the previous transaction has not completed.

    Note Although block reads and writes are intended to be individual transactions, the actual communication with the field device is dependent on the number and type of attributes, and it may be necessary to send and receive multiple messages to and from the field device. As a result, the values exposed after a block read operation might have been obtained at different times. You must carefully design the logic in the field device to make sure that the values do not change until the full read operation is completed. In the case of a block write operation, the logic in the field device must not use the written values until the full write operation is completed.

    For a block read, either all of the attributes will be updated or none of the attributes will be updated; no partial updates are supported. In the case of a block read failure or transaction timeout, the data quality for all attributes is set to BAD.

    For a block write, partial writes are supported. However, the system does not offer roll-back functionality. In the case of a block write failure or transaction timeout, some values may have been successfully sent, but there is no way to undo the value changes. For items that have not yet been written to, the data quality is set to BAD.

    Finally, run-time object attributes allow you to monitor errors related to the data quality for item values in a block read or block write operation.

    Related Topics

    Overview

    Scan Groups

Run-Time Behavior

    The following information describes the run-time behavior of OPCClient objects. Run-time

    behavior is limited to the state of individual OPCClient objects. After it has been deployed and is operating, an OPCClient object can assume one of several

    states, which are described in the following table:

    State Behavior

    Change

    Startup In this state, the OPCClient object connects to the OPC DA Server.

    Going None.

    onscan

    Running In this state, the OPCClient object:

    onscan

    ; Services read and write requests.

    ; Receives values from the OPC DA Server scan groups (device

    groups).

    ; Monitors the connection to the OPC DA Server.

    ; Detects alarm conditions, if alarming is enabled.

    ; Monitors the data quality for OPC DA Server data values and updates

    run-time error statistics if the quality is not GOOD.

    Going None. The ConnectionStatus attribute is set to "Disconnected."

    offscan

    Offscan The object is passive and does not service read and write requests.

    Shutdown In this state, the OPCClient object disconnects from the OPC DA

    Server.

    Related Topics

    Overview

    Configuration

    Run-Time Object Attributes

    Configuration

    The following section describes the object editor options for configuration and the associated

    attributes:

    ; General Configuration

    ; Scan Group Configuration

    ; Block Read Configuration

    ; Block Write Configuration

    For general information on objects, including relationships, deployment, and alarm

    distribution, see the Integrated Development Environment (IDE) documentation.

    For information on configuration options for object information, scripts, user-defined

    attributes (UDAs), or attribute extensions, click Extensions Help in the Help file header. Related Topics

    Overview

    Run-Time Behavior

    Run-Time Object Attributes

    General Configuration

    Use the General tab to specify the OPC DA Server from which to retrieve data and to

    configure restart options.

    Editor Associated Attribute Description Run-Time Option Access

    (Supervisory,

    User,

    Read-Only,

    None) Server ServerNode The name of the Supervisory, node node (computer) on User

    which the OPC DA

    Server is running. If

    this attribute is

    blank, the OPC DA

    Server is assumed to

    be running on the

    local node.

    Click the Browse

    button to find the

    network for the

    node.

    Server ServerName The name of the OPC Supervisory, name DA Server. The User

    naming syntax for

    the OPC DA Server

    varies according to the type.

    Run server ServerActivation If enabled, the OPC Read-Only

    out-of-proc DA Server will be run

    out-of-process. An in-process OPC DA Server runs as a .Dll

    within the engine process. An

    out-of-process OPC DA Server runs as a stand-alone

    executable. The

    method you choose depends on the methods supported by the OPC DA

    Server and

    performance

    considerations.

    To connect to the OPC DA Server

    in-process, all of the following must be true:

    ; The OPC DA

    Server must be

    installed locally

    relative to

    where the

    OPCClient is

    installed.

    ; The OPC DA

    Server must

    support an

    in-process

    connection.

    ; The OPC DA

    Server is not

    currently

    running

    out-of-process.

    ; The value of

    the ServerNode

    attribute must

    be blank.

    ; This Run

    server

    out-of-proc

    check box must

    be unchecked.

    Use scan DAGroupAsAccessPath If enabled, the name Read-Only group of the scan group will name as be used for the OPC access path access path. Select

    this option for OPC

    DA Servers that

    require a topic to be

    specified for the

    access path. You

    must then make sure

    that any scan group

    you specify is named

    the same as a topic

    within the OPC DA

    Server.

    Restart RestartMax The maximum Supervisory, attempts number of times that User

    the OPCClient object

    should attempt to

    restart a failed OPC

    DA Server within the

    restart period.

    Restart RestartPeriod The time period, in Supervisory, period milliseconds, over User

    which the maximum

    number of restart

    attempts applies. If

    this time period

    elapses before the

    maximum number of

    restarts is exceeded,

    then the restart

    count is set back to

    zero.

    Detect RestartAlarm.Alarmed If enabled, an alarm None restart will be triggered alarm when the number of

    attempts to start the

    OPC Server has

    exceeded the

    allowed maximum

    within the restart

    period.

    Priority RestartAlarm.Priority See Alarm Supervisory,

    Attributes. User Connection ConnectionHeartbeatPeriod The time interval, in Supervisory, heartbeat milliseconds, at User period which the OPCClient

    object will check the

    connection to the

    OPC DA Server.

    Detect ConnectionAlarm.Alarmed If enabled, an alarm None connection will be triggered alarm when the OPCClient

    object can no longer

    communicate with

    the OPC Server.

    Priority ConnectionAlarm.Priority See Alarm Supervisory,

    Attributes. User Restart RestartReset Used to set security Supervisory, reset for restarting the User security OPC DA Server.

    Related Topics

    Configuration

    Scan Group Configuration Use the Scan Group tab to add scan groups to the OPCClient object.

    Editor Associated Attribute Description Run-Time Option Access

Report this document

For any questions or suggestions please email
cust-service@docsford.com