RE: Closing "Stale" OPC Client Connections

I've had this before and unfortunately it is not something deltav can do from its end.  The OPC client has to be better written to terminate the call to the OPC server, otherwise you need to use a persistent link from the client.

Sent from my Windows Phone

From: James Henry
Sent: ‎19/‎08/‎2014 18:18
To: DeltaV@community.emerson.com
Subject: [EE365 DeltaV Track] Closing "Stale" OPC Client Connections

Anyone,

We're making connections to the OPC server from a third-party client.  After the connection is no longer needed, the client disconnects.  However, when we check diagnostics/OPC subsystem, we're seeing a connection still showing up.  Additionally, when the software creates another connection, both show up.  This appears to continue ad infinitum.  Can anyone tell me how to trigger DeltaV to close the connection on it's end to kill the stale client connections?

Thank you in advance,

James

---

View and reply online or reply-to-all to this email.

Stop receiving emails on this subject.

7 Replies

  • Hi James,
    I am facing the same problem while trying to connect a VB.NET client. Did you find a solution to it?
    Would you like to share the possible workaround.
    Thank you in advance.

    Gaetano
  • In reply to Gaetano Caputo:

    This means the client is not disconnecting properly. The server wouldn't know that the client is still there.

    Note that DeltaV OPC is based on DCOM. DCOM by default maintains the state between the client and the server. Should the client crash the server (DCOM underpinnings) will keep this connection until approximately 7 minutes.

    Later versions of DeltaV have a setting to "synthetically" detect orphaned connections and clean earlier - you have to contact GSC or if you have access to KBAs how to do it.
  • In reply to Lun.Raznik:

    Lun Raznik gave a very good explanation
    Emerson added a mechanism to kill unsed instance, into a Workstation hotfix bundle. if you have guardian search for KBA AK-1700-0073 and AK-1900-0002 This KBA explains which WS bundle is required depending of your DV Version, and also give you a way to manipulate registry key to reduce windows DCOM time out
  • In reply to Lun.Raznik:

    Thank you Lun Raznik.
    What you wrote is clear to me.
    Let me explain my scenario in which I am facing issues on disconnecting client from the server.
    I implemented a VB.Net OPC client running on a non DeltaV node externally from the DeltaV firewall.
    I am able to connect and managing data to and from the OPC server.
    When I have to disconnect from the server I execute the following code:

    If ObjOPCServer IsNot Nothing Then
    If ObjOPCItems IsNot Nothing Then
    ObjOPCGroup.OPCItems.Remove(NoOfItems, gpServerHandlers, gsErrors)
    ObjOPCItem = Nothing
    ObjOPCItems = Nothing
    End If
    ObjOPCServer.OPCGroups.RemoveAll()
    ObjOPCGroup = Nothing
    ObjOPCGroups = Nothing
    ' Disconnect from OPC server before closing the form
    ObjOPCServer.Disconnect()
    ObjOPCServer = Nothing
    End If

    Doing in this way the numer of clients connected to the server (from the Deltav diagnostic) in not decreasing till the client application is killed.

    Is the above illustrated code correct?
    Am I missing something?

    Thank you in advance.
    Regards
    Gaetano
  • In reply to Gaetano Caputo:

    I run into issues using "automation" interface that was shipped as part of OPC Remote. I need to go back and dig to get more information - that might take a while.
  • In reply to Lun.Raznik:

    Thank you Lun Raznik for the time you are dedicating to me.
    I appreciate.

    Gaetano
  • In reply to Gaetano Caputo:

    Gaetano,

    After poking around I remembered that the provided OPC Automation wrapper by DeltaV and/or OPC Foundation does not play nice with .NET languages. This has to do with RCW (.Net Runtime Callable Wrapper) that automatically wraps opcdaauto.dll. There are certain patterns that RCW assumes but unfortunately does not work well with OPCDAAuto.dll.

    The issue is mainly around OPCGroups class/object that is automatically generated by RCW. RCW assumes (rightfully) that OPCGroups object from ObjOPCServer is a distinct COM object but under the hood OPCServer and OPCGroup are one and the same. So the reference counting used by RCW is not going to work!

    OPC Foundation created OPC .NET API to help with this issue. I have created a very simple OPC DA Console in github that you can use as a reference, see github.com/.../DaConsoleVB.