Strange 800xa OPC behaviour with third party clients addition
Hereby the document in which the opc log is described. I hope you can look into it and confirm or explain my findings.
Voted best answer
I believe I have reproduced the problem in my lab!
In both 5.1RevD and 5.1FP4RevE I think I see an update of the old value a second before the newly written value is returned.
If I turn off audit trail, the intermediate update does not appear.
I believe the "control read" made when audit is enabled "bleed" to the client. No other clients are affected.
Since most I write here on AKS is "gossip" I recommend that you ask your regional ABB support center to file a support case. You may refer to the two threads you have written here on AKS.
Sure looks odd to me...
Writing a 1 works as expected, but writing a 0 results in a 1 followed by a 0.
2016-01-20 08:45:46:109 Write 1
2016-01-20 08:45:46:850 Update 1
2016-01-20 08:45:53:363 Write 0
2016-01-20 08:45:53:947 Update 1 (!)
2016-01-20 08:45:55:043 Update 0
2016-01-20 08:46:02:194 Write 1
2016-01-20 08:46:03:074 Update 1
2016-01-20 08:46:07:050 Write 0
2016-01-20 08:46:07:131 Update 1 (!)
2016-01-20 08:46:08:150 Update 0
What OPC server is used?
Do you get the same result with another OPC server?
What do you get if you write to a General Property?
Without knowing, the incorrect updates (!) must originate in the write destination's OPC server.
If you like you can turn on two logs in the OPC DA Connector facing the OPC server
AdvDsOPCConnector.exe->OPC Connector Basic->level 3
AdvDsOPCConnector.exe->OPC Adapter Basic->level 3
The wrong updates should be visible there as well, and then we know the write destianation OPC server is sending them.
If audit operator action is enabled, try disabling it. If this audit option is on, each write is preceeded by a control read (read before write) - but the response on the control read should not "bleed through" to the client posting the write.