Core Historian history binding intermittently returns incorrect leading & trailing zero values

We recently migrated one location from the Internal Historian to the new Core Historian available in 8.3 as we were bumping up against performance limits on the Internal Historian. We immediately noticed an issue on Perspective Sparkline charts.

The 3 oldest points with zero values should not be zero; top sparkline should look more like the bottom one (more on that below). We get between none and quite a few of these zero values with each refresh. It appears likely we’re getting zeros from start of realtime history window until the first value within window recorded in tag history (we get more leading zeroes with wider analog deadband and/or higher maximum sample intervals). We also get a zero value at newest value sometimes, though this happens less often. We did not encounter either of these problems with the old Internal Historian on the same tags, same history configuration, and same sparkline tag history bindings (except for path update required on switch from Internal to Core Historian).

For now, we are working around these issues on sparklines with a crude transform that doesn’t accurately address every case, but for the most part makes the sparklines useful to operators again. We applied this transform on the upper sparkline’s tag history binding results to produce the dataset for the lower sparkline above seen by operators:

def transform(self, value, quality, timestamp):
	filtered = [row for row in value if row[1] != 0.0]
	headers = list(value.getColumnNames())
	
	# Set last row to current value.
	lastRow = list(value[-1])
	lastRow[1] = self.custom.currentValue
	filtered.append(lastRow)
	
	# Set first row to previous oldest value if it is zero.
	firstRow = list(value[0])
	if firstRow[1] == 0.0:
		firstRow[1] = self.custom.oldestValuePrevious
		filtered.insert(0, firstRow)
	
	# Update oldest value for next cycle.
	self.custom.oldestValuePrevious = firstRow[1] if len(filtered) > 2 or self.custom.currentValue != 0.0 else 0.0
	
	return system.dataset.toDataset(headers, filtered)

This issue also affects other charts:

Here we expand the above chart window to view the last 12 hours and see that older data that should have been displayed on the left (oldest) side of last 4 hour PowerChart was present in history, but not returned to PowerChart by Core Historian:

It looks like @hlam ran into this issue too (from post here):

I also encountered a different bug when working with the aggregation tag history binding, where I’m getting 0 values between the initial time (doesn’t matter if its time or # of points) and the first valid data point.

We are hoping for a near future 8.3.x fix so tag history bindings to Core Historian behave like they did to Internal Historian (chart starts with most recent old value prior to chart window if no sample present at start of window and ends with current value, instead of substituting zeroes for one or both).

1 Like

Just to fill in a bit of the data on what I had submitted to support (I still have not seen a response on this specific topic as it was combined with my ticket about the timestamp issues)

This exact behavior occurs with the aggregation mode of either MinMax or Average. Query Mode being PointCount or Periodic (no difference in behavior). If you analyze the data in “Tall” format, you essentially get 0’s with a quality of -2147483129 (Bad_NotFound).

If I change the aggregation mode to Last Value or Simple Average, this is even worse, because we have a initial null data point with a bad quality (-2147483129), and then zeros with good quality (192) data points until we hit the most recent sample in the historian.

Essentially, between the Timestamp bugs and the aggregation bugs, it renders all of my Sparklines and Time Scale trends inaccurate.

1 Like

Sounds a lot line this topic

Core Historian - Realtime glitch? - Ignition - Inductive Automation Forum

Looks like a bug that is fixed in the latest nightly release.

1 Like

That looks like it may apply, though it’s unclear as symptoms here are quite different than the post you linked. We’ll have to try 8.3.5 when stable version is released.