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.