This version of Internet Explorer is either no longer supported by Microsoft, or is obsolete and some features of our store may no longer be supported.
Please consider upgrading or use a different browser.
**Prices were valid at the time the video was released and are subject to change.
Software Version used in this video: Do-more Designer 2.0.0
So what is the difference between a task, a program, a subroutine and an Interrupt Service Routine? In this video we’ll take a quick look at the differences at a very high level and then in separate videos will focus on each one with live examples so you can see exactly how to use them. Normally, a PLC program reads its inputs, executes its logic and then updates the outputs. We call that a scan. Suppose we have a bunch of rungs of ladder code here and the exact same lines of code here and here. When ever you see redundant blocks of code like this, think about pulling that code out and putting it into a subroutine. Now the ladder code just has a single call to the subroutine and all three call the exact same code. Now if you have to modify it in the future you only have to modify it in one place. That saves you time and effort and just makes your ladder code much easier to read and maintain. You can even pass the subroutine parameters so if each section needs to use different values you can do that too. The key thing to remember is the Subroutine runs as if it is part of the main scan loop. The main loop jumps to the subroutine, executes it and then picks up right where it left off. So you are still running the same long scan loop, it’s just packaged a more modular easier to maintain fashion. And it also takes less memory. So if you have redundant code that may just need to use different values but does the exact same operation – Think Subroutines. Programs are not subroutines. The Main Program is a Program that is guaranteed to run every scan while the PLC is in RUN mode. The cool thing about the Do-more is you can create your own programs. Suppose for example that you have several machines in a process line. Maybe one preps material, one drills holes, one rivets, and one does some kind of finishing work. You could do all of those in one long monolithic block of code, or you could pull each one out and create a separate Program for each. Then in the Main program you just RUN each routine to enable it and they all go off and run their own machine – I like to think of it as independent background process. Programs are also good for processing asynchronous things like handling of incoming messages. You start the message handler program with a RUN command and then it just patiently waits for messages in the background while the main scan loop runs its normal processes. When it gets one it processes it and then goes back to waiting. Again, an asynchronous or background process. So any time you have a large bock of code that’s running multiple processes that each needs to run continuously or even for just several scans at a time, think about breaking the code out into separate programs. You can do all the same stuff in a Program that you can do in main program loop, but it will make your code much easier to read and maintain. In this example main launches each of the processes and then sits back and does nothing. We’ll do some live examples of this in the video dedicated to programs and tasks. A Task is basically a stripped down Program. The main difference is it executes to completion and exits. One pass and it’s done. It won’t execute again until it’s re-enabled. Of course, since a task only runs one pass, it doesn’t do stage programming. That wouldn’t make any sense because stage always runs over multiple scans – right? Tasks are ideal for doing things that just need a single pass like checking an alarm value periodically because you can just call that code block when you need it OR you can tell the Task to do periodic updates for you. That’s cool. Tasks are also great for doing episodic stuff - maybe you need to calculate the production rates and values at the end of a shift. And calculating all of that stuff is going to take a long time relative to your scan. Well, look at this. You can tell a Task to only run for a limited amount of time – we call that a time slice. So now it might take several scans to finish the calculations, but since it only does a little bit at a time, it doesn’t affect your regular scan interval very much. That’s a great way to make sure your episodic task doesn’t overly burden you main scan loop and slow down your machine processes. Time slicing can also be used with Programs so you can dedicate the bulk of the scan to one machine or process and the rest of the scan time to the others if you want to. That’s one of the things that makes the Do-more so powerful. You have complete control over exactly how your system runs. You also have complete control over WHEN things run. You can tell the Do-more PLC what order you want the various tasks and programs to run in. We’ll do several live demos of time slicing and execution order in the video on Programs and Tasks. For now just know that it’s an amazing feature of the Do-more PLC. Interrupt subroutines are great for handling events that need to be serviced right now. You have a scan loop, and maybe some programs and tasks and they are doing their thing. But when a triggering event occurs you want to run a specific block of code as soon as that event happens. Maybe you want to react to the rising edge of a signal when it occurs and not wait until the next scan to see something changed for example. That’s a good example of when you would want to use an interrupt service routine – or ISR. It doesn’t mater where the program is in the scan loop, the program immediately jumps away, executes that ISR and then comes back to where the scan loop left off and continues on its way. It’s kinda like a subroutine that can run when ever a triggering event happens. That triggering event could be an external input coming in, a timer timing out, all kinds of things. Of course, since it is interrupting the flow of the scan, you always want to make sure the ISR is just as short as it can possibly be. For example, in an ISR, all you would do is make note that a signal changed. Just take note that a signal changed and let some other routine take care of the details later. Don’t try to do any more than that in an ISR, otherwise it might impact your scan time. So we have Subroutines which are great for cleaning up redundant code. We have Programs which are really great for running independent processes. We have Tasks which are particularly good for periodic and episodic processes that only require one pass. And we have Interrupt Service routines which are great for reacting immediately to an event of some kind. All of which make maintaining and debugging your code a whole lot easier. This was just a very quick introduction there’s a whole lot more to this. Check out the dedicated videos to learn exactly how to use each of these powerful tools. And 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’s lots of experienced automation professions there that love to share their years of experience. Just don’t post any questions directed at AutomationDirect’s support staff there, they don’t monitor the forums on a regular basis. Spend Less. Do-more. With AutomationDirect.