BlogIgnitionManufacturing Execution Systems (MES)

5 Quick Performance Enhancements in Ignition

By April 5, 2018 August 1st, 2019 No Comments

5 Quick Performance Enhancements in Ignition

When you have unlimited everything with Ignition, you can bump into some performance ceilings with the default configuration when you start adding a lot of PLCs, tags, and clients to your architecture.

Getting better performance out of your existing hardware is not difficult, you just need to know the right adjustments to make. Here are the top 5 things we typically adjust on Ignition systems when we build out a new gateway.

Learn more about Inductive Automation’s Ignition.

See some fun things you can do on Ignition with Corso’s Bracketology on Ignition.

1. Update Garbage Collection

In basic terms, as computer programs run, they create objects in your computer’s memory. As those objects are no longer used, they will remain in memory until they are cleaned up by the software. While this cleaning process (typically called Garbage Collection) is occurring, the program is devoting resources to that operation rather than operating the program itself.  This means different methods of garbage collection will cause applications to behave differently.

Ignition (and Java 8’s) default setting for garbage collection is to use a method called Concurrent Mark Sweep (ConcMarkSweepGC). In Java 9 this has been changed to use the Garbage First Garbage Collector (G1GC).  While the names don’t matter, the way they operate can have a significant impact on your system’s performance. ConcMarkSweepGC does fewer garbage collection operations, freeing up more memory with each one. G1GC does more frequent garbage collections with less memory freed each time. Inductive Automation recommends changing to G1GC for the performance boost gained by its garbage collection algorithm.

To update this, open your igntion.conf file, (C:\Program Files\Inductive Automation\Ignition\data\ignition.conf in Windows) and change the following line under Java Additional Parameters:

wrapper.java.additional.1=-XX:+UseConcMarkSweepGC

to

wrapper.java.additional.1=-XX:+UseG1GC

2. Device Configurations

After you have configured your devices and have tags reading/writing to them, you will want to check your device statistics to make sure any PLCs or other devices are not a bottleneck. To check these, login to the gateway and go to the Status tab. Under Connections on the left, click Devices, and check the details of each device. If you see anything is close to or at 100%, or you see 100ms+ response times with the default settings, you can make some adjustments to your device configuration to increase the size of Ignition’s pipe to that device.

These adjustments will be specific to each device. However, common ones for Allen Bradley PLCs are to increase the CIP Connection Size, the Maximum Number of Connections, and adjust the timeslice in the PLC to allow for more time for Ignition to communicate with the PLC.

3. Update Memory Allocations

By default, Ignition is not going to use all of the memory available on the system for the gateway or clients. Updating the memory available for the gateway and clients is easy, you only need to know where to look.

For the Gateway, go back to your ignition.conf file from item 1, and look for the Initial Java Heap Size setting. The Initial Heap Size is set in the same range as your average usage, and the maximum would be a multiple of that, usually 4x. As a system grows, we would typically increase these values to allow Ignition to use more memory. In those instances, we raise them incrementally to make sure the system remains stable with the new values.

If our average usage were 1GB, we would use the following:

# Initial Java Heap Size (in MB)

wrapper.java.initmemory=1024

# Maximum Java Heap Size (in MB)

wrapper.java.maxmemory=4096

For clients you need to look in the Project->Properties menu in the Ignition Designer. Go down to the Client->Launching section of the tree, and adjust the maximum memory available for clients. NOTE: If you are using 32 bit Java or IT will push out auto-updates of Java that overwrite a 64-bit installation of Java, keep this value below 1.5GB. If you set it to more than 1.5GB, your clients will not launch while using 32bit Java on the client machines. If you are confident you will always be using 64 bit Java, any selection here will work.

4. Use Templates and Data Types

Not all performance enhancements are created equal. The first three tips are for the backend architecture, while the next two cover workflow enhancements to help your team develop applications more efficiently.

One huge performance enhancement Ignition provides the ease of using Templates and Data Types for Development. Templates are client-side objects you can use to represent different pieces of equipment, informational displays, buttons, etc. Data Types are essentially data models for tags you can use to group tags into logical structures instead of having one endless list of every tag in your system.

We will cover our best practices in using templates and data types in more detail in future posts. If you find yourself copying and pasting graphics and updating a ton of tag references rather than making a global change, or copying and pasting tags and updating more than a handful of addresses, dig into templates and data types, they will save you an enormous amount of time developing your system.

You can also use template repeaters and template canvases to streamline screen development further if you want to go into Boss Mode.

5. Use Custom Methods on Components and Windows

Similar to number 4, if you find yourself copying a pasting a function to more than one component’s scripting window, STOP what you are doing and walk away. See the “Custom Method” field in the scripting window? Use that instead.

Here you can define a custom method you can call from any other component in the window. We typically use this when we want to do some database interaction to update the values in a table, and may have a handful of places from which this script needs to be called. This saves you many lines of code by only having to define the script once.

The real benefit comes from when need to troubleshoot and update something. Rather than doing a find/replace, and probably missing something in 11 different copies of the same function, you only need to update it in the custom method, one time, and it is applied across the entire window.

What’s Next?

If you have any other ideas for performance enhancement we missed, we would love to hear them! We are also putting together more specific posts for the nitty gritty details of everything we have run into in Ignition, so be on the lookout for those here on the Corso blog!

 

Want some more hands on help? Contact us at (503) 389-5811 or Info@CorsoSystems.com and we can answer any questions you may have.