In addition to a great software platform, a SCADA system requires a solid hardware and network architecture to be high performing in a particular application. Without proper application, you might open up Task Manager to find that the 16 GB of RAM on your new computer suddenly feels like 16 MB. When developing a system using Ignition SCADA software from Inductive Automation, you may encounter performance issues depending on the type of hardware you're using and how your system is set up. Here are a few configuration tips to transform a sluggish SCADA into a fast and responsive system.
Increase the Memory
Today, most servers are 64-bit which allows essentially endless amounts of RAM for us to use[1] (24TB in Windows Server 2016). If using a 64-bit instance of Java, there are two places that you can up the allotted memory for Ignition: the gateway server and the client. The client memory is the easier to alter, but offers less in the way of customization. Simply go to the Project Properties in the Ignition Designer and change the dropdowns for the initial and maximum memory usage for clients (up to 4GB).
For the gateway memory usage, you’ll need to change the Ignition.conf file located in the data folder in Ignition’s install directory. Inside, you’ll find two properties: initial java heap size and maximum java heap size. Typical practice is to set the initial memory to the average memory usage of the gateway and the maximum to 2 or 4 times the initial.
# Initial Java Heap Size (in MB)
wrapper.java.initmemory=1024
# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=4096
Change the Garbage Collector
If the maximum Java heap size is increased past 4GB, it’s recommended to also change which garbage collector Java is using. The default Java garbage in Java 8 (and Ignition) is Concurrent Mark Sweep (ConcMarkSweepGC). This garbage collector is efficient for projects with not too much data and a lower java heap size. Once the size of the project and memory increases, however, you should consider switching to the Garbage First Garbage Collector (G1GC) which is the default garbage collector for Java 9. The garbage collector is specified in the Ignition.conf file as wrapper.java.additional.1 under the Java Additional Parameters.
wrapper.java.additional.1=-XX:+UseG1GC
Keep An Eye on Execution Times
When data is not coming in at the rate that you’d expect, the likely cause is the scan class. Scan classes are often overlooked as a cause to performance issues, most likely because they are often overlooked in general. Scan classes determine how often tags are updated from the PLC, an expression, or a database query, and are set when editing a tag. However, since scan classes execute on the gateway, all the tags from all providers could potentially share the same scan class. On the Ignition Status page under Diagnostics/Execution you can see the how long scan classes are taking to execute and how often they’re running. It’s not uncommon to see that a scan class that is running every 1 second is taking longer to execute. Moving tags to different scan classes that update at different rates will take the load off tags and you should see the data start to flow through.
Remove the Runscript Expressions
Since Ignition does not have a tag that supports Python scripting directly, many people resort to using Expression tags that use the runscript function to call a Python script. While the Python script may be efficient and quick, the expression tag will take an inexplicably longer time to execute the script. If this tag is tied to the GUI, it could easily hold up the GUI thread each time it executes. If it’s set to update every second or whenever it changes, it could cause a cascading effect on the GUI and essentially stop it from responding. It is advised to move any runscript expressions into timer scripts. An easy way to check for runscripts is to use Ctrl+F and search all windows and templates.
Run Asynchronously
To finish off this list, one of the most important things you can do to an Ignition project with a laggy GUI is to run scripts asynchronously. Traditional script calls will perform the computation on the same processing thread as the GUI. This means that if the thread is busy sorting through datasets and reading tag values, the button press event will not be executed until the previous calculations are done. This is where asynchronous script calls come in. Making a script run asynchronously is not too difficult of a process – simply call system.util.invokeAsynchronous(functionName). Keep in mind, though, that this will isolate the script from the GUI unless using a system.util.invokeLater call to bring in the event.
[1] The theoretical limit – 264 approximately 18 ExaBytes (1/16th of the estimated total data in Earth’s history)
You might also be interested in...
Building a Front-End Web App for Ignition SCADA Using React and the Web Dev Module.
This blog post outlines a set of steps you can follow to build a web-based HMI using React with an Inductive Automation Ignition back end.
Essential SCADA Design Components to Maximize Plant Productivity
For more tips on good user interface design in general, check out this white paper on SCADA UI design.
COMMENTS