Do-more H2 (Micro Modular PLC) Videos

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.