This lesson is part of the Module Development with the Ignition SDK course. You can browse the rest of the lessons below.

LESSON LIST

Autoplay Off

Description

Learn how to use loggers in your SDK Java source code, to trace the flow of execution of your module project.

Transcript

(open in window)

[00:00] In this lesson, we'll demonstrate how to set up some rudimentary debug of an Ignition SDK module using loggers, and show where those logger messages get displayed based upon their module scopes. Our emphasis in this lesson will be on the indicated portions of the development workflow. Now that we've seen how the module code is compiled, executed, and structured, we'll likely need some way to trace its path of execution and debug it as needed. There are two ways to do this: using logger message outputs, and attaching an IDE debugger to a running Ignition SDK module. We'll consider the logger approach here and save the other way for a separate lesson. Using logger messages with an SDK module is a pretty simple process. We will simply create a new logger object in each Java source file that we want to look into, add longer messages at the appropriate places in each file, then of course, rebuild the project and reinstall it in the gateway. And finally, run the SDK module and observe its outputs, which will show up in different places based upon the scope. For gateway scope log messages, in the gateway logs; for designer scope messages, in designer console messages; and for Vision client scope messages in the client console.

[01:17] Let's now demonstrate how all of this is done. Here in IntelliJ. We are back in our original scripting-function-g example project. We have 5 of the 7 Java source files open in these tabs. Here in GatewayHook on line 17, there is a logger object initialization statement. It will be exactly identical in each of the other files, and if it is not already present, then it needs to be added, exactly as shown. inside the class. Each such dedicated, created logger will be named the same as the class it's created in due to its getClass initialization. Once this logger object exists, we can then add logger statements in any desired locations so that we can trace the execution path and inspect any data of interest. I have the needed such logger statements in a text file off screen, so we will go through the 5 files and simply copy-paste to insert those statements at the desired locations.

[02:14] So here in GatewayHook, down on line 28, we will add a logger print to the setup method, And on line 37, to the startup method In DesignerHook, at line 18, the needed logger initialization is present. Then after line 22, we will add a logger print to the startup method. In ClientHook at line 16, the needed logger initialization is already present, but here there is no startup method. So we will first need to add one, after line 29 by overriding as follows. Then inside that overridden method, ahead of line 35, we will add a logger print to the startup method.

[03:10] In GatewayScriptModule, here we do not have a logger, so we will first create one inside the class. Then inside multiplyImpl, we will add a logger print ahead of the return statement. Here we're also using the positional braces syntax to include parameters in the message. And finally, in ClientScriptModule, once again, we do not have a logger, so we will first create one inside the class. Then again, inside multiplyImpl, we will add a logger print ahead of the return statement. We've now added 6 logger.info messages to the 5 Java source code files. Let's now see where such messages show up. Obviously we'll need to recompile, reinstall, and then execute our changes.

[04:03] We won't repeat these steps, as they've all been shown in prior lessons. So here we are in the Ignition gateway, and we'll see the two gateway scope messages appear in the log file after initial module installation. If we go to the Status tab, then down to the Diagnostics section, then Logs, where we will see the two GatewayHook logger messages for startup and setup. For designer scope log messages, we'll see those appear down here in our output console. If I scroll down just a little bit, here is the startup logger message from DesignerHook. Then to display the Vision client scope startup and execution messages, we're going to take a slightly different approach this time. We're going to use this window to demonstrate running our SDK scripting function. This button runs an event script, which reads any two ints from the left, internally calls the SDK function system.example.multiply, then writes the result to the right side.

[05:10] But rather than run this in the Script Console like last time we saw this, we're going to run in a dedicated Vision client window this time instead. Let's open that minimized vision client from our menu bar. Then let's also open up its Help > Diagnostics > Console window, and let's expand it a bit. Here we see the startup message from ClientHook. Finally, let's actually execute our SDK module scripting function. But first, if we were to examine the example code closely, we'd see that it gets invoked on the client, but actually gets executed back on the gateway via a remote procedure call. We won't go over all those details here, but it's something to look for as you study the example code. What this means is that we should see some logger messages arising from both the client and the gateway scopes. So let's input two random values.

[06:06] How about 6 and 7? And we'll click the button. Our module scripting function gets executed under the hood here, and we see the correct 42 result. Note that we see that result from the script echoed in the console window also, but in the client console, we also see this logger message from the client's script module logger, and if we restore our gateway window, we also see a similar message arising from GatewayScriptModule logger. So summing up, we added 6 logger messages at various places in all three scopes of our module code, and we saw 6 corresponding logger outputs appear in the various scoped outputs. So now we've seen how to add and display debug logger messages in our SDK module code.

You are editing this transcript.

Make any corrections to improve this transcript. We'll review any changes before posting them.