Trend Display
Good day,
Does somebody has seen the the trend traces behaviour where the traces are dotted and in one case one of the traces is going in the future? It is a System 800xA 6.0.3-2 with advant master connect, and the logs configuration are recording the data and all of them are good quality, so we have not loss data in the basic history server. This behaviour is not for all signals in the trends display. The logs configuration, for the basic history service, are configured for 7 days but now the trend displays are showing well only 2 hour of data.
I appreciate any information about the rare behaviour in the trends display.
Regards and Thanks in advance.
Does somebody has seen the the trend traces behaviour where the traces are dotted and in one case one of the traces is going in the future? It is a System 800xA 6.0.3-2 with advant master connect, and the logs configuration are recording the data and all of them are good quality, so we have not loss data in the basic history server. This behaviour is not for all signals in the trends display. The logs configuration, for the basic history service, are configured for 7 days but now the trend displays are showing well only 2 hour of data.
I appreciate any information about the rare behaviour in the trends display.
Regards and Thanks in advance.
Asked 1 month ago
Answers
0
Do only use 1, 3 or 9 second Min Time for properties coming from 800xA for Advant Master.
Avoid slower rates unless really really slow like 60 seconds or slower. Setting 10 seconds or above is no good at all since the MB300 OPC server is then forced to PULL EVERY SAMPLE OUT OF THE CONTROLLER instead of enjoying a relaxed subscription. At 60+ seconds (the higher the better) the negative effects of these PULL EVERY SAMPLE is reduced.
A 9 second log is more efficient than a 90 second log due to the extra work required to PULL SAMPLES instead of subscribing for cyclic data. Advant Master controllers can only pump at 1, 3 and 9 seconds.
The image of the data on the status tab may indicate you have set a Max Time set (to get samples recorded, even if they are not changing). This is OK (but never set Max Time equal to Min Time, always set a higher Max Time).
I'm guessing you had a "future time event" when something set the clocks forward. When this happen, Basic History will extrapolate "missing" data into logs with a Max Time set, as required. This extrapolation "burns space" in the log (only fitting the number of samples given by Storage Period/Min Time).
Maybe this forward time event happened some time ago and you did not notice it (there seem to be no future time recorded now, at least not in the primary 2s7d log, I suggest checking all levels if the hierarchy; if you can find data with a future time - there is one possible culprit).
Have you checked if the \OperateITData\History\{some GUID}\*.log files have a recent CREATION TIME? If so, someone might have tampered with your Log Configuration, e.g. some actions made in the History Source aspect may erase all logs and start off with new empty files. Check modification time (and user!) on the History Source, Log Template and Log Confíguration aspects. If someone touched them, you will notice the modification time being recent. If that time coincide with the data loss...
Make sure your system is properly configured in terms of Clock Synchronization. There are many examples given in the Network User's Guide. Implement one of them. I recommend turning OFF the possibility for human intervention in System Time by unchecking the "Allow clients to set time" on the AfwTime Service's Special Configuration tab. Then let some computer govern the clock; or get a GPS time which you can convert to MB300 using an AC 800M and a CI855 MB300 module. Reverse Time Synchronization is less desirable for more than one reason.
If you need more help, I would be happy to assist you via a regular support case which you must first file with your regional ABB support center.
Avoid slower rates unless really really slow like 60 seconds or slower. Setting 10 seconds or above is no good at all since the MB300 OPC server is then forced to PULL EVERY SAMPLE OUT OF THE CONTROLLER instead of enjoying a relaxed subscription. At 60+ seconds (the higher the better) the negative effects of these PULL EVERY SAMPLE is reduced.
A 9 second log is more efficient than a 90 second log due to the extra work required to PULL SAMPLES instead of subscribing for cyclic data. Advant Master controllers can only pump at 1, 3 and 9 seconds.
The image of the data on the status tab may indicate you have set a Max Time set (to get samples recorded, even if they are not changing). This is OK (but never set Max Time equal to Min Time, always set a higher Max Time).
I'm guessing you had a "future time event" when something set the clocks forward. When this happen, Basic History will extrapolate "missing" data into logs with a Max Time set, as required. This extrapolation "burns space" in the log (only fitting the number of samples given by Storage Period/Min Time).
Maybe this forward time event happened some time ago and you did not notice it (there seem to be no future time recorded now, at least not in the primary 2s7d log, I suggest checking all levels if the hierarchy; if you can find data with a future time - there is one possible culprit).
Have you checked if the \OperateITData\History\{some GUID}\*.log files have a recent CREATION TIME? If so, someone might have tampered with your Log Configuration, e.g. some actions made in the History Source aspect may erase all logs and start off with new empty files. Check modification time (and user!) on the History Source, Log Template and Log Confíguration aspects. If someone touched them, you will notice the modification time being recent. If that time coincide with the data loss...
Make sure your system is properly configured in terms of Clock Synchronization. There are many examples given in the Network User's Guide. Implement one of them. I recommend turning OFF the possibility for human intervention in System Time by unchecking the "Allow clients to set time" on the AfwTime Service's Special Configuration tab. Then let some computer govern the clock; or get a GPS time which you can convert to MB300 using an AC 800M and a CI855 MB300 module. Reverse Time Synchronization is less desirable for more than one reason.
If you need more help, I would be happy to assist you via a regular support case which you must first file with your regional ABB support center.
by aravind12a6 Rank: 149 on 8/18/2020 5:58:06 AM | Like (0) | Report
Is the treatment selected as Extmomentary?
by David Greening Rank: 222 on 8/18/2020 6:11:30 AM | Like (0) | Report
If this is Advant - are you using RTA boards (PU410)? - your collect rate is 2s - the manual says 9s or multiples of that.
by CarlosQ Rank: 176 on 8/18/2020 6:24:06 AM | Like (0) | Report
@aravind12a6; Yes, the treatment selected is ExtMomentary.
@David greening; Yes we are using a PU410. The log configuration is a copy of one that is comming with the APC Library (Advant Power Connect Library), so I think that the collect rate of 2s should be good.
Add new comment