subroutines,how works it?

aleziv

Member
Join Date
Dec 2009
Location
belgrade
Posts
15
Hi everybody,
Now I looking at one program in the SLC 500, my experience with plc is very poor, with that maybe my question looks very simple for somebody, ok when I open main program I could see a lot instructions “jump to subroutine “rather 35 instructions, what are those instructions means for the program, are this initially wake up of program or something else, I suppose that subprograms represents some of the part from the system, for me very interestedly how processor uses instructions?
Thank in advance a lot.
 
A subroutine is a compact way of using a codesequence many times. Instead of writing the same code over and over again you can assign the code to a subroutine. ie when you "call subroutine x" the program behaves as if the complete code as written instead of just a subroutinecall.
On top of that you can write a subroutine so that when you call it, you can add a number of parameters so the subroutine behaves different depending of what parameters you added to the call.
 
I think maybe what he is seeing is a program who's main ladder logic consists of a series of calls to subroutines (I've seen it at the place I'm working as a co-op student). I've been wondering about it myself, actually. Can someone explain why the main pogram in something might consist of a bunch of subroutines, rather than just going right into code. Is it just there to organize things in more "encapsulated" sections where you only need to see the instructions related to whatever the purpose of that subroutine is?
 
Mainly Organization

Bobbias: You are correct when saying that it organizes the program better. You could create the whole program in the main routine (which has been done a lot) and it would be fine. However troubleshooting or de-bugging becomes a nightmare. this is not the only reason however is the main reason.

This discussion can and probably will go into much more detail but you have the general idea.
 
The best way to describe this is to refer to it as a form of modular programming. Take for example C++ or quick C rather than write code that is used over and over again in different programs or repeatably in the same program its easier to write the program once then refer to this routine whenever necessary In C++ or quick C you link this smaller programs with the main to add them but those smaller programs can also be used in other programs.
Now in PLC's they usually don't link outside programs however the habits of software developers often transport from one platform to the next.
In this case there is still several advantages one it avoids what is often termed as spagetti code (code where you are constantly having to look through it beginning to end and back to middle to end to start etc etc etc. The modular style was developed to correct the old Basic programming habits (caused by nested loops). Usually in a PLC the subroutines will perform a specific function and serves as a means of organizing the seperate tasks involved.
The C++ equivelent or standard practice is that the main programs only function is to call the seperate subroutines so in this case its exaclty as you described a main that does nothing but call up subroutines. Other than organization there is no significant advantage in PLC's other than it makes troubleshooting a problem a lot easier if all I have to do to look at a code issue is to look at the sub routine assigned to it rather than having to pour through the entire code to find the various elements.
 
With AB the subroutines are more organisational rather than saving the amount of code. You can pass in parameters and make them unique but your program will grind to a halt.

If you have 20 conveyors you can write 20 sub routines, each one for a particular conveyor, then you call each sub routine in turn.

When you are fault finding, you don't need to search through one long continuous routine looking for the conveyor you need, you just open the subroutine that runs that conveyor.
 
Make the jump conditional

Another reason to use the jump is you can make it conditional. IE several conditions have to be meet before you jump into this sub routine. It is also very good for sequencing. How you order your jumps will decide which happens first.

Awhile back when PLC's were not as fast as they are now I used the jumps to speed up the scan. In other words I ignored some subroutines while I ran others. The net effect is a shorter scan time.
 
There are also a number of ways to use subroutines to organize the program. For example you can organize a program by zones, eg ZONE1, ZONE2, etc, or by function, eg, closing, injecting, cooling, opening, or by state, state1, state2, etc, or a combination of the zone/function/state or any other division that makes sense. Its not uncommon to group similar things together, for example all outputs might be in one subroutine while all analog scaling is in a different subroutine and all alarms are in another.

For example, I'm looking at a program right now for a large vacuum furnace that covers a 4 meter x 15 meter area. Its divided into zones: Power Supply, Chamber, Gas Quench System, Sweep gas system, Cryo Traps, Pumps, Chiller. Each zone is further divided by function, for example, the chamber has functions for roughvac, hivac, gas sweep, heating, backfill, quench.

You can organize in any meaningful way. For example you might decide to allocate program files 10-19 to zone 1, program files 20-29 to zone 2. You can do the same thing with data files.

What is most important is that the organization makes sense and that its obvious. Avoid overly complex program organization schemes. That means that sometimes you'll use just use a few sequential subroutines, other times you may use quite a few. I try to avoid nesting subroutines to make it easier to find where a subroutine is called from, but that is not a hard/fast rule because sometimes it makes sense to nest them.

As a general rule of thumb I try to break a program down into pieces that can be coded in less than 30 rungs. If I can't code a function in less than that I try to break the function down a little more. This is not a hard and fast rule but its a useful method for handling large and complex programs.
 
Last edited:
Passing Parameters

With AB the subroutines are more organisational rather than saving the amount of code. You can pass in parameters and make them unique but your program will grind to a halt.

If you have 20 conveyors you can write 20 sub routines, each one for a particular conveyor, then you call each sub routine in turn.

When you are fault finding, you don't need to search through one long continuous routine looking for the conveyor you need, you just open the subroutine that runs that conveyor.

Passing parameters will actually reduce scan times and not bring program to a halt. By passing the parameters the processors does not have to go "search" for the tag that is associated with a parameter. This is true with AB anyway and I am not sure how other processors utilize the passing of parameters.
 
Passing parameters will actually reduce scan times and not bring program to a halt. By passing the parameters the processors does not have to go "search" for the tag that is associated with a parameter. This is true with AB anyway and I am not sure how other processors utilize the passing of parameters.

I'll agree to disagree.
 
The truth is somewhere between the previous two posts.

Passing parameters into a subroutine will cost more time than not passing parameters. The operating system needs to copy the parameters being passed between the data location listed in the JSR and the data location listed in the SBR. That takes some finite amount of time per instance. Also, the processor doesn't need to do any more searching regardless of where the address is located. It is the same either way.

Having said that you would need to pass ALOT of parameters before you have a meaningful effect on scan time. Data manipulation is data manipulation. Parameter passing is in effect a MOV. I have many, many MOVs in my programs and I still typically stay under 20 msec in scan time.

Keith
 
Thanks guys for opinions, I something understood and something not, Peter W gave me figurative answer with conveyers and it is ok, in global for me intelligibly way we using subroutines, when I look in our program I could see also some conditions before we execute subroutine now it is clear for me, next question, all commands “jump to subroutines” are in one file which have name “main block” with specific numbers (not names) also our program divided per block of the line(extrusion line)for exe. LED2 FURNANCE file etc, are possible direction connection between LED files and subroutines? Is this having same meaning?
Thanks a lot in advance.
 

Similar Topics

I am trying to do a subroutine using a Q series (Q06UDEH) plc and GXWorks 2. The manual says to use a FEND and then start the subroutines. Each...
Replies
3
Views
3,996
I have been asked to extensively modify a piece of machinery that is very mission critical to the operation, thus not allowed much downtime or...
Replies
4
Views
2,281
We have an application where we need to indicate a piece of machinery needs maintenance. I have created a routine which resets a value of "days...
Replies
12
Views
3,720
Hi all. Please see attached. Tried to google the error with absolutely no results. I did the same at payed version and real PLC so I'm almost...
Replies
7
Views
2,334
hello all is there a rule of thumb as to using or not using subroutines when writing a program ? i am using an Allen Bradley slc 500 thank you...
Replies
5
Views
1,733
Back
Top Bottom