Easy Chart: Accessing the Datasets Being Rendered

In the past I have gotten some information on accessing the internal JFreeChart component that powers the Easy Chart. Now I have a question on getting at a hidden piece that I believe exists between the chart module and the Ignition world – the datasets that represent the data that is actually being passed into (and subsequently rendered) by the chart module.

For example, I have some tag history pens defined. There is a particular functionality (display) I want to add based on the data being plotted. Theoretically I could issue a call to system.tag.queryTagHistory() using the ranges and such set on the Easy Chart component, but that would be inefficient since I’ve already paid the resource penalty to power the chart with that data. Especially since this could involve a number of pens (a lot). So for this reason, I would much rather just get at the data datasets attached to the pens (i.e. rows within the tagPens dataset).

No early takers? In any case, aside from this, I wanted to clarify I mis-stated the access to the JFreeChart internals when using the Easy Chart. So far this appears only available on regular chart components. So now this is one deeper. I can understand some might make the argument to roll my own charting, but why reinvent the wheel? Easy Chart already has all the buttons, pen/axis control, time sliders, realtime control, etc. I don’t want to reroll all that just so I can get at the data and chart object (which is under the covers there somewhere)… Help?!

I’m a bit confused. Did the EasyChart object’s methods of getTagPens() and setTagPens(Dataset tagPens) not work?


Sorry, that might have been confusing the way I worded it … I am -not- after the pen definitions, I am after the DATA that the Easy Chart has collected to render. I want to have direct access to exactly what it is that the chart module is rendering. Some have said “well go execute a call to system.tag.queryTagHistory()” – well that might work for some, but I would really rather have the exact same data. Not only that, but also there must be an internal table in use for calculated and/or DB pens… That goes beyond my original post, but hopefully this clarifies it: “I would like to get direct access to whatever internal datasets are being built and fed to JFreeChart.” Reason? To add some specific features not currently available in the Easy Chart component.

PS> And of course there is still the issue of getting at the JFreeChart instance that is in the Easy Chart component (a la the standard Chart component .getChart()).


I am -not- after the pen definitions, I am after the DATA that the Easy Chart has collected to render. Derp. Of course.
That won’t be simple to get at, even if it were exposed. Taking a brief look at the code, it would not be trivial to expose that in a way that you could get at the pen data, alter it, and reinsert it, all while being reasonably sure you weren’t causing complete havoc. :neutral_face: Not saying it’s impossible, just that it’s not trivial.

[quote]And of course there is still the issue of getting at the JFreeChart instance that is in the Easy Chart component (a la the standard Chart component .getChart())[/quote] Yeah, that doesn’t have a public accessor, I imagine for the same reasons that the pens don’t.


First I appreciate the discussion. But to continue on this… So there is nothing I can get at within the underlying class structure? That the component might have some internal dataset for what is being retrieved and pushed into JFreeChart? Or are you saying that it was constructed with most of this stuff deeply buried within the component’s code? Separately, is there a fundamental difference in the component’s architecture that makes it hard to get at the chart instance as one can with the standard Chart component? Both limitations are, well, very limiting…

Here’s some examples:

I want a table to display min/max/avg of the values plotted within the chart. Trivial if I can get at the active datasets. Without it, much more difficult without having to essentially re-query everything. If one can get right at the same data, you can keep such additional functionality in total parity with the rendered chart and not have a re-query penalty for larger datasets.

I would like to customize the JFreeChart in ways only attainable by direct access (a la chart.getChart() type access). One example is to toggle off the visibility of an axis label without toggling off the pen itself (somewhat like a sparkline which has no axis label).

So I’m open to alternates/workarounds, but hope you can see where I was trying to go here which is fueling my inquiry… Thanks again for the discussion on this.

Try using the Easy Chart Customizer:


I am well aware of adding a calculated pen… It is the data for such pens that I am discussing the need to access. So to your point, if I add the pens you illustrated, I want the data that is being plotted – not just a line on my chart. I need the actual tabular data, not just a plot.

Good morning JJ,

I can help you find the JFreeChart, but I think you are going to be disappointed: the chart doesn’t contain normal datasets. The EasyChart munges large datasets before loading them, so the data you’ll be able to obtain may not be complete. With that caveat, here’s how I find the JFreeChart when I need it:

def findJFChart(src): """IA's EasyChart and XYPlot components have their JFreeChart objects at different positions in the Container/Component hierarchy. This helper function scans the hierarchy, given a container or component as a starting point, and returns a tuple containing the parent JFreeChartPanel and the targeted JFreeChart. Note: The hierarchy is searched depth-first! """ from app.scriptmodule import findJFChart try: return (src, src.chart) except: pass try: for x in range(src.componentCount): try: return findJFChart(src.getComponent(x)) except: pass except: pass raise ValueError, "Unable to Find a JFreeChart Instance"
The code makes one major assumption: that the first property named “chart” that it encounters is the desired JFreeChart. If that isn’t sufficient, you would need to add type-checking of that property.

Hope this helps!