Checklist: OPCDA Server

Checklist: OPCDA Server

Time estimate: 20 minutes

Please go through all the points in the following checklist. If necessary, confirm with IT Department any information you cannot verify before contacting your local COPA-DATA Representative.
  1. Do NOT use DCOM in combination with the zenon OPC DA server (or the zenon OPC DA client).
    2. Only local access to the zenon OPC DA server is supported.
  2. Make sure that the OPC DA core components from the OPC foundation are installed (this is not included in the zenon installation).
    1. Install x86 and x64 version of the latest version of the OPC DA core components.
      1. The latest setup can be downloaded from the OPC foundation website.
      2. A version is also included on the zenon DVD / USB drive, in the third party applications folder.
    2. Reboot the system after installation.
  3. Make sure that the zenon OPC DA server is registered correctly (this is explicitly not performed by the zenon installation or the Startup tool, for security reasons).
    1. Open a command prompt with Administrator rights.
    2. Navigate to the 32 bit zenon installation directory.
    3. Execute "zenOpcSrv /RegSrvD".
    4. Make sure that the result says that the zenon OPC DA server registered correctly.
  4. Make sure that external zenon API access to the Service Engine is enabled in zenon configuration file (zenon6.ini: [VBA] EVENT=1).
  5. Make sure that the Service Engine and the zenon OPC DA server are running in the same Windows session and in the same User context.
    1. This can be challenging under certain circumstances:
      1. It is usually the OPC DA client that starts the zenon OPC DA server, by connecting to it.
        1. If a OPC DA client is started via remote desktop, this can be a different Windows session than the Windows Session where the Service Engine is running, especially on Server operating systems
          1. Should the OPC DA client not run in the same Windows session, on connecting to the zenon OPC DA server, the client will initiate a new zenon OPC DA server instance to be launched. This instance of the zenon OPC DA server will not have access to the zenon Service Engine that is running in a different Windows session.
          2. It can happen that there are two or more instances of the zenon OPC DA server process running, started by OPC DA clients from different Windows sessions or started by OPC DA clients that are run in a different Windows users context.
            1. Only the OPC DA server that is running in the same Windows session and user context as the zenon Service Engine, will have access to the Service Engine and will provide the variables as items when browsing the OPC DA server.
  6. Make sure that with large zenon projects, the zenon OPC DA server is started "automatically" with the zenon Service Engine, so that it has some time to initialize all variables for all Projects.
    1. It is not possible to configure the zenon OPC DA server, to provide access only to limited zenon variables or projects. In any case all variables for all projects in the Service Engine are provided. With larger projects, startup of the zenon OPC DA server takes time. Up to twenty minutes for projects with 650.000 variables. If an OPC DA client attempts to connect to the zenon OPC Server while the zenon OPC DA server is still initializing the variables and projects, it will automatically run in to a timeout after two minutes (120 seconds) and disconnect. If this is the only client connected to the OPC DA server, the OPC DA server will shutdown, as it always does when the last client disconnects. In this case, a communication would only be possible of the OPC DA client is able to hold off connecting to the OPC DA server until the OPC DA server is fully initialized (visible in the diagnosis server logs).
    2. A way to start the OPC DA server "automatically" with the Service Engine, is to create an OPC DA client driver in a zenon project that connects to the local zenon OPC DA server. Do not create any variables for this driver. On startup it will launch the zenon OPC DA server and will also prevent the OPC DA server from closing as at least one client is still connected (do take care when reloading the Service Engine).
  7. Note that the zenon OPC DA server uses the com interface and only supports single variable change events and not bulkchange. Many variable changes may put a stress on the communication and may lead to high CPU load and even blocking of the Service Engine.
  8. Note that the zenon OPC DA server will only be running once in the same user context and windows session. It is not possible to start multiple instances that all connect to the same Service Engine. Two separate OPC DA clients in the same user context and session as the zenon Service Engine will result in a single zenon OPC DA server running communicating to both OPC DA clients.
  9. Make sure that an OPC DA client only ever inserts a variable once, in any group. Inserting a variable multiple times will result in an error message on the client.
  10. Make sure that an OPC DA client creates a separate OPC group for every single zenon Service Engine project and only inserts variables from the same project in each group.
  11. Be aware that the matrikon OPC tunnelling software performs an optimization that cannot be turned off. Even if the OPC DA client creates different OPC groups for different zenon projects, the tunnelling software merges these groups together. On the zenon OPC DA server side, the matrikon tunneler client will only create one group in the zenon OPC DA server. If a OPC DA client adds variables from different projects in the different groups, this may result in a variable with the same PvID being added in the single group created by the tunnel client. This results in an error on the OPC DA client side.
    1. As a workaround, the OPC DA client can create OPC groups with different settings, for every zenon projects. E.g. an asynchronous group with a scan time of 1000ms, for the first project and another asynchronous group with a scan time of 1001ms for the second project. This circumvents the optimization feature in the tunnelling software.
  12. Be aware that the matrikon OPC tunnelling software by default is configured as a service. This makes the OPC client side of the tunneler that connects to the zenon OPC DA server run in "session 0" usually in the user context SYSTEM. Any OPC DA client that connects through the tunneler will cause a new zenOPCSrv process to be launched, in session 0 and the SYSTEM context. Due to session isolation and user context protection in Windows, this instance of the zenon OPC DA server will not have access to the zenon Service Engine running in session 1 under a different user context. An OPC DA client may be able to connect, but a browse will yield no results.
  13. Be aware that the OPC DA server does not provide a hierarchy in the address space. An OPC DA client can only browse a flat list, that contains all items.
  14. Note that the OPC DA server forwards quality information from the zenon Service Engine. An OPC Item that has quality "bad" in the OPC client does not necessarily mean that the communication of the item from the OPC DA server is not working. It is more likely that the internal quality of the variable in the zenon Service Engine is INVALID.
  15. Note that the last client that disconnects from a running zenon OPC DA server, will cause the zenon OPC DA server to close.
 ad1) to consider when running zenon Service Engine as a service:

When the zenon Service Engine is configured to run as a service through zenStartupMgr.exe, the Service Engine is running in Session 0, normally in the SYSTEM user context.

An OPC DA client that attempts to connect to the zenon OPC DA server will launch a zenOPCSrv.exe server in its own interactive session (usually session 1) in its own user context. The zenOPCSrv.exe requires access to the zenrt32.exe process. This is not possible when the zenrt32.exe process is running in a different user context or different session. The zenOPCSrv will therefore not find the Service Engine, that in fact is running.

In order for the zenOPCSrv to access the Service Engine, it must also be started in Session 0 and the SYSTEM user context. This can be done by explicitly starting also the zenOPCSrv.exe application through zenStartupMgr, however in this case when a OPC client connects and disconnects (and it is the last client) the zenOPCSrv.exe server will also close automatically (intended behaviour). A workaround exists by creating a OPC client driver in the zenon project that connects to the local zenOPCSrv server, to 1) start the server and 2) keep the server running.

OPC Tunneling software, (Matrikon OPC Tunneller or Softing Data Suite) can overcome the issue that a OPC Client does not normally run in session 0 in the SYSTEM context, as the OPC Client side of the OPC tunnel by default is implemented as a service.

One thing needs to be explicitly taken into account. If the zenStartupMgr.exe service is configured to "allow interaction with desktop", also the OPC Tunneler service must be configured with the same option set to TRUE. If this is not done, a OPC Client that attempts to connect through the tunnel will create a new instance of the zenOPCSrv.exe server that will not be able to connect to the Service Engine, rather than find and use the existing one.

 ad2) tunnelling software

While COPA-DATA only officially supports local OPC communication, there are customers that have successfully implemented 3rd party OPC Tunnelling software to overcome having to use DCOM. COPA-DATA does not test compatibility with such 3rd party tunnelling software. In case of any suspected errors, it should always first be tested if the issue also occurs with local communication and no tunnelling is used.

There is a known issue where Softing tunnelling software may cause a very high CPU load on the OPC DA server side when the OPC tunnelling client connects and browses the address space.

If the problem persists after completing this checklist and followed corrective actions, please contact your local COPA-DATA Representative providing a SIC-Reduced Report from the target computer(s) and the result of this checklist – please include any additional information or comments related with the points addressed you find relevant.

System Information Collector is a standalone COPA-DATA application that collects relevant data about the Operating System and zenon Software Platform for troubleshooting purposes. SIC is installed with zenon and can be started from zenon Startup Tool (Tools).

    • Related Articles

    • Checklist: Client/Standby cannot establish a reliable connection with Service Engine Server

      Time estimate: 45 minutes Please go through all the points in the following checklist. If necessary, confirm with IT Department any information you cannot verify before contacting your local COPA-DATA Representative. Checklist usage: #. [Quick hints] ...

    • Checklist: Allocations

      Time estimate: 15 minutes Please go through all the items in the following checklist. If necessary, confirm any information you cannot verify with the IT department before contacting your local COPA-DATA representative. Is a source and a target ...

    • Checklist: Message Control

      Time estimate: 15 minutes Please go through all the points in the following checklist. If necessary, confirm with IT Department any information you cannot verify before contacting your local COPA-DATA Representative. Screenshot and followed ...

    • Checklist: HTML Web Engine

      Time estimate: 20 minutes Please go through all the points in the following checklist. If necessary, confirm with IT Department any information you cannot verify before contacting your local COPA-DATA Representative. Screenshot and followed ...

    • Checklist: Software Platform installation fails

      Time estimate: 30 minutes Please go through all the items in the following checklist. If necessary, confirm any information you cannot verify with the IT department before contacting your local COPA-DATA representative. Checklist usage: #. [Quick ...