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 email@example.com.
We are experiencing playback issues from our video hosting provider. Please check back shortly.
This lesson is part of the Scripting in Ignition course. You can browse the rest of the lessons below.
4:53Gateway vs. Client Event Scripts
8:40Tag Change Scripts
Take topic challenge
Take topic challenge
Learn how to write Gateway and Client scripts that execute on a timer.
Video recorded using: Ignition 7.9
Transcript(open in window)
[00:00] Timer scripts are great for repetitive tasks that need to happen over and over again. They're available at both the client as well as the gateway scope here. For this video I'm going to focus on the gateway scope though. So I will double click on the gateway event script section over here in my project browser and under timer you can see I already have a script to find. Let's take a look at some of the settings on this timer script here. I'll just double click on the script and you can see the name you can see that it's currently disabled I'm going to enable it so we can take a look at it in action in just a moment and there's also a delay. Now what the delay does depends on what you have selected for the delay type property down below. When using a fixed delay we'll try to maintain the delay period here in between each execution of the script. So let's say that this script here takes a long time to execute, it takes 500 milliseconds. So we'll wait for the script to finish executing and then we'll wait the full delay period again. So in actuality this script would only really be executing once every one point five seconds. The fixed rate type here on the other hand trys to maintain the schedule here under delay as closely as possible. So again in that same scenario if the script takes 500 milliseconds to execute once it finishes executing, we'll wait the remaining 500 milliseconds until we reach the delay period and then spin up a new execution of the script. Now a fixed rate is potentially dangerous as we could miss executions. So a more extreme example would be if the script took two seconds to finish executing. With the same delay period of 1000 milliseconds here we'll actually miss the delay period part way through our current execution. Now fortunately we don't stack up current executions in the event that we miss a delay period. So you're not going to run the system out of memory with a bunch fo qued up executions that were unable to run in a timely manner but as a best practice we generally recommend that your fixed rate scripts are given plenty of time to finish executing. Now our last setting would be the threading setting there are shared and dedicated options. When set to shared all timer scripts that are also set to shared will use the one same thread to execute with them. Shared would be the preferable option as we're not spending extra memory to spin up additional threads. However, if our script takes a long time to finish executing it could potentially block up that one thread and prevent other scripts from executing in a timely manner. So in that scenario it would be a good idea to use the dedicated threading option. As the general rule of thumb if your script is very quick to execute it should use the shared threading if it needs some time you should switch it over to the dedicated threading. Now I'm going to click okay here to enable my scripts. I'm going to select it again and you can take a look at what it's doing. I'm using system util get logger to create a logger and sending a hello message to the diagnostics logs on the gateway. So we'll click okay down below. Ill save my project let me bring up the gateway over here so we can look at it in action. Now I'm in the status section of the gateway scroll down and under diagnostics and logs I can see my test script over here it's printing my hello message and it's coming in at a one second rate over here. Now let's go a head and see what happens when an error occurs. So I'm going to bring my designer up real quick and I'm going to head back to the gateway event script section one more time select my script and I'm going to put a little typo in here just to make sure that this fails. So ill click the okay button save the project one more time head back to my gateway and here we are we can see that there is an error that came up from my timer script task here it's telling me the project, the name of the script, as well the rates and it's also letting me know that repeat errors of these types will be logged as debugged messages. So they're not just going to show in here by default. So it's very important to keep this in mind here if you have a timer script that fails in the middle of the night when no ones around you'll have to check the logs from that time period to be able to find the issue. Now fortunately we do have a bunch of tools to kind of help you filter by specific time ranges and recent searches and so on. I did want to point out that again under the status section over here under system gateway scripts you can see I'm in the timer section of this gateway scripts page here I got some information down below about my current running gateway scripts you can see it's error ed and if I scroll down a little bit further you can actually see the logging specific to this sub system. So I gave you plenty of tools to be able to troubleshoot and diagnose these kinds of problems.