Freelance OPCserver is reporting priority-1 alarms whenever there is a time synchronization done by AC800F
Could you please tell us how to avoid the freelance system priority-1 nuisance alarms, whenever there is a time synchronization done by AC800F.
The alarm screens attached for you information.
Thanks & Regards
Subramani T N
it would be helpfull to know the column titles for the screenshot. Some I can guess, but others I have no clue.
Also it is talking about an Uploader. Is it a Freelance system with 800xA on top?
How is time synchronization set up in the system? Is one of the AC 800F time master, or is it a Windows PC? How is the other part of the system (that part that does not contain the time master) synchronized?
Do those alarms only come up during upload?
so the system is time synchronized top down from the GPS connected to the domain server via the OPC Gateway (which is also synchronized by the domain server) to the controllers.
That requires that you have enabled External Time Synchronization in the OPC Gateway Header and at least given the IP address of one AC 800F Controller in the System.
Please verify that the IP address you configured in the OPC GWY header indeed belongs to an AC 800F!
The AC 800F also need to be in the same subnet as the OPC GWY. Check that your subnet mask fits to the IP range you are using for the AC 800M and the OPC GWY!
It also requires that in the Settings on the OPC GWY PC you have disabled the Time Synchronization, otherwise the OPC Gateway receives Time messages from 2 Time Masters. Pleas check!
The Controller issues a Time Synchronization alarm, if the synchronization message it receives has a time difference of 1 second or more to its own internal time.
That could happen, if a) there are 2 time masters in the system, which are not synchronized and have a difference of 1 second or more, or b) the OPC Gateway has too much load and the time synch messages get delayed.
If the latter is the case, consider to Time Synch the system bottom up. That means, connect the GPS to one Controller, install a dummy GWY on the Domain server and let the Domian Server PC get time synchronized by the controller (enable Time Synch in the Settings for this PC and disable Ext Time Synch in all the OPC GWY header.). Then synchronize the other 800xA stations via the domain.
in answer to your comment to my previous post:
You send the controller logs of a redundant pair of controllers, where the primary (184.108.40.206) also is the controller time master, synchronized by the gateway 220.127.116.11. So far so good.
According to your information all gateways specify 18.104.22.168 and 22.214.171.124 as controllers which will get time synced by the gateway, which is fine with regards to the controllers selected. Having every gateway doing the time sync doesn't make much sense, because when a gatway application crashes the redundant gateway will take over and when the PC crashes, all gateways on that PC will no longer work.
It is enough to have one gateway in a PC doing the time sync and the gateway redundant to the first on the second PC. In your configuration you have 2 redundant connectivity server (4 PCs) with 3 gateways each. 4 gateways having the Ext. Time Sync configuration (2 redundant gateways) is enough.
Looking at the diagnostic files we see for 126.96.36.199 (the primary controller)
Time Sync Statistics
GwySync active GwyServer : 188.8.131.52
ms: 0 0 0 0 0 0 0 0 0 0 0 0 -10 -9 -1
and for the secondary controller 184.108.40.206
Time Sync Statistics
Active Server: #1 (220.127.116.11) with Gateway Server
GwySync passive GwyServer : 18.104.22.168
ms: 15 5 42 191 210 294 173 91 -2 -43 -43 -690 -232 -10 -3
The bold numbers are a time correction history for that controller. Each number shows the time difference in ms that needs to be corrected and the sample time in the history is 1 minute. So we see a time set history of the last 15 minutes.
Now, the difference between the history in the primary and secondary controller is interesting but explainable. If the time difference exceeds 699 ms, the controller will hard set the time, which also creates an entry in the Error FiFo (Time set by high diff), which in your case is full of those time set errors. For time differences below 700ms the controllers tune their "time quartz" to run faster or slower. In case the time is set hard, the time synch history is reset and will restart with all entries 0.
That happened in the primary approx 3-4 minutes before you retrieved the diagnostics file, so most of its entries are 0. The time was set hard by receiving a time sync message from the gateway.
The secondary also gets the time sync message from the gateway, but discards it, because it is not the active time master. Instead it gets the time from 22.214.171.124. But within the control net the controller calculate an average of the last 4 time sync message, thereby filtering out spikes. The -690 in the secondary's time sync history is the averaged spike corresponding to the hard time set in the primary. But here in the secondary the averaged (down) difference is not enough to trigger a hard time set (threshold is 700ms) and consequently we keep the history.
That is good, because we see something interesting. The first half of the numbers are positive and the second half is negative, indicating a periodic function of the time signal send out by the gateway 126.96.36.199. That gateway seems to have a bad clock that runs away over several minutes, before it is caught by the domain server time sync which sets it back rather harsh, triggering the time sets alarm. It also seems to me that the peak of the periodic function (or how far the time in the gateway runs away before it is corrected by the domain server) lies mostly under 700ms but close to it, thus sometimes creating a hard time set, at other times not.
I propose to move the time sync function from the current PC of 188.8.131.52 to the other active connectivity server PC, to see if that PC behaves better. To do that, disable the Ext. Time Sync. configurations in all gateways except in one of the three gateways on the other Connectivity server PC and its redundant gateway counter part.
Another way would be to reduce the interval by which the domain server synchronizes the gateways so the gateway does not run into the 700 ms time difference area.
Hope that helps.