Openhistorian d2 files

Hello,
Openhistorian saves the data in the d2 files, it happens that some PMU lose the synchronization and send a timestamp with 1970-01-01, in this case some anomalous files are created. The file d2 can be unrelated from the timestamp date ?

Best Regards,
Pietro

Hello Pietro,

The historian adapter has a flag that can be adjusted via the connection string called EnableTimeReasonabilityCheck. If you add EnableTimeReasonabilityCheck=true to the connection string for your historian adapter, it will only accept measurements that are within 12 hours of the server’s local clock. This will cause the measurements with 1970-01-01 timestamps will be filtered out at the gate so they will not be stored in the archive.

Thanks,
Stephen

Hello Stephen,
I edit connection string with the flags EnableTimeReasonabilityCheck and also PastTimeReasonabilityCheck=43200 and FutureTimeReasonabilityCheck = 43200.
A few months ago I had entered “MaximumArchiveDays=7;” but I think it does not work because I have 9 months saved inside archive.

ArchiveDirectories=E:\Archive;
MaximumArchiveDays=7;
WorkingDirectory=E:\TempArchive;
EnableTimeReasonabilityCheck=True;
FutureTimeReasonabilityLimit=43200;
PastTimeReasonabilityLimit=43200;

Ciao
Pietro

The MaximumArchiveDays parameter is handled through the CurtailArchiveFiles() method. This method is called on a timer once per day, starting from the day after the adapter was last initialized. If you look at the code, there are messages produced by the adapter when the method is invoked. These messages can help you determine whether the curtailment process is working properly. You should be able to locate these messages in the StatusLog.txt file.

If you are unable to find the messages in StatusLog.txt, you can also force the method to be invoked by entering the following command into the openHistorian Console: INVOKE PPA CurtailArchiveFiles. By doing that, you should be able to see the output of the command directly in the console to help determine what the problem might be.

Thanks,
Stephen