I have a question on best practices and most efficient ways to trouble shoot gateway tag change event scripts? I can’t use the script console because my scripts always have event tag paths, parent paths, etc. and errors always pop up for the variables not being defined. Is there a way around this? If not, what is the best way to troubleshoot the gateway scripts?
I have realized that my gateway script stops executing on an error, which I must currently have in my script. Though, its not a compile error. On top of not being a compile error, my java exception doesn’t catch the error either.
Use loggers liberally at debug level throughout the script.
When first writing a script, I do so for 1 tag, I hard code the tagPath and/or parent paths, and other things and insure that the script works as expected. Then I move on to a list of hardcoded paths if needed, before I ever actually implement it in the gateway. Even then I still insure that I use a logger, sometimes even multiple loggers in the same script, so I can look back and get an idea of what went wrong.
Use multiple except blocks to ensure you catch jython exceptions as well as java exceptions.
Thanks for the tip. Do you by chance have a link that explains throwables and how to use them? I have never used them before and I didn't find anything about them in a search for Ignition 8.1 manual.
Throwable is the ultimate parent of all java exceptions and errors. It is the container for anything that has the structure message, traceback, and cause. Ignition’s loggers have method signatures that include Throwable for when you wish your log entry to have a stack trace attached. That’s particularly valuable when you are suppressing an error but want the source reported.
My later.py script includes a class that can wrap a jython exception in java format so you can log it with the jython traceback (mostly) intact.
Where can I access this script? Thanks for your response, though unfortunately it unravels more questions for me. I need to learn what loggers and stack traces are.
Loggers are objects that, well, log. Specifically they are wrappers that write messages to the console log at specific levels. Where exactly you go to see that message depends on the scope in which it is called.
You use system.util.getLogger() to get a reference to a LoggerEx object which has specific functions which log the messages at different levels.
Stack traces, basically, are a list of function calls leading from the function in which code is currently being executed back to the top.
Think of it like this, each time a function is called, it is placed on a pile, subsequent function calls are placed on top, before you can remove one from the pile it must complete its execution and complete. You can only remove things from the top of the pile, and thus it’s called a stack. Another name you might see for this type of structure is LIFO (last in first out).
It is often included in debug messages to help indicate the path the program took to generate the error. This is useful when a function can be called from many places.
You’ve undoubtedly seen a stack trace, probably even used it to debug, and just didn’t know that it was called a stack trace.
Of course there is a more technical definition for why it’s called a stack trace but that’s not entirely relevant here.