You're currently browsing the Ignition 8.0 docs. Click here to view the latest docs.

Where Is Scripting Used?

Python is used in many places in Ignition. Each location has its own events that trigger your scripts to run, and add functionality to your projects in different ways. The most apparent place is in event handlers on components and other objects in Vision Clients and Perspective Sessions.

Script Scope

One important thing to keep in mind before scripting in Ignition, is to understand the concept of scope.  Within Ignition, there are different scopes: the Gateway Scope, the Perspective Session scope, and the Client Scope. Where a script is run from determines what scope it is running in. This is important because it determines what system functions can be run, what resources the script can interact with, and where the output will be written to. For example, running a script on a Tag is run in the Gateway Scope and the output is sent to the Gateway console (i.e., wrapper.log file) because Tags are stored in the Gateway. This means that the script will not be able to access any client level resources such as windows or components that you may have open in the Client. Additionally, some of the system functions like system.gui.errorBox only work in the "Client Scope," so you will not be able to use them in the script on the Tag.

"Client Scope" scripts, however, execute on the running client (and also in Designer when testing, but only in Preview Mode). For example, if a component on a window is running a script, its values are isolated to the client, and the output will be displayed on the Designer/Client output console.

System Functions

Ignition comes with a group of system functions, called the System Library. Using a system function is simple. For example, the following code will access the value of a Tag.

Python - Simple Script Using a System Function
value ="tagPath").value

A complete list of these functions (with their definitions) is available wherever you can add a script. Just type system. and then press Ctrl+Space to get a list of all the functions available. If you keep typing, the list will even be automatically narrowed down for you!  Additionally, the Scripting Functions page in the appendix contains complete documentation for the built-in system functions.

On this page ...


Scripting in Ignition


System Library


Both Perspective and Vision offer component based scripting triggers, providing a means to execute a script under a number of different situations, such as a user interacting with a component or a component property value changing. For more information on how both module handle component based scripts, take a look at the Scripting in Perspective and Scripting in Vision sections. 

Client, Gateway, and Session Event Scripts

Scripts can be set to activate on specific events that occur during runtime. For example, you can triggering a script to run when a vision client starts, or on certain time intervals. 

More information on these events can be found on the Client Event ScriptsGateway Event Scripts, and Perspective Session Event Scripts pages. 

Project Scripts

You can create your own reusable blocks of code in the Project Library. Once configured, these functions can be called from anywhere in a project, just like our system.* functions.

Tag Scripts

Once Enabled, these scripts are fired whenever a Tag value changes or an alarm event happens. You can use them for additional diagnostics, to set additional Tags, or to react to an alarm event. Because these events are on Tags, they are Gateway Scoped.


Reporting uses scripting in many different ways to help increase the effectiveness of the report. Scripting in Reports is used to create and modify data sources, manipulate charts, and set up a script as a scheduled report action.



The Alarm Notification system can also use scripting to great effect. A script block allows a script to be run within the pipeline, allowing data to be manipulated as the alarm event travels through the pipeline. Additionally, scripting can be used to generate a custom roster of users at runtime, giving full customization to who gets notified by the alarm event.

Sequential Function Charts

Sequential Function Charts (SFCs) are a flowchart of blocks that run scripts. They are executed in a specific sequential order along with some logic to potentially loop or call other charts. The scripts here can interact with the Gateway, and provide greater control when each step needs to complete before the next one can begin in multi-step processes.

  • No labels