Information Management - History Not Getting Logged for Specified Duration
Voted best answer
Cannot open PDF from iPad but the symptom you describe may arise if you create a secondary log of Type 5 using ”STORE_AS_IS” calculation method of IM History to a primary log in Basic History without matching the update rate of the primary log.
- Primary Log (Basic History): Min Time 5 seconds
- Secondary Log (IM History): Sample Interval 10 seconds, STORE_AS_IS, Type 5, Log Period 90 days
Effect: IM will store data every 5 seconds (while expecting every 10 seconds). Log Period will be cut by roughly 50% (depending on regularity of primary log’s feed from OPC server)
Solution: match rates between primary and secondary logs or set secondary log with another calculation method, eg AVERAGE instead of STORE_AS_IS.
So, this is the setup:
OPC Log: Min Time 1 s, Max. Time 5s
IM Log: Sample Rate 5 s, Storage Rate 5 s, Store As Is
I can only agree with Stefan's answer: This set up will give very random outcomes. If you use Stor As Is in the IM Log it should match the storage interval of the source log, if not, use another algorithm (average..) in the IM log. If the primary (OPC) Log has not stored a value at the time the IM log wants it, well...
As you found, there is nothing wrong with the IM, it just tries to do its best with a bad set up.
A way often used (by me and others) is to use Store As Is in the IM with a sample time matching the the minimum storage time of the source log. Also, I would use a larger factor between the minimum and the maximum storage time, which gives even greater data depth if the values do not change (much) between samples.The IM will store values exactly as the are stored in the OPC Log with Store As Is (If the sample time of OPC and IM logs match).
Otherwise, store an average in the IM Log. What elect to do will depend on what the data is going to be used for and how fast it actually needs to be sampled.