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


Where Is Scripting Used?

Python is used in many places in Ignition. Each location has it's 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 Ignition Clients. Project and Gateway event scripts are another major place where Python is used.

Script Scope

One important thing to keep in mind before scripting in Ignition, is to understand the concept of scope.  Within Ignition, there are two different scopes: the Gateway 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 = 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.

On this page ...


IULocgo

Scripting in Ignition



IULocgo

System Library



Components

Every component has "events" associated with them such as when a mouse is clicked, a key is pressed, or a value changes. Each type of component has a slightly different set of events based on what you do with that component. For example, all of them have the Property Change event, but only components that can be activated have the focus events. Because these events are on components, they are "Client Scoped."

Extension Functions

Extension Functions are chunks of code that allow you to interact with some of the basic parts of components that would otherwise be hidden. They vary for each component and not all components have them because they are so specialized. These functions allow you to do things like configure a cell or create a right-click menu in a table, or change the way the Easy Chart works. Because these events are on components, they are Client Scoped.

Custom Methods

You might want to have a table contain all the scripting to edit it's contents, or a button that does a complicated check before continuing. Using Custom Methods allow you to add functions just like the Script Modules, but attach them directly to a specific component. This means that if you have a template or component used in several places, you can set up common functions that will stay with that component. Because these events are on components, they are Client Scoped.


Client and Gateway Event Scripts

Scripts can be set to activate on specific events in the Client, or in the Gateway. These scripts may run every 5 seconds, on a Tag change, or when the Client or Gateway start up or shut down. There is even a messaging system that allows you to create functions that will run on demand when called by another script. These scripts vary in scope, depending on whether you set up a Client Event Script or a Gateway Event Script.


Scripting Modules

You can create your own reusable blocks of code in the Script Library. You can set up these Script Modules that exist in just one Project, or ones that are shared between all projects on a Gateway. Once completed, these functions can be called from anywhere in Ignition just like our system.* functions. The Script Modules vary in scope depending on where you call them. They act similar to the system functions except you create them. Calling a Script Module in a Tag Script will be in the Gateway Scope, while calling one from a component will be in the Client Scope. However, a Script Module made in the Project Script Library can only be called in places with the Project Scope, whereas Script Modules made in the Shared Script Library can be called from anywhere.




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

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.

  

Alarming

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