Skip to main content
Version: 8.1

Scripting in Ignition

Inductive University

Scripting in Ignition

Watch the video

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:

  • Gateway Scope - The script runs on the gateway. Scripts running in this scope cannot interact with components in the other two scopes.
  • Perspective Session Scope - The script runs as a part of a Perspective Session. Note that scripts in Perspective execute on the gateway, not in the browser, but this scope is still distinct from the Gateway Scope.
  • the Vision Client Scope - The script runs inside of an instance of a Vision Client.

Where a script was written determines which scope it executes in. For example, Tags are in the Gateway Scope, so Tag Event Scripts execute in the Gateway Scope.

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.

System Functions, Hints, and Autocomplete‚Äč

Inductive University

System Library

Watch the video

Ignition comes with a group of system functions, which are built-in functions that interact with Ignition features.

Python - Simple Script Using a System Function
value = system.tag.readBlocking(["tagPath"]).value

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


The autocomplete popup always shows all system functions scoped to the current script. If a system function does not appear in the list, that means the function is not available in the current scope, or has been deprecated.


New in 8.1.18
Starting in 8.1.18, the autocomplete popup is enabled by default and will appear after typing "."

The new editor also offers parameter completion assistance; if you auto-complete a method with multiple required parameters, you‚Äôll automatically enter a ‚Äúparameter assistance‚ÄĚ mode, where you can tab through the parameters and enter them one at a time:

To disable these features, right-click anywhere within the Script Editor window and deselect Automatic Activation and/or Parameter Assistance.


New in 8.1.18
Autocomplete hints are now also displayed for code other than Ignition's system functions. If Ignition detects a function or project script, a popup will automatically appear, from which you can select which function or project script you are trying to reference. You can also bring up this popup by pressing "ctrl-space".


New in 8.1.32
Autocomplete hints will extract method parameters, return information, and limited type awareness for project script functions and class docstrings written in Google Python Style Guide's docstring format. An example of the expected format is as follows:

Code Snippet
def setMode(mode):
"""Changes the mode of the running system

mode: An integer representing the mode to switch to.

A boolean that indicates if the attempt at switching to the given mode was successful.

Error: If communications are down, an exception will be thrown.
# Function code goes here

The code above will display the description, parameter, and return information when autocomplete hints render the docstring:

Script Hint Scope‚Äč


New in 8.1.19
You can choose the scope of your scripting hints and suggestions come from by selecting the dropdown menu in your Project Library's scripts:

The table below lists possible values you can choose from in the dropdown menu:

NoneThe project library will not use the Designer nor the Gateway to populate scripting hints.
DesignerThe project library will use the Designer scope to populate scripting hints.
GatewayThe project library will use the Gateway scope to populate scripting hints.
AllThe project library will use both the Designer and Gateway scope to populate scripting hints.


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 trigger 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 Scripts, Gateway 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.