Ignition 8.1
Ignition 7.9
Ignition 7.8
Sepasoft - MES Modules
Cirrus Link - MQTT Modules
Inductive University
Ignition Demo Project
Knowledge Base Articles
Forum
IA Support
SDK Documentation
SDK Examples
You're currently browsing the Ignition 8.0 docs. Click here to view the latest docs.
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.
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.
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.
value = system.tag.read("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.
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.
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 Scripts, Gateway Event Scripts, and Perspective Session Event Scripts pages.
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.
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 (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.
