ARCHIVER FOLDER
cosimopis opened this issue · 8 comments
Hi Cosimo,
Is it possible that one of your input devices is reporting timestamps in 1970? It does seem suspiciously close to the Unix epoch, so maybe it's an error code. If you navigate into the folder, the names of the files should give you an idea of the full time range of the data in each file.
Thanks,
Stephen
Hi Stephen,
thank you for your prompty reply as usual. The situation is exactly the one I show you with the following snapshot:
Is there a manner via OpenPDC to discover which device is characterized by wrong timestamp?
If I understood what you told me there are two devices with minimum timestamp 1970 and maximum 2036. Correct?
Thanks
When we were having this problem with some of our devices, we found that there actually aren't any displays in the openPDC that allow you to see the date of the timestamps reported by input devices. We had to use the openHistorian to export data from the time range in question to find which devices reported data during that time. Ritchie has since added a feature to the Trend/Export Measurements page of openHistorian where you can mouse over a value in the "Current Value" column to see the full date and time of the value being displayed.
Currently, there are still no displays in the openPDC that can be used to display the date of the input devices' timestamps.
Great I will follow your suggestion!
Hi Stephen,
I followed your approach, unfortunately it seems that there is no wrong timestamp.
Is there a manner to automatically discard measurements not aligned with local time in openPDC?
Or, alternatively, if the tiemstamp is wrong, is there a manner to fix the timestamp at the local time?
Please let me know.
Kind regards,
Cosimo
....and additionally. Due to this issue, could the circular archiving fail? I mean that the timestamp misalignment could affect the correct removal of old data?
Regards
A file with a timestamp of 1970 can occur when anytime when timestamp is received from a PMU that has a bad time - this could occur when a device connected with a bad configuration frame / unlocked clock but has since been corrected.
How large is the file with the 1970 timestamp - does the file modification time continue to grow? Perhaps this was a temporary issue related to a clock?
Are all your devices ABB's reporting with IEEE 1344? Or do you have a protocol mix that includes IEEE C37.118?
Thanks,
Ritchie
Hi Ritchie,
the situation is this:
[cid:image001.png@01D24568.6D1D5580]
The oldest file has “Date modified” 17/10/2016 10:05. It seems that the cyclical deleting set at 20 days does not work properly.
We have some PMU reporting with IEEE 1344 and other with C37.118 protocol…
Any suggestion to fix?
Kind regards,
Cosimo