Hide Transcript
View Transcript
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.