while you do not have to do a return on a jsr,
I always include this statement because I believe the program executes faster and more efficiently.
that's just me.
james
Opposite to that, James
The "END" rung of a subroutine file executes exactly the same as a RET instruction, simply returning code scanning to where it got left. So, having that extra rung with the RET instruction is just using memory that doesn't need to be used.
Usage of SBR and RET varies by family, so here's a summary of the JSR, SBR, and RET instructions.
1. PLC5
JSR always required, and could pass input and/or retrieve return parameters.
SBR optional, unless input parameters were declared in the JSR, then required.
RET optional, unless return parameters were declared in the JSR, then required.
2. SLC
JSR always required, no parameter passing allowed.
SBR optional, so why use it if no parameters can be passed.
RET optional, so why use it if no parameters can be passed.
3. Logix5000
JSR always required, and could pass input and/or retrieve return parameters.
SBR optional, unless input parameters were declared in the JSR, then required.
RET optional, unless return parameters were declared in the JSR, then required.
In all cases SBR and RET are "optional", and, according to RA documentation "serve to mark the start and end of a subroutine file". Doesn't rung 0 of an actual subroutine file define its "start", and the last rung define its "end". Yes, you can have files that are NOT "subroutine" files, e.g. STI, DII, or Fault files, and you would typically NOT use SBR and RET instructions in those, but on the same hand you would NAME those files accordingly, so you knew what they were there for.
In any family, I would only use SBR and RET if parameter passing was taking place - SBR to unpack the parameters, and RET to pack them for the JSR to retrieve. I certainly would not include them just because you can, it takes up memory, and slows scan time.