[00:00] In this lesson, we'll show how to install an Ignition SDK module into a gateway, so that it can be run within Ignition. Our emphasis in this lesson will be on the indicated portion of the development workflow. In a prior lesson, we loaded an existing SDK example project into IntelliJ and built it into an .modl file using Gradle. Now that we have a module file, we'll demonstrate how to install it into the Ignition gateway so that it can be run within Ignition itself. Let's see what needs to be done. So first, there is one important change needed in one key Ignition configuration file. This change will allow us to install and run a new unsigned module. It just becomes a lot easier that way if still doing lots of iterative development and test. For more specifics on signed versus unsigned modules, please refer to the SDK Programmer's Guide or the Ignition User Manual. So in my file system browser, in Program Files, I'll navigate down into my Ignition installation, which for me will be in Inductive Automation\Ignition.

[01:14] Then here in the data directory, we'll want to open up the file ignition.conf. Note that one possible gotcha here is that you will likely require admin privileges to open and modify this file. So in this file, scroll down a bit to the Java Additional Parameters section, where we want to add one more line: wrapper.java.additional. (some number) = -DIgnition. allowunsignedmodules=true This specific line can also be found in the User Manual, on the Gateway Configuration File Reference page. That page is linked in the resources section below. And here the number can be anything, as long as it doesn't conflict with any of the other settings above it, it doesn't have to be in order or anything.

[02:05] We will set it to 4 so as not to conflict with any lines above it. Note that for this change to take effect, we do need to stop then restart the Ignition gateway. So we will save our changes, do a Ctrl-S, and close this file. Then we'll go back up one level to the Ignition directory, which I will copy to my clipboard. Then to restart the gateway, we're going to run the platform independent command line utility gwcmd, but we're gonna need to run it with admin permissions from a command line. So we'll do the following. On my Windows system, at lower left, I will run a command prompt, right clicking to run as an admin. Then we'll change to that Ignition directory by doing cd and then pasting the directory path we copied. Then we'll run the command gwcmd -r, gwcmd. This will likely take several moments, so you'll have to be a little patient.

[03:12] And now our config file changes have been read by the gateway. Next, let's turn our attention to our already logged-in gateway window. We'll select the Config tab. Then in the System options, we'll select Modules, then scroll all the way down to the bottom, where we will click on Install or Upgrade a Module, and then click on Choose File. Here we'll navigate if needed to the location of our recently created module file. Recall that it will be located in our repo directory ignition-sdk-training, then in its example directory scripting-function-g, and then in its build directory. So we'll select our module project .modl file, and it's good to spot check that the build timestamp looks recent. This one looks current. Then when we click Open to select it, we'll choose to install the selected module file, and we'll get this disclaimer about loading an unsigned module.

[04:12] We'll just acknowledge it and proceed to install it anyway. Once we've successfully installed our newly created module, we'll notice two things. First, we've now got this green License Incomplete banner, and a countdown timer. This isn't a cause for concern, it's just showing up because our new module is unlicensed, and besides, we can always reset this timer as needed. And second, if we scroll all the way to the bottom of the modules list, we see that our new module is in fact installed and in the unsigned module section as well. Okay, so all this means, we're now ready to try out our new scripting function module in Ignition. So here we've skipped over the steps where we log into Ignition, open a project and launch the designer. Presumably those steps are pretty familiar to us by now. If they are not, please see another IU video which discusses all of these. Here we're starting in Perspective. If we look closely at our output console, we'll see a message about starting the module scripting-function-g.

[05:15] So that's a good sign. Ignition knows about the module we just added in the gateway. Even though we haven't examined the module code closely yet, what we've done in our example code is implement a simple scripting function, which multiplies two numbers together. So we need a simple way to demonstrate this in Ignition. Let's use the Script Console for this purpose. I'll head up to the Tools menu and select the Script Console option. And here, I'll type the simple command: print system.example.multiply Notice that by the auto completes we use, we already know this new function is present. Let's give it two arguments. How about 6 and 7? And when we click Execute, we see 42 printed in the output pane to the right. Let's try two other numbers.

[06:07] How about 5 and 8? Click Execute, and again, we get the correct result. That's it! Now we know everything is working correctly. So in truth, that was a pretty unspectacular example. But what's important here is the culmination of the process, not so much the result. We have just successfully demonstrated all the following steps. We pulled existing working SDK example module code from GitHub, into our IntelliJ development environment, built it into a module file, then installed it into Ignition and executed it. We just introduced our own simple custom scripting function into Ignition's existing system library. While that actual scripting function is pretty trivial, now that the steps of the process are established, now the sky's the limit as to what other custom elements can be created and incorporated into Ignition. In the next lesson, we'll circle back to take a look at some basic structure of the code we've just added, without getting too deeply enmeshed into all its specifics.