Subroutine Instructions - SLC 500


Thread Starter


Hello Everyone,
What is your opinion of the SBR instruction in SLC 500 programming. The online help in RSLogix indicates that it is optional but recommended to use. I have never had a problem going without it but wonder what other people's experiences are. What is the purpose of it? Is it just an old instruction that newer firmware doesn't need anymore to process additional subroutines?

Thanks for your responses!

Steve Myres, PE

Well, if you use enough subroutines and use an SBR to start them all, it might use enough memory to push you to the next processor size! Maybe they should call it an AB$ function. I never use them.
What are you talking about? subroutines save memory they do not waist it.

There are many reasons for JSR’s

First is organization, by using them you can cut down the trouble shooting time...I have several programs that would be 1000 or more rungs have a tech trouble shoot it, unless I had subroutines would be a pathetic waist of time.

Second is processor speed by using them I can have only certain subroutines scan, I can cut the scan time by 50% sometimes

I use them in AB, Siemens, etc, all of my programs, any GOOD program that I have seen have used them.


There are several purposes of subroutines

1st is to make a very large program manageable and allow the reader to be able to understand your program, I have several programs that would be several thousand rungs long, but using subroutine, this allows me to be able break the program into parts...if the troubleshooter of the machine is having trouble with one part of the machine, he would be able to concentrate on that part of the program

2nd is for processor speed if there is a part of the machine that can sit and not run, then I would be able to only scan that part of the program when needed.

Hope this helps


There are several reasons for subroutines...

First being in large programs they would be unmanageable, I have several program that would be 1000 rungs or greater, by breaking them down it’s easier for someone to read my programs.

Along the same line if I break the code down to parts of the machine then the person that is trouble shooting the machine could cut the time down by going to the specific part of the machine/code.

Third, processor speed if I only run half of the program (only what I need) then my processor speed has doubled.

There are many more, but try and think of them as organizational tools, they help you control the code not the code control you.

Hope this helps
The SBR statement is very usefull in my world of automation, robotics and interface. Using SBR instructions allows you to perform different functions within the program in a specific order dependent upon certain conditions, then return to the main program where it originally was. This saves programming time and PLC memory as well as PLC scan time. An example I have used would be interfacing the PLC with a pick and place robot and a vision system. When the robot has the part visually checked, it will be good or bad. The vision system provides an output to the PLC. Good part input becomes true, the rung for your good part program SBR comes true and those instructions are excecuted. Once the SBR returns to the main program, the PLC scan continues from where it left off to complete the program. Likewise for a bad part detected. The bad part input comes true and this completes the rung for the bad part SBR. Once the subroutine is complete, the PLC returns to that point in the program and continues.

Hope this helps.

Gerald Beaudoin

I shared a similar opinion until the programms that I was dealing with become more and more complex. By breaking the program down to more manageable subroutines, each dealing with a discrete task, it is much easier to debug and understand what is going on. Just the fact that each subroutine is appropriately named confers a great advantage as to where to look for a problem. Using the subroutine technique also allows you to develop a new subroutine without executing it until you are finally ready. By the simple inclusion or exclusion of the JUMP instruction, you have complete control over a subroutine that may still need tweaking. A 20 line program doesn't make much difference one way or the other, but I have seen those simple tasks explode into more complex ones because of add ons and modifications. Good programming dictates good structure that allows for easy integration of unknown future considerations. Try debugging a program of 1000 lines of code in a single routine, and then consider how much easier it would be if it were broken down into 10 or 20 named suboutines....I think you will quickly get the point !

Gerald Beaudoin

Trevor Ousey \(list\)

SBR instruction is not required in the SLC5 series subroutines, as well as
the RET instruction. All you need is the JSR instruction to jump to the
different subroutines. I feel these instructions (SBR/RET) are just there
because of the old days. JSR's can be conditional and again don't require
SBR or RET instructions. I have not seen any degradation in performance by
removing these instruction.

Now if we were talking about PLC5's and ControlLogix SBR's and RET's can be
used to pass parameters for JSR's.


Steve Myres, PE

Guys, guys, guys! Reread the original post. the guy isn't asking about SLC subroutines per se, but about the "SBR" instruction. The instruction used to branch to a subroutine is the JSR (Jump to SubRoutine). The SBR, by contrast, when used, is just a static label to be the first instruction in the subroutine, and doesn't actually do anything anyone can determine.

So all your defense about why subroutines are good is beside the point. He's asking about the SBR instruction.

Steve Myres, PE

Well, now the RET is a different kettle of fish in that it actually has a function. If I have a subroutine that doesn't always need to be completely executed, I'll do a conditional RET at the branch point or points (or sometimes JMP/LBL pairs).

As far as putting one at the end where one is implied anyway, why would anybody do that?
I agree about the PLC5 and passing variables in/out of the soubroutine. I was curious as to the acutal use in a SLC. I see it in other people's programs but it doesn't appear to do anything except use up a word or two of memory. Oh and about the comments about using subroutins I fully agree with what people say - it is the proper way to program for ease of use and troubleshooting.

I enjoyed all of your reponses and thank you!
I was thinking the JSR as well.

Subroutines jump to other programs. If in the JSR instruction two arguments are passed, say N7:0 and 123, the subroutine (SBR) function will receive these two arguments and put them in say N10:0 and N10:1. When the subroutine ends and returns to program file 2 where it was called, the RET function can also return the value N10:1 to the calling program where it is put in location N7:1. By passing arguments (instead of having the subroutine use global memory locations) the subroutine can be used for more than one operation. For example, a subroutine could be given an angle in degrees and return a value in radians by calculation in the subroutine. Not one of the more common instructions used. The integers givin are just examples.

Brian E Boothe

thats the huge Difference thats i've always Argued about " that statement" who in there right mind would Throw all there ladder into one HUGE Routine, thats just stupid
SBR is very useful when passing parameters in a PLC. The SLC, however, is a different story. The JSR is good but a JSR without the ability to pass parameters to a subroutine is almost useless.
The JSR in a SLC is good to a certain extent in that it gives conditional execution for subroutines. (You could do this with JMP's and LBL's if the code were all in file 2). So basically, it's only good for program modularization, or when using some jury-rigged parameter passing scheme.

Steve Myres, PE
Automation Solutions
(480) 813-1145