Script Modules

Ignition's Shared and Project Script Modules are global libraries of scripts that can be called from anywhere within their scope. Shared Script Modules are available to the whole Gateway including every project, and Project Script Modules are available anywhere in the project that they were created in. These scripts are organized as named modules that all live under the shared or project Script Library. To open the Script Module Editor, find the shared or project Script Library and double-click it in the Project Browser.









 




 




If you're unsure of when to put scripts in a script module vs. writing the script directly in an event handler, follow this simple rule: If you ever find yourself copying a script from one event handler to another, stop and refactor the script into a global script module! Then simply call your new module from the event handler. This rule will help prevent code duplication across your project which can be a major maintenance liability. By consolidating scripts into one location makes them easier to update.





How to use Script Modules

To add a script module, simply right click the Script Library [project] package and click the New Script option. Each module is a python script that can define many functions. You can also keep your scripting modules organized in Packages (i.e., folders) by creating additional nested subpackages. To create a Package, click on the Script Library [project] and click the New Package option. 

For example, let's suppose you added the following script module named myFuncs, whose body is shown below.

def callMe(message):
	system.gui.messageBox(message)




Now, anywhere in your project you can call this function.

project.myFuncs.callMe('Hello World')


Because each module can hold many functions, you can add any functions you need to this Script Module.


Just like before, you can call this function using:

project.myFuncs.addNumbers(14, 87)

Note, that the addNumbers function also has a return value. This will be returned to the script that called the function, allowing you to use it within that script.

To import System or not to import System - Unedited content

Frequently in Ignition, your scripts get system library (the built-in library package in Ignition) and shared and project libraries imported for you automatically. However,

Subsequent versions of Ignition beyond version 7 no longer need import system every time you create a new scope. However versions prior to version 7 still require an import system every time a system associated function is called inside a function.  Ignition versions prior to version 7 still need the import system when system functions are called inside functions. Regardless, typing import system in any version of Ignition will result in the system library being available for use inside the function.

When to Import the System Library - edited content - Maria

In current versions of Ignition (version 7 and later), the System Library (containing the built-in library package), Shared and Project Script Libaries are imported for you automatically when creating a new project. Subsequent versions of Ignition beyond version 7 no longer require you to import  the System Libary every time you create a new scope.  However, versions prior to version 7 still require you to  import the System Library every time a system associated function is called inside a function.  Regardless, typing  the "import system" command in any version of Ignition, will result in the System Library being available for use inside the function.


Project Scripts vs. Shared Scripts

There are a few differences between Project and Shared Script Modules. The first difference is the way each script type is called. Shared Scripts are called with "shared." preceeding the event handler function, while Project Scripts are called with "project." The other difference is where Shared and Project Script Modules can be used. Project Script Modules are limited to the Project Scope, and can only be used within the project they are located in. This is useful when you are using a script many times within a project, but do not want it to be used by any other projector, or elsewhere in your Gateway.

Shared Script Modules, on the other hand, are not limited by scope and can be used anywhere within any project or Gateway. However, this means the Shared scripts can be used by projects that possibly shouldn't have access to them. Since Shared Script Modules are stored on the Gateway, they are not part of a normal project export. So moving a project to a new Gateway will require that Shared scripts also be included in the transfer.


A Simple Example

In our projects, we use a fairly simple script that calculates OEE, and writes it to a Tag as shown below.

def caclulateOEE(lineNum):
	#Build the Tagpaths with the dynamic line numbers.
	paths = ["[default]Metrics/Line_%f/Quality" % lineNum,
			"[default]Metrics/Line_%f/Availability" % lineNum,
			"[default]Metrics/Line_%f/Performance" % lineNum]
	
	#Read the values from the Tags.		
	values = system.tag.readAll(paths)
	
	#Get your Quality, Availability, and Performance.
	quality = values[0].getValue()
	availability = values[1].getValue()
	performance = values[2].getValue()
	
	#calculate OEE
	oee = quality * availability * performance
	
	#Write back to our OEE tag. 
	system.tag.write("[default]Metrics/Line_%f/OEE" % lineNum, oee)


Instead of copying this script between projects and throughout all of the windows that need it, a Shared Script Module was created in the Shared Script Library called "Metrics."  The code was copied and pasted into the scripting area in the Shared Script Library. 


This could then be called from a script in any project by calling shared.metrics.calculateOEE():