Nick Mudge Ignition Software Consulting & Development

Recently Chris Powell, who I met in the Ignition Chat Room, started writing blog posts about Ignition - giving examples of how to use various functionality.

He wrote a guest post on my blog about Ignition Power Tables.

He recently started his own blog about Ignition. His first posts are about Ignition's Calendar Components and Ignition Template Repeaters.

For a long time there was no officially supported way to create screens dynamically in Ignition. Screens were created up front by designers/programmers by dropping components on windows and then scripting and configuring them.

There was no dynamic creation of components based on current data from a database or other source of information.

Ignition Containers

This has changed in Ignition. It started with the Template Repeater which was released in Ignition 7.7.0. This component allows an Ignition template to be configured and repeated any number of times. A vertical or horizontal scroll bar is automatically added to the template repeater when there isn't enough space for all templates to fit within the designated space. This is a great component but has various limitations; for example it only allows one template to be repeated in a single direction.

The Template Canvas was released in December 2014 in Ignition 7.7.2. The Template Canvas is the most powerful, most significant single component to be released by Inductive Automation since Ignition itself was released in 2010.

The Template Canvas makes it possible to dynamically create any number of instances of any number of templates. The position, width and height of each template instance can be configured. If there isn't enough space for all template instances to fit within the designated space scroll bars are automatically added - vertical or horizontal or both. Once all templates are displayed on a screen their position and configuration can be changed through Python scripting.

How to Use the Template Canvas

First a Template Canvas is dropped onto an Ignition window. You will see a box of ant track lines. The Template Canvas is a kind of Ignition container and the ant track lines show the dimensions of the Template Canvas. This shows how much space the Template Canvas will use on the window. Change the position and width and height of the Template Canvas as needed.

Templates Property

The Templates property of a Template Canvas is a dataset that contains template instance information. Each row of the dataset specifies a template to use to create a template instance and its position and layout. Populating this property is what creates and positions template instances. Here is a view of a Templates dataset:

Ignition Templates Dataset
Ignition Containers

There are different ways to populate the Templates property. One way is to use the Template Canvas Customizer. Right click on the Template Canvas in the designer, hover the mouse over Customizers, then choose Template Canvas Customizer. Using this customizer you can select templates to use and the layout and positioning. The Template Canvas Customizer also lets you input values for any template instance parameters. The Template Canvas Customizer is a static upfront way to create the Templates dataset. Using it is a good way to get started with the Template Canvas.

A dynamic way to create the Templates property (and therefor dynamically create template instances and configuration) is to bind a database query to the Templates property.

Python scripting is the most powerful and flexible way to dynamically create a dataset for the Templates property. Python provides many tools and capabilities to analyze and manipulate data and many ways to access sources of data.

Layout and Positioning

There are two ways to position template instances: Absolute Positioning and Layout Positioning.

Absolute Positioning uses absolute x and y coordinates and values for width and height. The x, y, width and height columns in the Templates dataset are used for Absolution Positioning. x and y coordinates need to be calculated for each template instance.

Layout Positioning uses a powerful and easy to use layout manager called MigLayout. The "layout" column in the Templates dataset is used for Layout Positioning. The layout column holds a MigLayout string for each row in the dataset.

Documentation for MigLayout is here: MigLayout QuickStart

Here is a handy MigLayout cheetsheet: MigLayout Cheetsheet.

Initializing Template Instances

By initializing template instances I mean setting any template parameters for each instance. There are a couple ways to do this.

The Template Canvas Templates property can have a column called "parameters". This column holds a string representation of a Python dictionary. Each item in the dictionary contains the name of a template parameter and a value to be set for the template parameter. The Template Canvas Customizer uses the "parameters" column to set parameter values for template instances.

Another way is to use the initializeTemplate extension function on the Template Canvas. Remember an extension function is an editable function on a component that exists to customize it.

initializeTemplate Ignition Script

The initializeTemplate function is called for each template instance created by the Template Canvas. The initializeTemplate function takes as an argument the template that it is called for. This extension function provides a chance to execute a Python script for each template instance to configure it, set template parameters etc. Each time the Template Canvas Templates property changes the initializeTemplate extension function runs for each template instance.

Template Canvas Video & Demo

I made a Template Canvas demo project and a video that shows how to use the Template Canvas. To see the video and get a copy of the Template Canvas demo project signup for my email list.

Immediately after signing up for my email list you will be sent an email containing a link to the Template Canvas video and a link to the Ignition project that is used in the video.

You are free to have and use the Template Canvas demo project for your own purposes.

Here's a screen shot of the Template Canvas demo application:

initializeTemplate Ignition Script

It is common in Ignition to want to copy visual displays, configuration and functionality. For example, if 20 motors are needed on a window create one motor and copy it 19 times.

But later those 20 motor displays will need to be changed. You know it will happen. Someone will request a change to them or you realize how to make them better etc. etc.

In the past you would need to change each motor display individually. In a large project where there are lots of copies of things the amount of work to make changes really adds up.

Ignition templates solve this problem. This is how:

  • Something is designed. This is a template.
  • The template is used in many places. Each use of a template is called a template instance.
  • When it needs to change it is changed in one place one time. All template instances are automatically updated.

Here's a quote from the Ignition User Manual:

Templates are components that can be re-used across many windows. They are designed separately, outside of any window. After being designed, they can be added to any of the windows within a project. The true power of a template is that if you change its design, all uses of that template across all windows will reflect those changes. This gives templates a major advantage over a copy-and-paste style of design.

Different Template Instance, Different Data

The graphics and functionality of each template instance (from the same template) is the same but the data used by each template instance is different.

Example: Motors template is used to create the Motor A template instance. The data from the actual physical Motor A on the plant floor is fed into the Motor A template instance so that it can display that data. The Motor B template instance is fed Motor B data etc.

Also see an Introduction to Templates.

This is a guest post from Chris Powell.

Recently, Inductive Automation added a new table to their list of components. The name 'Power Table' is not understated. I want to share a few of the features I have found for some of the non-programming background developers out there.

Since the release of Ignition V7.7, Inductive Automation has added Extension Functions to several components. Extension functions are editable functions that exist on components that are used to customize components. Let us go over some of these features as they relate to the power table component.

First, put a power table table on a window. Then select TestData to load the table with data.

Ignition Power Table

You can paste the code from the following sections into each power table extension function to see how it works. I hope this will make your use of power tables faster and easier to implement in your next project.

configureCell Extension Function

I use this feature to highlight each individual cell on each row based on the row's value. With this code, I can change the background color based on that cell's value. You may add custom properties to the power table and access them with 'self.propertyName'. I created the custom property called 'highsp' and used it in line 2. Here is code for this:


    if colName == 'Float Column':
        if value > self.highsp:  
            return {'background' : 'red'}
        elif value < 0.2:
            return {'background' : 'yellow'}
        else:
            return {'background' : self.background}
    elif colName == 'Boolean Column':
        if value == 1:
            return {'background' : '0,125,0'}
        else:
            return {'background' : self.background}
    else:
        return {'background' : self.background}

The only issue I noticed so far is the repaint of the table if you are using dynamic properties. So if my 'highsp' property changed, the table does not repaint. To fix this, add the following code to the propertyChange event handler:


if event.propertyName == 'highsp':
    event.source.parent.repaint()

This will force the table to repaint and you will see the changes.

While we are on the property changed event handler, this is where you will edit the Columns Attributes Data table. You create the entire table because it does not create itself unless you use the Table Customizer. The following code will build the Columns Attributes Data table from scratch each time new data is loaded. Add the following code to the property change event handler.


# Let's create the Column Attributes Data table.
# First, let's set the defaults.
if event.propertyName == 'data':
    name = ''
    dateFormat = 'MMM d, yyyy h:mm a'
    editable = 1
    filterable = 0
    hidden = 0
    horizontalAlignment = '-9'
    label = ''
    numberFormat = '#,##0.##'
    prefix = ''
    sortable = 1
    suffix = ''
    treatAsBoolean = 0
    verticalAlignment = 0
    wrapText = 0
	
    # Now let's get rows loaded in the table.
    rows = []
	
    table = event.newValue
    for k in table.columnNames:
        #Name of the column I want to be different from default.
        if k == 'Int Column': 
            name = k
            # Makes the 'Int Column' hidden.
            newrow = [name, dateFormat, editable, filterable, 1,
            horizontalAlignment, label, numberFormat, prefix,
            sortable, suffix, treatAsBoolean, verticalAlignment,
            wrapText]
        else:
            name = k
            newrow = [name, dateFormat, editable, filterable,
                      hidden, horizontalAlignment, label,
                      numberFormat, prefix, sortable, suffix,
                      treatAsBoolean, verticalAlignment, wrapText]
        rows.append(newrow)
	
    # Build the header
    headers = ["name", "dateFormat", "editable", "filterable",
               "hidden", "horizontalAlignment", "label",
               "numberFormat", "prefix", "sortable", "suffix",
               "treatAsBoolean", "verticalAlignment", "wrapText"]
	
    data = system.dataset.toDataSet(headers, rows)
    event.source.columnAttributesData = data

onCellEdited Extension Function

I mention this section because even if you have 'Editable' selected in the Column Attributes Data, it does not really edit anything. You need to enable this function and uncomment the code. I have added the code below. You also might want to add a call to 'system.db.runPrepUpdate' to send the update back to a database.


import system
self.data = system.dataset.setValue(self.data, rowIndex, colIndex, newValue)

Recently I found out how to setup autologin for the Ignition Designer. This is the ability to start the Ignition Designer from a desktop shortcut and it automatically logs in and opens a project.

This is especially useful when developing an Ignition module that affects the designer because the designer will need to be restarted many times to test code changes.

Here's how to setup autologin for the Ignition Designer:

  1. Create a designer shortcut using a native client launcher.
  2. Edit the shortcut. Add the following parameters to the Target: -Djavaws.ignition.debug=true -Dautologin.username=admin -Dautologin.password=password -Dproject.name=MyProject.
    Replace the username, password and project name with your specific information.

    Here is an example of a complete Target in a shortcut:
    C:\Users\nick\Downloads\clientlauncher.exe scope=D windowmode=window gateway.addr=192.168.1.4:8088:8043 -Djavaws.ignition.debug=true -Dautologin.username=admin -Dautologin.password=password -Dproject.name=MyProject

That's it. The next time the shortcut is double-clicked the designer will automatically login and open the project.

Security must be kept in mind, as this setup makes it easy for people to log in to the designer as you if they get your Designer shortcut.

One of the great things about Ignition is its ability to web-deploy applications created with it. Notice that Ignition applications are not "web-based", they are "web-deployed". Web-deployed means an application is downloaded from a web server and started.

Web-based applications are web-deployed too — web-based applications and Ignition applications have that in common. Web-based applications are webpages downloaded from a web server and ran in a web browser. Ignition applications are downloaded from Ignition's web server and ran in a Java Virtual Machine. (In other words an Ignition application is downloaded and automatically started as a Java desktop application.)

Ignition does have a built-in web-based application for configuring many things in Ignition. But the applications/projects created with Ignition are typically Java desktop applications that are web-deployed.

Ignition has two separate web-deploying technologies. Both of them can be used to deploy Ignition applications.

In the beginning Ignition only used Java Web Start, which is a web-deploying technology controlled and owned by Oracle. Here is a good description of Java Web Start from www.java.com:

The Java Web Start software allows you to download and run Java applications from the web. The Java Web Start software:
  • Provides an easy, one-click activation of applications
  • Guarantees that you are always running the latest version of the application
  • Eliminates complicated installation or upgrade procedures

The problem with Java Web Start is that it is controlled by Oracle. In the past changes were made to Java Web Start that broke functionality in Ignition and in once case temporarily broke the ability to start projects on Linux.

Inductive Automation decided to implement their own web-deploying technology and did so. With this technology under their control they could make it stable, keep it from breaking Ignition, and add new functionality to it. This technology is called Native Client Launchers. It is called Native Client Launchers because separate client launcher executable programs exist for OS X, Windows and Linux.

One of the advantages of the client native launchers is that they can be used to create stable desktop shortcuts to projects or the Ignition designer. Shortcuts created with Java Web Start sometimes stop working.

Using a native client launcher is easy. Download the native client launcher executable for your operating system and then run it. The native client launcher will scan your network for Ignition servers. It will provide you with a list of Ignition servers it found. Once you choose an Ignition server you are provided with a list of projects that exist in that Ignition server. From there you can launch projects or the designer, and create shortcuts to projects and the Ignition designer.

The native client launchers are part of your Ignition server and are downloaded from your Ignition server. You can find and download them from the Ignition homepage. Here is a screenshot that shows where the native client launchers can be downloaded.

Ignition Native Client Launchers

Every two or three months a new production version of Ignition comes out. Thankfully upgrading Ignition is usually a pleasant, easy and quick action.

The main thing to know about upgrading Ignition is that it is exactly like installing Ignition. You download the latest production version of Ignition and install it as if you were installing it for the first time on your server. This action upgrades your current Ignition installation. All your projects and configuration remain the same but your Ignition becomes the latest version. This is very nice.

It is good practice to make a gateway backup before upgrading. Inductive Automation provides instructions for installing Ignition on MAC OS X, Windows and Linux.

Ignition uses 3 numbers to indicate it's version. The current version of Ignition is 7.7.2. The first 7 is pretty static and hasn't changed since Ignition was first released in 2010. The second 7 is the major number. It indicates significant changes and significant new functionality compared to the prior major number. The 2 is the minor number. It indicates bug fixes, improvements and new functionality.

Upgrading Ignition from a minor number (for example upgrading from Ignition 7.7.1 to Ignition 7.7.2) is the easiest thing. It is free so no licensing changes are needed and the upgrade does not affect the current license.

Upgrading Ignition from a major number (for example upgrading Ignition from 7.6.5 to Ignition 7.7.2) requires a license change. This is because there are significant improvements and significant new functionality between major numbers. Before upgrading it is a good idea to upgrade your license so that it will be compatible with the new version of Ignition. Upgrading from a major version costs money to upgrade the license. Inductive Automation offers something called upgrade protection which can reduce the cost of major number upgrades.

I prefer and recommend to use the latest production version of Ignition in all projects. The reason is because the newest production version is almost always better than earlier versions.

Sometimes the changes between a minor number and the next minor number can actually be significant. The difference between Ignition 7.7.1 and Ignition 7.7.2 is such a case. Ignition 7.7.2 introduced a brand new, very powerful component called the Template Canvas. For the first time Ignition has a built-in tool for dynamically, programmatically creating instances of templates in Ignition. This means programmers can write Python programs to create screens dynamically (for instance based on data in a database) -- instead of designers creating everything up front on screens in a static fixed way.

Every Ignition version release has a changelog so it is possible to see what the new changes are. Here's a link to the changelog for Ignition 7.7.2: Ignition 7.7.2 Changlog.

Inductive Automation also releases development versions of Ignition. These are new versions of Ignition that are not ready for production but that you can download and try out. You can also report any bugs or problems with it to Inductive Automation to help them get it production ready. Also, if you can't wait for new functionality in the next version of Ignition, you can use a development version. For example you could use a development version of Ignition in your own development and use the production version of Ignition when it comes out for your production version of projects.

After releasing database-backed form components for Ignition, I received several requests for a Form Popup Calendar component for handling dates and times. This has been implemented and is now available.

The FormComponentsPalette.proj download now includes a new Form Popup Calendar component and a Form Check Box component. The Form Example has been updated to use these as well. (Upgrade your Ignition to Ignition 7.7.2 or higher for the import to work.)

Here's what these two new components look like:

Form Popup Calendar

The Form Popup Calendar component is associated with a Datetime column in a database table. When a date and time has not been selected or when the date property is None/null then a label is displayed that says, "Select Datetime". This text can be changed to whatever you like if you want to change it.

A Form Check Box component is associated with a BIT column in a database table. Any number of Form Check Box components can be used on a form.

The two new form components work like other components in the Form Components Palette.

All the form components have been tested on MySQL and SQL Server.

Check out the original blog post about form components to learn more. Don't forget to watch the videos.

Automation World published an article entitled, Want to Build Your own SCADA? Here's a Guideline, which is based on my article A Software Framework for SCADA Applications.

I want to clarify what I meant to say. I was not saying or suggesting that people create their own SCADA systems from scratch or create their own SCADA framework.

I was not providing a list of features that people should implement to build their own SCADA system. On the contrary, I was providing a list of features that people should not create when building a SCADA system — because these things should already exist for them.

I was saying that people should use a framework with this list of features to build the SCADA applications that they need. The list of features is useful for evaluating different SCADA software frameworks.

The real message is this: Don't create a SCADA system from scratch. Don't buy a canned SCADA solution that is too inflexible. Use an existing SCADA software framework that gives you the flexibility and tools to design and create what is needed.

The purpose of a SCADA framework is to take away all the work that isn't the core business application.

I do agree with the Automation World article that my list of features is a good list to follow and use for someone who wants to create their own SCADA system or framework from scratch.

The list of capabilities and features that I wrote about were inspired by Ignition, which is a full-blown software framework for creating manufacturing and business applications.

Form Components Palette

I created a set of pre-configured form components that make it easy and fast to create database-backed user input forms in Ignition. The components are free and available for anyone to use.

The ability to create custom component palettes in Ignition is a capability that is not often talked about but is a powerful feature and can be very useful. In this case I used this capability to create a set of components that anyone can use to quickly and easily create forms in Ignition. The forms are used to capture user input and insert and update data in databases. See the Form Components in the image on the right.

To use the Form Components Palette download this file: FormComponentsPalette.proj. Then import the file into an Ignition project. The project file includes the Form Components Palette and a Python module at project.pa.forms. This project file only works in Ignition 7.7.2 and above.

How it Works in a Nutshell

A Form Container is placed in a window and other form components are placed inside the Form Container. A Form Container specifies what database table to insert data into and update.

Form input components receive user input for specific columns of a database table.

A Form Table shows what data exists in a database table and enables users to select rows in the table to update or delete.

A Form Submit Button is clicked on to insert or update data in a database table.

The form components are very flexible and can be modified easily to support various functionality.

Videos

Here is a video that shows how to create forms using the new form components: Ignition: How to Create a Form Using New Form Components.

Here's another video where I create a form from scratch in less than 5 minutes, including adding validation and testing the form: Ignition: How to Create a Database User Input Form in 5 Minutes.

Form Components in Detail

Form Example

The Form Example provides a working example of a form using the form components. The Form Example expects a simple "people" database table to exist using the default datasource of a project. Look at the SQL query used by the Form Table to understand the schema for the "people" database table.

The Form Example is a skeleton form. Use it to get started creating a new form. Here is an image showing an Example Form:

Example Form

Form Container

The Form Container is a regular container with two custom properties. The "TableName" property specifies what database table to insert data into and update. The "Datasource" property specifies what datasource to use. If the "Datasource" property is blank then the default datatsource for the project will be used.

Form Input Components

These are the form input components: "Form Text Field", "Form Numeric Text Field", "Form Text Area", "Form Dropdown List", "Form Radio Buttons".

Each form input component has a "Column" custom property that specifies which column in the database table to insert into or update. Each form input component has an "IsValid" custom property that indicates if user input is valid or not.

Each form input component has a "validateInput" custom method that is used for validating user input and setting the "IsValid" property to True or False. This method can easily be modified to perform custom validation. This method is called when user input changes.

Each form input component has within it a "Label" component for describing the input component purpose, and a hidden "InvalidMessage" label component for displaying validation errors.

Form Submit Button

The Form Submit Button is used to submit a form, which inserts or updates data in a database table. The Form Submit Button contains within it a "Status" label that shows the success or failure of an attempt to submit a form.

project.pa.forms Python Module

The form components call functions provided by the project.pa.forms Python module to tie together form components and execute functionality of forms.

No Ignition Templates

It is notable that the Form Component Palette does not use any Ignition component templates. While component templates are a powerful and useful feature I found it was best not to use them in this instance. Like templates, component palettes have the ability to combine and capture pre-configured functionlity on regular components and reuse them. While templates have benefits that captured components on palettes don't have, individual instances of non-template palette components can be more easily modified individually.

More Functionality?

If you want me to add more functionality to this then let me know.

I am also interested in finding sponsors who would be interested in funding improvements and new functionality for this work.

Also see discussion on Inductive Automation Forum.

Update: Recently a new Form Popup Calendar component and Form Check Box component were added.