Nick Mudge Ignition Software Consulting & Development

The Perfect Abstractions Power Scripting Module has been tested and released for Ignition 7.9.

The module can be downloaded from this webpage:

Contact me to get a license.

LafargeHolcim's Technical Information System Ignition project was recently featured in the Discover Gallery at the 2016 Ignition Community Conference.

The user interface in this project was developed by Perfect Abstractions. You can see a video about it at this link: Ignition Helps Huge Company Empower Thousands of Users

Here's a brief description of some of the interesting things we did:

Dynamic Creation of Template Instances

We displayed a list of names of Ignition templates in the client. We implemented the ability for users to drag a template from the list and drop it on a window. An instance of the template would be dynamically created and placed where the user dropped it. After that the user could resize, move and configure the template. Whatever the user did it could be saved and used later. We essentially created a simplified Ignition designer in the Ignition client that regular users could use to create and save functionality. You can see this functionality in the video.

Graphics Library Integrated Into Ignition

We integrated a graphics library into Ignition that shows how things are connected to each other in a graphical, animated and interactive way. You can see this functionality in the video.

Excel in Ignition

We heavily customized an Ignition Power Table to behave and function like an Excel spreadsheet. Users can add columns and rows. Users can input values and create formulas. Users can do various text formatting like change font, color, height, change text alignment and more. Users can also drop Ignition tags into cells and see real-time values. And more can be done. You can see this functionality in the video.

This week Ignition 7.9 was released. You can find out about the new features at this link: What's New.

Also: Webinar: The New Ignition 7.9

A Perfect Abstractions Ignition Project Developer recently made a graphical interface for displaying all the available super classes and methods that exists in a component.

Sometimes it is very useful for a developer to see all that can be done with a particular component. This new object inspector helps a developer do that.

The functionality exists in a single template called TreeObjectInspector. It works directly in the Ignition designer and in clients. The template is freely available and can be imported into your own projects. The template works in Ignition 7.8.0 and up. Download here: TreeObjectInspector.proj.

Here is a screenshot of the template displaying the super classes and methods of the button component in Ignition:

The Vision Module, which is installed in Ignition by default, enables people to create Java-based graphical user interfaces. The underlying Java library that Vision Module GUIs are created upon is Java Swing. Java Swing is a standard graphics library that ships with Java, so you can learn all about it on the Internet and in books.

Because Vision Module-based GUIs are built on top of Java Swing, they follow the rules of Java Swing.

A primary rule of Java Swing is that the user interface is single threaded.

This single thread is called the Event Dispatch Thread or EDT. Code that touches the user interface is supposed to execute in the EDT. This paradigm eliminates numerous multithreading problems and hassles by not having multiple threads touch the GUI.

All the component event handling code in Ignition and the extension functions on components run in the EDT by default so you don't have to do anything special to make your code execute in the EDT. It is the default.

But if this was the end of the story there would be a big problem in Ignition GUI development. The GUI should be and needs to be very very fast - always. A slow, unresponsive GUI (even if it is just a little slow) means that a programmer didn't program it to be fast.

Some code is a little slower than very very fast, and some code is a lot slower, and there is no way around it. Database queries, requests over the network, computations over large sets of data, all these things can take awhile.

If long running code executes in the EDT then the GUI will freeze and appear slow. This is obvious since the EDT can't do anything else until it is done doing what it is currently doing. So if the EDT needs to make a database query (or other such thing) over a potentially slow network the GUI will freeze while this happens and the user will feel like the application is slow or broken.

Executing code that directly affects the GUI such as setting values on component properties, moving components, changing the display of components in some way, and configuring components is usually very fast. It is actually the non-GUI code that is most often slow, like getting data over a network and processing lots of data.

So the question is, How do you make a very fast GUI always when you have code that takes awhile to execute? The answer is to separate the slow (data processing or data retrieval) code from the fast GUI manipulation code. Put the slow code in a background thread. When the slow code completes execution have the background thread pass the data results to code in the EDT that configures and updates the GUI with that data.

Ignition provides the system.util.invokeAsynchronous(func) function to execute a function in a background thread. And Ignition provides the system.util.invokeLater(func) function to pass data produced in a background thread back into the EDT so the data can be used to update GUI components.

Here is a simple example:

#This code could be on an actionPerformed event of a button to retrieve, process and display data.
#This code will prevent the GUI from freezing if the code to get and process the data takes awhile.
def async():
    #Fetch and process a lot of data. Return a useful dataset
    dataset = functionThatTakesALongTimeToFinish()	
    def later():
        label = event.source.parent.getComponent("Label")
	label.text = "Processed and retrieved %s results."% dataset.getRowCount()
	event.source.parent.getComponent("Table").data = dataset

In the code example above the async function is executed in a background thread. The async function takes its time fetching and processing data. During this time the GUI is responsive and not frozen. Then the async function calls the system.util.invokeLater function, passing the function named 'later' as an argument. The system.util.invokeLater executes its argument (the function called later) in the EDT. Notice that function later can access and use the dataset variable that was created in the async function.

It is possible to sprinkle a background thread with multiple calls to system.util.invokeLater in order to update the user interface as the background thread makes progress. This keeps the user informed of the progress of something happening.

Note that the runScript expression function in Ignition executes in the EDT. So runScript should only execute Python code that is fast and not do things that is potentially slow like execute database queries or otherwise access the network.

The PA Power Scripting Module makes writing code that uses system.util.invokeLater and system.util.invokeAsynchronous easier with @run.