Customizable Graphs! Better Graphs

Hi Everyone!

A few months ago I posted looking for some customizable graph windows. What I found was there was ‘click to graph’, a package from Inductive Automation that didn’t quite work the way I wanted (yet) and was also a bit dated. So I took that and reworked it, and now want to share my work with you! I’ve called it ‘Better Graphs’ and you can check out the user guide (which can also be shared with your operators so they know what everything does):

The major change that I’ve made is that before, most of the configuration was being stored in SQL and was being passed back and forth. I moved the live data of a chart configuration over to client tags, and use sql only for storing and recalling graphs. Also, before not everything was being saved, and I’ve modified it so that absolutely all the parameters of a tag pen, axes, and subplots are saved and recalled.

I’ve made a text installation guide that’s included with all the other files you need, as well as a youtube video to walk you through quickly how to set it up. You can check out everything and find the link to download (on github) here:

If you want to contribute, follow the link above to my GitHub page.


Consider moving your runtime settings from client tags to root container properties of the chart windows themselves. That allows you to open more than one chart window at a time, and provides a convenient hook to open a chart with a preset collection of pens. When opening popups to configure a specific chart, you can use a client property in the popup to hold a weak reference to the origin chart window, so the settings go back to the correct chart.


When the React Perspective vision module is released, the client side will shift to React platform. Java client and components will become obsolete. You can build awesome components and UI with React. I think, developing components on ReactJS will bring more value for SIs.

None of this is true, and to anyone reading this thread in the future, @R.Alamsha is not an Inductive Automation employee; please keep that in mind.


Let me also say it once again. I am NOT an employee of IA. I am just an Ignition SI living 1000’s of kms away from US. I was little bit overenthusiastic about Ignition because of the stability, flexibility and freedom which i didn’t find in any other SCADA product till date. I have personally convinced and brought many SI’s to Ignition. I have done something good for Ignition because i like the product. Nothing else whatsoever.

I have lot of respect for JAVA programmers and i am sure that they can easily cope up with any disruption in technology and deal with any other programming language effortlessly. Having said this, i would definitely prefer a non-java solution because i don’t want to pay ransom to Oracle.

Today, when i see any third party JAVA solution for Ignition, the first thing pops up in my mind is "does it have any Oracle JAVA component?.. better stay away…"

This JAVA fear is spreading across and haunting the minds of many SMB software vendors and end users. You can ask your Ignition core developers, how much hard are they working to bail out the clients from the grip of JAVA Oracle. Thanks.

Looks very impressive! I’ve downloaded it, will test it out when I get some time. Thanks for posting