« Back

Using Ignition Scripting Libraries

News

Using Ignition Scripting Libraries

Volumes have been written about the proper use of tools within a software application and how to create projects for maximum efficiency in both development and execution.  Senior programmers and leaders of development teams strive to write and deploy robust solutions that are simple, efficient, easy to debug, and easy to adapt in the future.

Ignition is a multi-faceted tool that continues to revolutionize industrial applications.  The package includes a powerful scripting tool that has undergone significant upgrades from versions 7 and before and has existed in its current form since version 8.  When combined with the software’s other capabilities and using a disciplined approach to the application of all the tools, Ignition can give you efficient and optimized solutions that can solve most SCADA and business integration challenges.

The scripting capability, specifically, is a great way to maximize the power of your projects.  Scripts can be called within both Vision and Perspective environments as well as part of alarm pipelines, reports, and more.  These capabilities can be attached to Vision components and windows, Perspective components, and with tags, client events, and session events.  Furthermore, the library functionality extends the functionality of Ignition by reaching outside the native application and into business systems. This is where we find this tool to be very useful.  For example, querying a database to retrieve data from a higher-level system or placing a series of data back into a business system based on a scripted event are great uses of the scripting library functionality.

The tool itself provides extensive capability within the native library.  It also uses and promotes the use of scripting packages which are folders that hold multiple related scripts.  These libraries and packages are important components of optimized and validated routines within an overall project.  The friendly user interface can be tailored to the developer’s desires and allows access to all or a selected portion of the backend components.  It provides access to both the system and the project’s own custom libraries within the code, hints for writing scripts via an autocomplete option, powerful search and replace functionality, and flexible scheduling of execution based on an extremely adaptable utility.  The resultant scripts and script packages can be used repeatedly throughout different areas within a given project and they can be used as inherited resources in other projects.

At ECS we have found that this allows us to maintain our quality control within applications.  The libraries make it easier to test functions and audit code to ensure that it is compliant with our standards.  It also makes applications easier to review and promotes code reuse overall.  In the long run, this makes for better programmers and more robust, reusable components.  It is easy for a project lead to divide the work required for a given application amongst those best suited to deliver that portion.  Later, subject matter experts at ECS review nearly every application during quality gate reviews.  This allows us to ensure that our standards for not only coding but also the application of code are being adhered to.  Tools like the Ignition scripting libraries simplify this process, making it easy to see where scripting has been deployed and then debugging within by using standard Ignition tools.

As with any software tool, you must be careful not to overuse its power.  Developers should always use the simplest tool available to reach the end goal.  If a simpler tool within Ignition can be used for lower-level functionality, then use the simple tool.  Conversely, if something complex needs to be executed within a package such as Java or Python then it is always best to use that application and perhaps call that complex function with an Ignition function.  In between can be libraries and library packages functioning as an optimized middleware for industrial solutions.

At the end of the day, an integrator can use Ignition libraries to deploy a good application that was developed by an individual or a team who focused on their core expertise and delivered in a manageable and profitable way.  The application as it will come to exist at a client site will be a combination of simple and complex components that should run as an efficient overall solution.

 

Posted In: Blogs, Inductive Automation