[00:00] In this lesson, we're going to be talking about chart best practices. And in particular, one of the most important rules you need to follow when designing your charts. So, when designing charts, you want to design your chart so that it is a responsive chart. And what that means is that the chart responds quickly to the pause and cancel commands. So if you remember from earlier lessons, when you try to pause a chart, the chart goes into pausing state, and it waits for any currently executing steps to finish up what they're working on. So for the case of an action step, that means that any currently executing script needs to finish before the chart can go into paused state. And the same thing for canceling. If you try to cancel a chart it goes into canceling state until the currently executing step has finished with any work that it's doing. And the reason it's important to respond quickly to the pause command is that when you shut down an ignition gateway, and it tries to persist the state of your chart so that it can be restarted upon startup, the gateway needs to pause your chart before it can save the state of the chart. And so you need to pause quickly because the operating system typically only gives the ignition gateway, a short time window in which to shut down before it will just kill the process. So that's why it's important to design your charts to be paused quickly. So a chart will be not responsive quickly to the pause and cancel commands. If it has a step that runs a script that takes a long time to finish. So for example, I have this very simple chart that has an extra step that has an on start action that executes a loop and so it's going to loop 60 times waiting a half second each, this going to take half a minute. And this is a simulation, of course. And there's a number of things that could cause a script to take a while to run. So, maybe a long running database query, or doing a whole bunch of IO. But typically, it's when you're trying to do lots of things, and oftentimes that involves a loop. So in this case, I'm simulating, maybe running a long query that's going to take half a second. And, but I'm doing 60 of them, All right? So, it's going to take me 30 seconds. And so if I run this chart, you'll see that the chart is ready to stop this step, but it can't stop it because of course, that script is running. And here we are processing our items. And if I try to pause this chart, it's going to be stuck here in the pausing state until our script finishes, which is when items processed equals 60. So the rest of this lesson is going to be focused on strategies where you can do the same amount of work, but in a different structure that keeps your chart responsive and we call that refactoring. So the first strategy to refactor loops is by using a loop in the chart itself. So you can see this chart here has a step called loop in it, which is going to initialize our counter to zero. And this is the thing that we're going to be counting up to 60 so we can process our 60 imaginary items. And then we have a step called do work, which does that same simulated work is just sleeping for half a second and it increments are countered. So instead of having a while loop in Python, we don't have a loop at all in our script, instead, we've got a loop in the chart. And the way the chart loop works is that you've got these two transitions, it's going to follow the left transition for item less than 60 until the item is 60, at which point, the chart will end. Alright, let's go ahead and run this chart and see how it works. So, when we start up the chart, we can see that our do work step is stopping because it's running our script and it's actually running over and over again, you can't really see that it's looping, but because this is true, we know this is just running over and over again, and we can see our item counter counting up. And if I pause this chart, we see that it went pausing for half a second, and then it successfully pause. So that's the big difference between the the last chart and this chart is that this chart successfully will pause and resume in the middle of doing all of its work. And then after 30 seconds, 60 items, this chart will finish and it's done the exact same work in the exact same amount of time as the other chart. There's one more way that we can refactor the same loop. This method doesn't have an advantage over the first method other than it's a bit more compact and on a really busy chart, sometimes minimizing the amount of chart structure can be advantageous. So, in this case, we have a single step, and it has an on start action, and the on start action does our initialization, and then it uses a timer action at a zero millisecond delay. So this timer action will just run as fast as possible, and it's doing the the inner part of the loop, in this case, just sleeping for half a second and implementing our item count. And then we use a transition that's just awaiting for the item count to become 60 in order for the loop to stop, so this is a much more compact way to refactor our first loop that we had done with scripting, and if we start this one, we can see that it is doing the same thing. In this case, the step is shown as running and step stopping because we're not ready to stop this step yet because our transition is waiting for the loop to be totally finished. And again, we can pause this thing and resume it and it's nice and responsive. So again to recap, the thing we want to keep in mind here for this best practice is instead of writing loops in your action scripts that might take a long time. It works a lot better to break up that loop into a chart structure loop or an action step timer, the zero millisecond delay and a transition so that the chart can remain responsive. And we can make sure that the ignition gateway can stop in a timely manner.