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.