In the meantime. We have found a lot of success with the Embr Chart module.
You can implement features using this powerful free module that will more than likely never be implemented by IA. Both ChartJS and Apex charts are included.
Musson Industrial’s Embr-Charts Module - 3rd Party Modules - Inductive Automation Forum
Finally some good news!
Do you have more info you can share, like planned features or estimated timeline?
You may want to try out the Tag Report Utility and see if it can meet your need. I think most of the settings are parameterized so you can adapt it into your current project. It has Apex Charts but not sure if @pturmel has it on the roadmap to add Embr or Kyvis.
Yes, but not soon.
Edit: removed, I guess it is a config option
Well that’s awkward. I vaguely remember it overriding trying to set it and always going back to pan-zoom but now I’m wondering if I’m miss-remembering something else.
Gotcha. Runtime instances should default to whatever it was set to in the designer the last time you saved the project/view it’s on, and something like an onStartup event could be changing it before you get a chance to interact with it at all.
@IAIAIAIA (Edit: I don't know why it keeps replacing my single IA with 4...) - Please, when you guys develop the new chart component to replace the Power Chart, can you please fix this jittering.
In the current Power Chart, we observe significant visual "jittering" during data refreshes (e.g. every 1s poll). This appears to be caused by the component's behaviour of completely replacing the existing tag pen datasets with a new result set from the Tag History provider on every poll.
Because the history provider re-calculates samples for the entire visible time window with every query, the interpolated or aggregated data points often shift slightly – or wildly – between refreshes. This seems computationally expensive. But more concerning is that it causes operators to lose faith in the data that they’re looking at, since tag pen values can jump wildly each second between different values for exactly the same timestamp. For example in the video attached the pink pen jumps at one timestamp from ~10 to ~90 kL/h between updates.
Please transition from a destructive refresh model to an incremental/delta update model. Instead of purging the client-side cache, the component should retain existing data points within the time window, and only query for and update missing data.
(Also, pretty please remove the distinction between realtime and historical - already mentioned by me somewhere in this topic, as well as in my big ol’ document I submitted to Drew/Travis/Kevin)
