I believe the answer is no, but maybe someone has already done or has an idea for how to implement an ad-hoc trending tool with the cool features that PowerChart has (tag browser and aggregation mode for longer timeframes) but with the flexibility to populate the chart with a sproc like you can with a Time Series chart.
Also, does PowerChart's aggregation mode depend on having the 'Enable Pre-processed Partitions' checkbox checked to return min, max, avg etc from the database or will Ignition generate SQL to calculate this on the fly if the pre-processed partition doesn't exist?
Honestly, I’ve looked at the SQL that PowerChart generates in our SQL profiler and it’s pretty rough - like prototype rough, not a polished final product at all. When doing a live chart, it will do about 3 database transactions just to figure out what partition it needs to query from (even if there’s only one) and then it refreshs the whole frame rather than just refreshing the last few seconds (or whatever live interval you have) and pushing the oldest part of the trend off the back. I’d file a database hurt feelings report if I knew where to send it.
You are correct; the power chart is limited to only work with the historian, not raw datasets.
No, the historian will run whatever aggregation queries it needs to.
This is a hair split, but a distinction worth teasing out.
The powerchart doesn't generate any SQL. The only thing the power chart "knows" about are the history providers configured on the gateway; it's operating a layer of abstraction up from any raw SQL. This is good for flexibility (there are first and third party modules that don't use SQL databases at all for history storage) but bad for some kinds of optimization.
This is necessary due to the architecture of the historian. One database can be used by any number of gateways to store history, and the SQL historian must run those extra queries to determine where the history for this particular tag, in this particular tag provider, on this particular gateway, is storing history. Imagine the disaster if you started getting another set of tag history silently just because of a name collision.
This one I don't have an excuse for. Vision does exactly this optimization in its history querying, but it may have never made it to Perspective or it may not be working.