Do-more H2 (Micro Modular PLC) Videos

Hide Transcript

View Transcript

Subroutines are great for building re-useable

and easy to maintain code because it let’s you use one chunk of code in multiple places. And that saves you time and effort. Let’s do an example so you can see how to

use subroutines and learn exactly what you can and – and more importantly - can’t

do with them. Suppose we have an analog input measuring

something like the fluid level of a tank. And when it gets to a certain level let’s

scale the input by some scaling factor in R10 and put that in D1. And when we reach a certain calculated result,

we want to turn on an output coil and an analog output that is a scaled version of the input. Now suppose we need to use this code for several

different machines or processes. The temptation is to copy this code, change

the input, the calibration parameters and the outputs. Then copy it and do it again and again and

again for each machine. But that’s a lot of work, the code is really

hard to read and when it comes time to change or update the code you have to do it all these

different places and hope you didn’t miss anything. The easy way to do this is to create a single

subroutine using this code which is identical every time we use it and then just tell the

subroutine which inputs, calibration data and outputs to use. To do that, you call the subroutine with a

call instruction. We haven’t created that subroutine yet,

so we’ll just do that here by giving it a new name. The yellow dot is reminding me the subroutine

doesn’t exist yet. That’s ok – we’ll fix that shortly. Our input to the routine is WX0 so internally

we’ll copy that to N100 for the subroutine to use internally and we only need one of

those. We’re multiply the input by R10 – that’s

fine. And for outputs we need a digital internal

register to map to Y0 and an internal analog register to map to WY0. You can re-arrange the rows, delete rows,

and move rows around. We’ll use this as a power flow enabled subroutine

– you can make it edge triggered if you want to - and we can add a counter that keeps

track of the number of times this routine gets used. That can be handy when you are debugging. We’ll leave it disabled for now. Hit OK and Do-more designer reminds us we

have a new subroutine name – did we want allocate memory for that? Yep. Do we want to create the Subroutine for that? Yep. The name is already filled in and since you

can’t do time slicing in subroutines all of this is greyed out. You can password protect the subroutine – but

be careful. Make sure you don’t forget that password

– if you do the only way to recover the PLC is to clear it and reset it to factory

default. Well look. Here’s our new empty subroutine. I’ll use Shift up arrow to select, and control-X

to cut. Go over to the new subroutine and I’ll use

control-Z to paste it in. This block of ladder code still has the original

references so let’s change those to the generic internal references. WX0 becomes N100 here and here. Y0 becomes C0. WY0 becomes N101. All subroutines require a RETURN instruction

at the end, but Do-more designer already put one there for us so we are good to go, though

I am going to delete these extra rungs just to clean things up a bit. So whatever gets mapped into N100 will get

compared to this and if it exceeds that, then that result will get multiplied by whatever

is in R10. If that result is greater or equal to than

this, C0 will get set and the result will be copied to N101. To use the subroutine we just use the CALL

Instruction to map the external values we want to use to the internal registers in the

CALL instruction - which we already did - so we are done. In this subroutine we are using R10 as a scaling

factor. That could be set anywhere, OR we could set

it in the CALL instruction. It’s nice to do it here in the Call instruction

because now everything you need to know is in one place. That’s all there is to setting up a subroutine. You create the subroutine, map external registers

to internal registers, and you are ready to go. But here is the real power. When we need that code to run another machine,

we just use another CALL instruction. And look at this. Do-more Designer asks if we want to use an

existing parameter list – of course we do. We want this guy’s parameter list with the

2 ins and 2 outs. Look at that. The parameter list is ready to go – we just

fill in the empty boxes. Suppose this new machine’s analog input

is coming from WX1, the calibration number we need is this, the output coil goes to Y2,

the analog output goes to WY1 for this new machine. Done. So this line of code is calling the subroutine

using these I/O can parameters. And this line is calling the exact same routine

with but with these parameters. I can now do this on as many machines as I

want and every one of them will use the exact same code in the subroutine. So if I ever need to change that code I only

have to change it in one place. And that makes maintain and debugging your

code so much easier. There are a couple things to keep in mind

when using subroutines. You CAN use loops in a subroutine, just beware

that since subroutines don’t have time slicing the routine won’t exit until that loop is

done which could have a big impact on your scan time. If an OUT instruction in a subroutine turns

on a coil inside a subroutine that coil will stay on when you exit the routine because

the subroutine is really just a continuation of the calling logic so the power flow is

always present. When you exit a program the power flow is

disrupted so the active OUT instruction turns off. So make sure you understand that difference

– it’s really important. You can’t use edge triggered inputs inside

a Subroutine because they require two scans to see one state of the signal on one scan

and then the changed state on the second scan. And there is no way to guarantee the subroutine

will be run for more than one scan. So that’s why Do-more designer won’t allow

you to use edge triggered instructions in a subroutine. Same thing for asynchronous instructions. They require more than one scan and we can’t

guarantee the subroutine will be run for more than one scan so Do-more Designer warns us

when we attempt to do that. Other than those couple special cases, for

all practical purposes subroutines are no different than your main code block. By the way, Subroutines CAN call Subroutines. You can nest those calls up t 84 calls deep. Just beware that will have an impact on your

scan time. Subroutines can also call themselves. We call that recursion. That’s real handy if you are searching for

files in directory structures. You have a routine that goes down into a folder

and looks for a file. If it finds a folder, it calls another copy

of itself to drop down into that folder and search for the file. If it finds another folder, it calls another

copy of itself to drop down into that folder and search for the file. Etc. We call that recursive programming. Will you need this very often in your day

to day PLC programming? Probably not. But when you do – it’s an awesome feature

to have in your back pocket. Just be careful – as you can image this

can have a huge impact on your scan time. Finally, subroutines don’t have a structure

associated with the like the other code blocks do. Which explains why this counter is an extra

thing off to the side. The other code block have that built into

their structures – right? We’ll that ought to be enough to get you

going with subroutines. If you have any questions, please contact

AutomationDirect’s free award winning tech support 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 anything directed at AutomationDirect’s

support team there, they don’t monitor the forums on a regular basis.