You can help by commenting or suggesting your edit directly into the transcript. We'll review any changes before posting them. All comments are completely anonymous. For any comments that need a reply, consider emailing firstname.lastname@example.org.
We are experiencing playback issues from our video hosting provider. Please check back shortly.
4:53Gateway vs. Client Event Scripts
5:29Tag Change Scripts
Take topic challenge
Learn to use the "project" script library to consolidate frequently used script logic into one place.
Video recorded using: Ignition 7.7
Transcript(open in window)
[00:00] Every project can have their own collection of scripting modules in the project script library. This was a feature introduced in Ignition 7.7.0 prior to that this was called the app scripts. So you might see users on our forums, still referring to these sorts of things as app scripts, but now they're called Project Scripts to more clearly identify the idea that these scripts are contained within your project and not share it amongst projects, and not accessible from outside of a project. If you want to create scripts that are accessible from multiple projects or from tags, you'd use shared scripts, but to contain a set of projects. I'm sorry, a set of script modules inside of a project, you create a project script, and you will notice right away that the shared and project script library editors share the same workspace. So they have all of the same features that the shared scripts have, you can float their editors. And when you define a function, it will show up in the structure helper over here. Also, a handy feature of this workspace is the auto commit feature. If you type this in, then any valid edit that you make to your script that doesn't cause a compilation error will be automatically applied within this designer session. It certainly doesn't get saved and sent out to clients or the gateway or anything like that. But it will get applied inside this design of session. That way you can test the script out, in your windows here in preview mode or in the script playground without having to save the project. Also, if you make a compilation error inside of the script editor, you'll get feedback right away as you keep typing. So for example, this I forgotten the colon here. And you can see I've got a little red line that corresponds to the very top of my script. Also, if I hover over the area, it'll tell me that it's expecting colon. So as you typing, you're going to start getting red underlines, and red markers over here in the gutter. And that tells you you've made a compilation error in your script. Now just like in the shared scripts, in my project scripts here, I can define as many functions as I want, here in each module. So let's define another function here. Pretty simple, and will show that since I typed it all in correctly, and I don't have any compilation errors, and I have auto commit checked. This script is already committed for this designer session. So I don't need to save this script just yet, that lets me test the script out before I... Before I save it, so I can go ahead and here and type in project. And the script was called project.NewScript.bar, project.NewScript.bar. And sure enough, it prints out to the console. So the project scripts are a great way to consolidate any scripting logic that you have inside of your project. So for example, you may have windows that need access to a common scripting area, you definitely don't want to be copying and pasting the same script into multiple locations, that will create a bit of a nightmare for maintenance for you. So you want to consolidate your scripting into one place so that when you need to update those functions, you can do it centrally.