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.