Ignition version:8.3.4
Approximate selected time range:8h
Tag history provider: Core Historian
I am working in Ignition Perspective and I am using a Time Series Chart to display historical data for a selected tag.
The chart is bound using Tag History, so it returns a dataset with the history of the selected tag. The time range is configured by the user with:
a numeric input field, where the user enters the amount of time
a dropdown menu, where the user selects the time unit, for example minutes, hours, days, etc.
The idea is similar to how the time range selection works in the Power Chart.
My main issue is that when the view/chart is opened or time range is changed, the tag history takes a very long time to load. I am trying to understand why the loading time is so long and what the recommended approach would be to improve it.
Is there a way to reduce the loading time of the historical data in a Time Series Chart?
Are there any best practices for using Tag History bindings with Perspective Time Series Charts, especially when the time range is selected dynamically by the user?
Some specific areas I am wondering about are:
limiting the amount of returned data
using aggregation instead of raw values
choosing a suitable interval or sample size
avoiding expensive queries when the view first opens
whether the Power Chart handles this differently than a manually configured Time Series Chart
Any advice or examples of best practices would be appreciated.
I have also attached screenshots of my current chart settings, Tag History binding configuration, and the input/dropdown components used to define the time range.
If any additional information is needed, such as the Ignition version, database type, tag history provider settings, query mode, sample size, or example tag configuration, I can provide it afterward.
Your min time between samples is set to 100ms and you've opted to return asStored data. This dataset could be HUGE. You will either need to cap the time period to be VERY short, or change the return size to not use as stored and return a fixed number of samples.
I would cut down the maximum number of returned datapoints, do you need to show ~11k on a single chart? Try going to 1,000 to 2,000 and see how it performs.
On the gateway, you can see what queries are taking awhile to execute, it could be that the query is taking longer than 1 second to execute and your compounding the issue with your 1 second refresh rate.
In my experience, with some logging to help, I found the history binding executes for tens of thousands of points in a snap (sub second) and the UI component chews on it for 100x the time.
Yup, exactly. Apex gets crushed extremely quickly for large datasets.
That agrees with my experience, 30k is pretty reasonable.
A really nice feature of Chart.js is its data decimation plugin:
The default setting for the Embr Charts Chart.js component is to decimate to 1 sample per pixel, across the width of the chart. In other words, it won't render more points than pixels.
There are some restrictions on when Data Decimation will occur though, so I'd recommend reading the docs above.
Edit: Actually I'll just post them here
To use the decimation plugin, the following requirements must be met:
Later during the day, as I looked deeper into this issue, I also came to the conclusion that the main problem is actually the amount of data that needs to be displayed. Because of this, I decided to change the way historical data is collected.
Specifically, I am considering changing the deadband mode to percentage. However, I still need to research what these percentages are based on. I assume that 100% represents the scale between the Engineering Low Limit and the Engineering High Limit, but I still need to confirm this.
I will also change the minimum time between data captures and the maximum time between data captures, but I still need to investigate what time intervals are most suitable for my measurements.
The measurements I have include various temperatures, water turbidity, flows, pressures, electrical current measurements, and VFD speed measurements.
With these changes, I believe the system performance should improve. However, if you have any other ideas, I am also willing to try them.
If these changes do not work, I will also try experimenting with Data Decimation.
