Emerson Exchange 365

• Not Answered

Help with an OPC server/client cache problem

I have a historian app station that also houses our OPC server. I have a good OPC client on another machine but we are trying to upgrade to a new OPC client. The new OPC client is able to connect and get data from the OPC server but for some reason it only works when I force a read, the old OPC client will continuously get new data as the data point changes. I am testing this with the DeltaV tool OPC Watch It. My end goal for the OPC client is to have Aspen CIMIO interface manager read and store the data on an IP21 server. 

These are the differences that I am aware of:

OLD CIM client machine:

• OS: Windows Server 2012R2
• Aspen CIM-IO interface manager V8
• Data is read & updates when values changes in OPC Watch IT
• Same OPC server for both machines

New CIM client machine:

• OS: Windows Server 2016 standard
• Aspen CIM-IO interface manager V11
• Data only reads when the read button is pressed in OPC Watch IT (seems like cache is not updating?)
• Same OPC server for both machines

Is it possible the OPC server has different OPC caches for each client? Could there be security settings in the newer version of windows preventing the continuous reads? Could it be a licensing issue - From my count I should be able to send 2.5x the number of tags I have over OPC so adding a second client for the same values should not make a difference... I have spent countless hours with Aspen e-support only for them to tell me this is an OPC/DeltaV side issue.

I have DeltaV 13.3.1 and I used the version of DeltaV remote on each OPC client that came with the system install disks.  

• cimio
• CIM
• OPC
• aspen
• Historian
• DeltaV

Amber Manzi

• 15 Jun 2020 12:27 PM
• Cancel

4 Replies

• LaurentB

  

  • 15 Jun 2020 1:11 PM

  When you need to force the read, that means your OPC client is not able to received the call the readback ( you can test , bu running OPCWATCHIT on the OPC server machine ( application station) you will received the value with status Recevied data from callback. Now run OPC watchit with the same credential of you OPC client user, from the machine where the opc client is installed and you will probably see that data is not automatically refreshed and status different that received with callback
  
  
  99.99999 % of the case this issue is due to a firewall between Client and Server ( Take care a firewall can be an antivirus software) During upgrade may be your mac address or IP adress have change and firewall doesn't allow all bi directionnal communication.
  To solve issue try to temporary disable all sort of firewalls which can exist between the OPC client and OPC server.

  • Cancel
• LaurentB

  

  • 15 Jun 2020 1:18 PM

  In reply to LaurentB:

  the problematic of this kind of issue is that this is not from Aspen Side, neither Emerson Side , but microsoft or firewall side....
  You don't have issue with DeltaV Licensing or aspen .... just communication restrictions...

  • Cancel
• Youssef.El-Bahtimy

  

  • 15 Jun 2020 2:08 PM

  The issue is with call backs. Deltav always returns the callbacks as Deltavadmin no matter the user on the opc client side. So if I make the request as opcuser, deltavadmin is the one to respond. In recent versions of opcremote, which you installed on the external client, the deltavadmin account created there is not created with enough privilege to receive the callback remotely. See if your deltavadmin account is in the windows administrators group on the client. Ideally, we don't want this, and the better solution is to grant deltav admin the appropriate dcom permissions on the client, but the activity affects the computer base dcom setting from what I was told by PE.
  Here is my basic troubleshooting technique. Take a look at the Windows administrative events filter log on both client and server. Typically one or the other will describe the root cause or enough symptoms to follow.

  • Cancel
• Youssef.El-Bahtimy

  

  • 15 Jun 2020 2:26 PM

  In reply to Youssef.El-Bahtimy:

  If you look at the server windows application log, I believe you may see an event from DeltaV OPC that says 'failed to advise' and then the name of the client computer. If not, then I would recommend using netstat on the server to see if there are unresolved callbacks being generated. These will look like entries from frsopcdv being sent to the foreign address of your client with the status SYN_SENT meaning they were sent but not acknowledged as received. Remember, in this part of the journey, your server is acting like a client, and your client is acting like a server.

  • Cancel