Timestamp Inspector is a visual diagnostics tool to help a PI Admin easily and quickly detect duplicate events or events with subsecond timestamps in the PI Data Archive. The primary emphasis is on examination of the timestamps and less emphasis on the quality of the values.
Windows Form application written in C# 6.0, using AF SDK.
Consider one sample page from PI-SMT. Take time to read the list below. How fast can you find all the duplicate events?
Did it take you more than 5 seconds? Imagine if you have 5 dozen screens to scroll through. Talk about eye fatigue!
Were you able to detect there are 5 duplicate sets? Congratulations ... but you would be wrong. There are actually only 3 duplicate sets of events, marked in red outline below. Two other sets of data, marked in green, only appear to be duplicates. Because we are only showing whole seconds in PI-SMT, when the ones in green have subseconds to consider, it is a visual illusion that they are duplicates.
Let’s look at the same page again, but this time with Timestamp Inspector.
Thanks to the shading, it’s very easy to see which sets of events are duplicates. And it’s equally easy to see which events have subseconds thanks to bolding. Granted seeing subseconds near 11:50 and 11:55 may pose a new set of perplexing questions such as "How did those get there?!", but the key feature of Timestamp Inspector is that a PI Admin can quickly determine such valuable information about the events.
App CONFIG Options
You probably will not need to change the run time settings, but in case you do, here is what they look like:
<setting name="PointLimit" serializeAs="String">
<setting name="TargetEventCount" serializeAs="String">
<setting name="SkipEventCount" serializeAs="String">
PointLimit restricts the number of tags loaded into the PIPoint ComboBox. There’s no reason to wait 5 minutes for a ComboBox to load 100,000 items.
TargetEventCount an estimate of how many values to include in a given RecordedValues call. Instead of one huge RecordedValues call, the time range is broken up into smaller subranges based upon this value. The smaller the value, the more trips to the data archive. A larger value means fewer trips, but also means a longer delay in provided feedback to the UI.
SkipEventCount controls whether or not the Summary event count occurs before retrieving archive values. If you skip this, there will only be one huge RecordedValues call which also means the progress bars will be disabled.
TargetEventCount is only an Estimation
The resulting RecordedValues calls do not limit themselves to TargetEventCount values. The logic employed uses the assumption that the events are fairly evenly distributed across the full time range. A Summary call is first made to count the actual events. That number is divided by TargetEventCount and rounded up to produce the number of RecordedValues calls to make. The full time range is then partitioned into the necessary number of subranges to produce that number of calls. As such, there is a possibility that any given RecordedValues call may return substantially more or less events than estimated by TargetEventCount.
The purpose behind this was to establish a mechanism to demonstrate how to cancel an async event. Since this required breaking up into many calls, it was a natural fit to tie this into progress bars that provides more visual feedback to the user.