Basic history. Differences in trends on different workstations
System: 800xA 6.1 with Freelance connect. (redundant AS, CS servers, redundant controllers)
I noticed that the same trend is different on the operator and engineer stations (It's the same trend, same log configuration, same data).
Fist I rebooted primary CS, and after some time rebooted secondary CS. After that I saw that Service Provider Metric "PercentSynchronized" doesn't become 100% (see photo) on both CS's.
I have some questions:
1. What is this Synchronization? Between what and what?
2. What could be the reason not 100% synchronization?
3. What could be the reason of trend data differences on different machines and how to solve it?
Best regards, Maksim.
Voted best answer
- Make sure all logs are enabled (statistics show some logs are not enabled).
- Do you have affinity for OPC DA Connector service? Make sure the "All nodes" group has been added last on each affinity row and that CS1 can connect CS2 and vice versa.
With the Parallel Redundancy function enabled on the OPC DA Connector service group (it is on by default) two redundant historians should record the exact same data since both uses the same source, only when the parallel feed is lost, data may be recorded from the local server.
To end up with different content (as your images seem to indicate) the following two items must be true:
a) there is a deviation between the OPC DA Servers (Basic History cannot invent data*...)
b) parallel redundancy is disabled or blocked from operation by affinity or other network issue
*) turn off Exception Deviation (deadband compaction). Never use it... Potentially also disable Max Time (to force only Raw values to be logged) during troubleshooting. With Max Time enabled, a "silent" signal will keep logging the last received value, though with the Extrapolated quality code bit set. Make sure to review quality code values using the Log Configuration > Status > Read function.
About a) keep in mind that calling up the same faceplate on CS1 and CS2 and verifying that the value is identical is NOT solid proof of an OPC server's health. The subscription used by the historians may be days, weeks or months old (only days here though as can be seen in EnterServiceTime statistics in your images). Two subscriptions (old and new) for the same item should in theory get same data, but that is up to the OPC server to make sure of. I've seen OPC servers faulting on this very important point.
The good thing is that the OPC DA layers of System 800xA is virtually stuffed with internal logging. Your regional support team should be able to assist you with a support case where we can have you enable such logs to track down from where the incorrect data is received (in practice, only the OPC DA server can create a data point/value, but with the logs we get solid proof of a server at fault). I have attached a document detailing some of these logs.
Likely, you will need support's assistance with narrowing down the root cause. Please have a case registered.