Programs and Tasks - Part I - The Fundamentals

It’s important to understand that Programs and Tasks are NOT subroutines. When you call a subroutine, the code that calls the subroutine literally jumps to the subroutine code, executes it and then returns to what it was doing and continues on its way. When you run a program or execute a task, the main logic just keeps right on going. All that did was arm the task or program so when the execution gets to it, it will run. Tasks and programs that weren’t armed during the previous scan don’t run. That’s really important to understand – when you call a program or enable a task they don’t get executed right away. When do they get executed? Well, that up to you. Over here in the project browser if you click on this execution order button, you can specify when you want something to be executed – if it’s been armed, of course. Does the main program have to be run first? No. You can make it the last thing to run if you want to. Just beware that if you enable a task or a program in the main program, it won’t be executed until the next scan which means it could be operating on inputs that have changed since the program or task was enabled. And that can be handy in some applications, but most of the time you’ll want to execute your programs and tasks THIS scan so they are all working with the same input values so you’ll usually put them below the main program. Of course, if this program depends on this task running first, then you’ll want to make sure that task runs BEFORE the program in the execution order. Of course, if this program depends on this task running first, then you will want to make sure that task runs before the program, right? So what would you use Programs or Tasks for? Well, I mostly use them for running background or asynchronous tasks or even running end of shift reports where I have to gather and manage lots of data infrequently. Stuff like that. For example, suppose you have a scan loop that is monitoring and controlling some system and you need some PID loops. Could you put them in your main ladder code? Sure. But since they are running their own independent process it makes more sense to launch them and just let them run off to the side all by them selves. These are actually located down here in whatever execution order you setup, I’m just showing them off to the side as a reminder that once enabled by the run instructions, they execute every scan and are off doing their thing independent of the main scan loop. Now you have a nice clean scan loop taking care of business, with these independent processes sitting over here running in the background. When you enable a task, it runs once through and it’s done. This is ideal for setting up or initializing the background process you are about to launch or maybe doing a report at the end of a shift where you just need to collect and store a bunch of data. So a task would be ideal for setting up the PID loops before you run them, again, because it runs once through setting up all the PID parameters and it’s done. Could you do this single pass with a Program? Sure, but know this: TASKs are much more efficient and execute quicker than a program. So if you can use a TASK, do it. Most of the time you will want to run a program to start it, and then let it run forever. But if you do need to stop it, there’s a number of ways to stop and restart a program. The debug menu one is handy. Maybe you need to shut down a PID or Communications process running in the background while you are doing some debug on something else. That’s a quick way to kill a program without modifying your code. To stop a program from within the code, the EXIT instruction allows the program to terminate itself so it can finish what its doing and shut itself down. And you can even make the EXIT conditional. HALT allows something external to the Program or Task to shut down the program or task you choose here. SUSPEND prevents the Program or Task you specify here from running during any scan that the SUSPEND is enabled. The key thing to understand here is SUSPEND maintains the current state of the program or task so when you remove power flow from the SUSPEND the Program or Task picks back up right where it left off. Maybe it was in the middle of a loop collecting data but you needed to suspend that task while some other time critical process had to be taken care of. That time critical process simply suspends the TASK or PROGRAM and then releases the Program or Task when it’s done. That’s a great way to ensure background tasks don’t interfere with critical path processes. RESTART also halts a program or a task, but it also resets the Program or Task so on the next scan it starts running from the beginning. That’s for when you have a process that when it gets to a certain time of day or to a certain level or something like that and you need for it to restart regardless of what it’s doing. If you have a TASK or a Program talks up a lot of time, how do you break it up into smaller chunks that are spread out across multiple scans? Easy. Just right click on the program or task, and choose one of these. We’ll cover all of these options and show you how to take advantage of them in the next video which is dedicated to Yielding and some other lose ends. And in the final video in this series we’ll do some live examples so you can see exactly how to get the most out of Programs and Tasks in your own code. If you have any questions, please contact AutomationDirect’s free, award winning support team during regular business hours. They will be happy to help. And don’t forget the forums. There are lots of automation professionals there that love to share their years of experience. Just don’t post any questions directed at AutomationDirect’s support team there, they don’t monitor the forums on a regular basis. Spend Less, Do-more. With AutomationDirect.