JSR in RSLogix5000

gbradley

Lifetime Supporting Member
Join Date
Apr 2002
Location
Corona, Ca.
Posts
1,637
I am familiar with JSR in RSLogix 500
I am learning RSLogix5000 with CompactLogix controller 1769-L30ERM

In RSLogix 500 I usually add a file called Overhead that is always called with an unconditional JSR.
I want to do the same thing with RSLogix5000.
I am not sure what to do with the Input Par, and Return Par
Any advice on what to put there?
Examples?
I have the Mini edition of RSLogix, so most of the samples in the program folder I cannot open.
The ones that were there did not use JSR as far as I can tell.

RS5000JSR.PNG
 
for most versions you can just right-click on the parameters and "Remove" them ... or just keep hitting Enter until they go away ...

RSLogix500 couldn't "pass parameters" at all ... RSLogix5 and RSLogix5000 can pass parameters - but you don't HAVE to use them if all you want to do is tell the processor to "go scan a subroutine" ...
 
Last edited:
for most versions you can just right-click on the parameters and "Remove" them ... or just keep hitting Enter until they go away ...

RSLogix500 couldn't "pass parameters" at all ... RSLogix5 and RSLogix5000 can pass parameters - but you don't HAVE to use them if all you want to do is tell the processor to "go scan a subroutine" ...
Thanks Ron,
I will try that in the morning.
Earlier today, I didn't know what to put in, so I entered some b9 bits, and faulted the controller.:rolleyes:
It's all better now.
 
What Parameters would you pass from one routine to another?

here's a simple "textbook" example:

suppose that you have quite a few Fahrenheit values to convert to the equivalent Centigrade values ...

suppose that you write a subroutine to do the math conversions ...

then you could use a series of JSR (Jump To Subroutine) instructions to "call" the subroutine ...

the first JSR would have an Input Parameter set up for the first Fahrenheit value – which gets passed into an SBR (Subroutine) instruction at the top of the conversion routine ... the routine does the math conversion – and then uses an RET (Return) instruction to pass the results back to the main routine as the first Centigrade value ...

then you could use another JSR to "call" the subroutine again ... this time the JSR has an Input Parameter set up for the second Fahrenheit value – which gets passed into the SBR ... the routine does the math conversion – and then the RET instruction passes the results back to the main routine as the second Centigrade value ...

and so on ...

the idea is to "reuse" the same conversion math over and over – by just feeding different parameter values into – and out of – the subroutine ...

in most cases, we only use a JSR to "call" a subroutine in order to make the processor scan (execute) the subroutine's logic ... but "passing parameters" is available when using RSLogix5 and RSLogix5000 ... on the other hand, RSLogix500 does NOT have the capability to pass parameters ...

 
Last edited:
Ron,
Maybe a little off topic, but you don't have to use a RET instruction when you use a JMP to a subroutine do you? The processor knows to go back to the main routine and go the next line right? I have never done that with any of the 500 projects I have done in the past. Just want to make sure I am thinking correctly.
 
you are correct ... the PLC processor's scan will automatically "return" after a subroutine - even without using an RET (Return) instruction ...

even so, sometimes the RET (even without parameters) comes in handy to "leave" or "exit" a subroutine part way through - before reaching the very end ...

and note that the JMP that you mentioned is incorrect ... the JMP (Jump To Label) can only jump to an LBL (Label) located within the SAME routine (file) ...

specifically, you need a JSR (Jump To Subroutine) instruction to make a jump from one file to another file ... a JMP (Jump To Label) can't go that far ...
 
Last edited:
Thankyou Ron,
Thanks for the explanation of why you might want to enter parameters.
It's all good now.

CleanJSR.PNG
 
Interestingly...

In RSLogix5000, when using a JSR, the SBR instruction is only required when passing parameters.
An unparameterized JSR only requires the subroutine number to jump to it. Using an SBR in the subroutine here is optional.

In RSLogix500, when using a JSR, as you cannot pass parameters, there is no need at all for the SBR instruction to call subroutines, again it's optional.
They do recommend you use the SBR when using a JSR, but it's not essential for it to work.

So why did they include the SBR instruction in RSLogix500?

My guess is, as it was necessary for parameter passing in RSLogix5, they just naturally included it in its successor, albeit without the parameter passing feature.

But why did a useful feature, the JSR/SBR/RET parameter passing, skip the RSLogix500 based controllers?

G.
 


here's a simple "textbook" example:

suppose that you have quite a few Fahrenheit values to convert to the equivalent Centigrade values ...

suppose that you write a subroutine to do the math conversions ...

then you could use a series of JSR (Jump To Subroutine) instructions to "call" the subroutine ...

the first JSR would have an Input Parameter set up for the first Fahrenheit value – which gets passed into an SBR (Subroutine) instruction at the top of the conversion routine ... the routine does the math conversion – and then uses an RET (Return) instruction to pass the results back to the main routine as the first Centigrade value ...

then you could use another JSR to "call" the subroutine again ... this time the JSR has an Input Parameter set up for the second Fahrenheit value – which gets passed into the SBR ... the routine does the math conversion – and then the RET instruction passes the results back to the main routine as the second Centigrade value ...

and so on ...

the idea is to "reuse" the same conversion math over and over – by just feeding different parameter values into – and out of – the subroutine ...

in most cases, we only use a JSR to "call" a subroutine in order to make the processor scan (execute) the subroutine's logic ... but "passing parameters" is available when using RSLogix5 and RSLogix5000 ... on the other hand, RSLogix500 does NOT have the capability to pass parameters ...


This sounds like a very primitive version of add-on instructions. In RS5000 would there be any reason to do this in lieu of an AOI? Other than the fact you can edit a subroutine online and not an AOI.
 
SBR and RET in Logix5000

A few more thoughts about SBR and JSR....

The discussion has gotten us to the concept that the SBR instruction is optional when a subroutine file is not passed any parameters, and the RET instruction is optional when the subroutine does not have to pass back parameters to the calling code.

RA say you should use them, as "...it helps to identify the {sub}routine file as a subroutine...".

Well, all I can say to that argument is that ALL routines are subroutine files*, unless they are configured as the "Main Routine", or configured as the "Fault Routine". These two routine types are clearly annotated in the Controller Organiser. The software lists them under the program first, then all the other files are listed alphanumerically.

* above denotes that there is an exception to this (isn't there always!!). A routine can be called from elsewhere with the iterative instruction FOR. This is the only case where a routine is not a true "subroutine", called by a JSR.

So let's get back to the optional use of SBR and RET (i.e. when they have no parameters to deal with)....

Q. Do they use up controller memory?
A. Yes
Q. Do they use up controller processing time?
A. Yes
Q. What do they do?
A. Nothing

So they occupy memory space, slow the code execution down, and do nothing ?? Why use them then?.....

OK, so that's my soap-box speech dealt with, here's another thought about the SBR instruction (when we use it) .....

It must be the first instruction on the first rung of the subroutine, that's a given. But it has absolutely nothing to do with the application code, it's classified as a "Program Control Instruction".

So now we have a little problem. If we put SBR where it must be, what do we put on the rest of the rung? If we start to put application logic, we have mixed Program Control Instructions and application instructions on the same rung, and that's not a good idea.

If we subsequently have to modify the application code by inserting new logic in front of what we already have, then we have to "break" this rung, and the editing process is much harder.

So we'd like to just put SBR on the first rung of the subroutine, and nothing else, but we can't, because a rung has to have an "output" type instruction.

Many people put a "dummy bit" OTE at the end of the rung, just to satisfy the compiler, but there's an instruction that we can put there, that occupies less memory, and is executed faster. It's called NOP {No Operation), and is classified as both an "Input" (conditional) instruction, and an "Output" (non-conditional) instruction, and it allows us to "finish" a rung without having the overhead of a database access.

I would recommend that when you are using SBR's, that you put them on a rung to themselves, with a NOP as the output on that rung. Doing so will isolate the program control instruction from the application code.
 

Similar Topics

Hi, I am dealing with a single SBR subroutine thats handed 1 input paramter UDT P.x multiple times: (Pump) P.1/2/3/4/5. I JSR into the same...
Replies
3
Views
1,975
I have: 1734-AENTR processor RSLogix5000 version 20 I am working with a JSR and it is behaving in a way I did not expect and I am unable to...
Replies
3
Views
2,420
Jsr
We have a motor control JSR with Input and Output parameters, There are 36 motors that are controlled by the same JSR. What or how can I view...
Replies
8
Views
500
I intend to pass a BOOL array to an ST routine (for loop) to count the true bits. (should never have used a Bool array, lesson learned) The ST...
Replies
10
Views
823
Currently, I have a 1769-L36ERM that is being using to control a machine with 15 servos. Due to the nature of the process, the code is very...
Replies
9
Views
1,516
Back
Top Bottom