I like that I can see the scripts that error in the logs.
I was wondering if there is another spot where I can see a list of the scripts that ran successfully, where they are located, and when they ran.
I have a script that is running correctly, but I want to know about when it runs.
I know I could add a logger, but wondered if there is a way to maybe filter logs for seeing those that ran successfully, or what is required.
The Ignition Gateway allows you to view gateway scripts that have run, such as timer, tag change, message handler scripts, etc.
To track the successful execution of scripts, especially those associated with UI components like buttons in Perspective, using loggers is a practical approach. Although it requires adding log statements to all relevant functionalities, it provides a clear record of when scripts executed and if any errors occurred.
Here's how I recommend handling this:
Use Loggers: Adding loggers to your scripts will enable you to see when they run successfully. Although it requires some setup, it ensures comprehensive logging.
Try-Except Block Incorporate a try-except block in your scripts. This allows you to log a message when the script runs successfully and capture any errors that occur.
I just want to add a suggestion.
You can use a logger, like @Noah_Casey said. It's really useful to have information about your script and for debugging.
At first, you might be tempted to use the information level, but this is the default minimal level of the log, and all information logs will be displayed in the gateway log.
Instead of the information level, you can use the debug level, which is hidden by default and will not flood the log. Then, when you want information about a script, just change the minimal level for this logger name to debug.
When you have hundreds of scripts running frequently, it can be hard to find the desired information in the flow of logs.
Sorry, where in the gateway can I see a list of the scripts that ran successfully, where they are located, and when they ran?
Or a custom logger is required?
Thanks
Inside of the gateway is the status section is a tab called "Gateway Scripts".
Now this will only show scripts that execute on the gateway such as timer, tag change, message handler, scheduled scripts, etc. (This will not show logs for scripts executed in places such as perspective, or vision where the script lives in a button.)
Here is an example of one of our gateways:
Below the execution status it also has log activity that goes into more details.
I mean, I want to see the script, where it is located, and the time that it ran down to the seconds at least.
Like I have a script to run at 7am, and it is working.
I have another on a change script, it is working.
I want to analyze their timings.
I also want to know if my change scripts are trampling themselves on the same tag.
But if I have to do loggers, I have to do loggers.
Though I also have this other gateway, where a script is running a log, and I don't know where it is coming from as like an additional concern on another location. For that one, I just want to find the logger and set it to debug or deactivate it.
Which scripts exactly do you want that information on?
If it is a script that isn't Gateway Event Script, so a timer, tag change, message handler etc... then you WILL need to create a logger and log the data you want to see.
I created a python decorator that I use for the scripts that I want to get this information from. It creates a logger for the function, and it will profile most of the function so I can turn on a debugger and see what is passed into the function and how long it takes for the script function to operate.
One unknown logger source (script)
One change script
One gateway scheduled script (seems like it is a few seconds late sometimes, but I don't think it is)
You best best is to create loggers for those scripts and log the data your specifically want.
If you want a pretty table to data, you will need to pass the information that you want to the database to log, using async logging so you don't hold up the script, then you can use that as sort of an action log.
What about identifying that one pesky logger's unknown source?