Configuring PowerChart Historian Trends in Ignition

After separating historian-backed trending from stored-procedure reporting, PowerChart can deliver tag browsing and aggregated history without treating it as a general SQL chart. Use a custom time-series component when the displayed series must come from a stored procedure or when live updates must fetch only the newest interval.

1. Data-path selection

Before anything else, confirm where the required values originate. PowerChart accepts tag history through a history provider configured on the Ignition Gateway. It does not accept a raw dataset returned by a stored procedure.

Do not build a stored-procedure adapter around PowerChart and expect it to retain native tag browsing. Those are different data contracts. Record the chosen path as either historian-backed PowerChart or query-backed custom chart. Do not move on until every required series belongs to one path.

2. History-provider validation

1. Open the Gateway configuration and identify the history provider used by the project.
2. Confirm that each required tag records history into that provider.
3. Query a short completed time range for one tag. Use a completed range first so changing live data cannot hide gaps or duplicate samples.
4. Compare the returned timestamps and values with the tag history diagnostic tools available on the Gateway.

PowerChart operates above the SQL layer. It requests history from the configured provider and does not construct database-specific SQL itself. A provider may use a first-party SQL historian, another history module, or storage that is not SQL-based. Consequently, SQL captured by a profiler belongs to the historian implementation serving the request, not to chart-side query generation.

The installation associated with the reported behavior used Ignition 8.3.2, Microsoft SQL Server, and JDBC driver 13.2.1. Treat those identifiers as the commissioning baseline for that installation, not as a universal affected-version range.

The check is a successful short-range history request for every required tag through the same provider PowerChart will use. Resolve missing or misrouted history before adding chart pens.

3. Pen and tag-identity configuration

1. Add one known tag to PowerChart through its tag browser.
2. Select a range containing known historical changes.
3. Confirm that the displayed values belong to the intended Gateway, tag provider, and tag path.
4. Add the remaining pens one at a time and repeat the identity check.

A SQL historian cannot safely select data by a visible tag name alone. One database can receive history from multiple Gateways and tag providers, so the historian must resolve the complete historical identity before selecting the physical partition. That lookup prevents a same-named tag from another source from being returned silently.

Do not move on until every pen returns the correct signal and the complete identity is unambiguous.

4. Aggregation and partition behavior

1. Choose a completed range long enough to require fewer displayed points than stored samples.
2. Select the required aggregation mode, such as minimum, maximum, or average.
3. Run the request with the current partition configuration.
4. Check the result for the expected aggregate shape and inspect historian or database diagnostics for failures.
5. Test the pre-processed-partition option separately as a performance change, not as a requirement for aggregation correctness.

The Enable Pre-processed Partitions setting is not the switch that grants PowerChart access to minimum, maximum, or average data. PowerChart asks the history subsystem for aggregated history, and the historian runs the queries needed to answer that request. When pre-processed data is unavailable, the SQL historian can perform the required aggregation work against stored history.

Pre-processing and on-demand aggregation can have different storage, write, and read costs. Measure those costs on the actual schema and representative ranges. Capture elapsed query time, rows processed, database CPU, and returned point count before changing the setting; then repeat the identical chart request after the change. A faster short query does not prove that long-range production queries will meet the target.

The check is correct minimum, maximum, or average output for a known interval without relying on the checkbox as a functional prerequisite. Do not move on until the aggregate values and database cost are both acceptable.

5. Live-window database load

1. Set the intended live display duration and refresh behavior in PowerChart.
2. Start database profiling immediately before opening the live chart.
3. Record the requested start and end bounds for several consecutive refreshes.
4. Separate metadata and partition-discovery transactions from the transaction that reads samples.
5. Compare the second and later sample requests with the first visible frame.

About three preliminary database transactions were observed while the SQL historian determined which partition held the requested tag history, even when only one partition existed. The architecture still requires identity and partition resolution because the database may contain history written by multiple Gateways and providers.

The more consequential pattern is a repeated request for the whole visible frame. An incremental live query would request only data after the last accepted sample, append it, advance the range, and discard expired points. The observed Perspective PowerChart behavior refreshed the frame instead. A comparable incremental optimization exists in Vision history querying, but its presence there does not prove that the Perspective component applies it.

Classify the load from measured query bounds. If each refresh advances both bounds while retaining the same window width yet rereads the entire interval, treat full-window retrieval as the working behavior for capacity planning. The check is a profiler capture that identifies the number, bounds, duration, and frequency of requests under the intended live load.

6. Stored-procedure decision point

Keep PowerChart when tag browsing, historian abstraction, and built-in aggregation are the controlling requirements. Change components when the database procedure defines the series, joins non-historian records, applies application-specific calculations, or must control incremental retrieval.

1. Define the stored procedure's inputs: visible start, visible end, requested density, and series selection.
2. Define the returned fields: timestamp, value, and a stable series identity when multiple pens share one result.
3. Require timestamps in ascending order and choose one timestamp convention across the Gateway and browser.
4. Reject duplicate timestamps or define a deterministic replacement rule.
5. Bind the dataset to a component designed for arbitrary time-series data.

A custom chart cannot automatically inherit PowerChart's historian tag browser merely because its result has timestamp and value columns. If interactive selection remains mandatory, create a separate series catalog and map each selection to an allowed query. Keep that mapping on the Gateway so browser input cannot choose arbitrary SQL objects.

The check is a fixed-range procedure call that returns ordered, correctly labeled points and produces the same chart after two identical executions.

7. Incremental custom-chart workflow

1. Install the chart lifecycle hook and create its cache during initialization.
2. On mount, request history for the initial visible range.
3. Calculate display density from the visible duration and chart width. The demonstrated design targets approximately one data point per pixel.
4. When a pan or zoom exposes a gap, send the requested start, end, and density to the Gateway.
5. Insert the returned chunk into the cache. Preserve equal- or higher-density data and replace overlapping lower-density portions.
6. Merge points by timestamp, sort them in ascending order, and redraw without animation when high update rates make animation unnecessary.
7. For live mode, start a polling event, request only data newer than the last accepted timestamp, append the response, advance the range, and prune points older than the window start.
8. Store the polling handle and stop it during component teardown so closed views do not continue querying the Gateway.

Track in-flight ranges as well as cached ranges. Without that state, several pan, zoom, or polling events can request the same gap before the first response returns. Apply responses by timestamp and density rather than arrival order because a wide, low-density request can finish after a narrow, high-density request.

The check is a pan into uncached time that produces one Gateway request, followed by a return to the same range with no new request at the same density. A closer zoom must request denser data only for the portion that lacks it.

8. End-to-end verification

1. Open a completed range and compare raw samples with each configured aggregate.
2. Change the range across a partition boundary and confirm that pen identity remains correct.
3. Run live mode for several refresh cycles while recording database activity.
4. For PowerChart, document full-frame retrieval if the profiler shows it and size the database for that measured pattern.
5. For a custom chart, confirm that each poll begins after the last accepted point, no timestamp is duplicated, expired points leave the cache, and teardown stops polling.
6. Repeat the test with the expected number of pens and concurrent clients. Accept the design only when values, query bounds, refresh frequency, and database cost match the commissioning target.

FAQ