Ron Beaufort
Lifetime Supporting Member
... a couple of minor points ...
first minor point ...
for the few readers who might still be confused ... the JMP (Jump) would not have solved bikerdude’s “not-scanning-the-SCP-rung” problem ... simply because a JMP cannot jump between ladder files ... specifically, if you put the JMP in Ladder 2, then you CANNOT “jump” out of Ladder 2 and over into Ladder 3 ... now you CAN jump forward to an LBL (Label) in Ladder 2 - or you CAN jump backwards to an LBL in Ladder 2 - but you CANNOT jump OUT OF Ladder 2 and over into another ladder file ...
second minor point ...
when bikerdude said:
he was technically correct ... but that word “previous” could be setting him up for some potential problems down the road. What he said was absolutely correct IN THIS PARTICULAR CASE because he wanted to tell the processor to go scan Ladder 3 - and the JSR needed to go in Ladder 2 - that is, in the “previous” file. No problem so far. But where the potential problem MIGHT arise is if he keeps the same “put-the-JSR-in-the-PREVIOUS-file" pattern and goes too far with it. Take a look at the “nested” subroutine pattern at the bottom of this picture ...
[attachment]
With the SLC-5/04 that bikerdude is using, the limit on “nested” jumps is eight times. (Note: Different processors have different limitations - check the online help for JSR’s to see how your specific processor handles this.) Now if bikerdude were to keep on stringing his files together by programming “this file’s JSR jumps to the next file” ... and then “this file’s JSR jumps to the next file” ... and then “this file’s JSR jumps to the next file” ... and so on - then something bad is going to happen when the processor tries to make the ninth jump ... the processor faults and shuts down everything it controls ... bummer ... if there are any witnesses around, bikerdude’s professional image might become slightly tarnished by this obvious programming flaw. And yes, this is a fairly common programming error that even experienced programmers can occasionally get into trouble with.
I think that rogerhollingsworth had this effect in mind when he said:
This is the way that most professionally written programs are structured and it’s diagrammed at the top of the figure above. Most programmers name Ladder File 2 as “master” or “main” or “sequencer” or “linker” or “index” or something along those lines. This ladder file generally contains little or no ladder logic. Instead it contains numerous JSR rungs which tell the processor to go scan the other ladder files. Just like chapters in a book, Ladder File 3 might contain logic to control the “grinder” ... Ladder File 4 might contain logic to control the “conveyor” ... Ladder File 5 might contain logic to control the “wrapper” ... etc. ... etc. This structure has obvious advantages to the maintenance crew who won’t have to scroll up and down past the “grinder” logic while they’re troubleshooting the “conveyor” system.
Another thought: does bikerdude really and truly need to execute that SCP to update his tank temperature reading every single time that the processor makes a scan? Probably not - since the tank’s temperature can’t change all that rapidly. So maybe he could (notice I’m not saying that he SHOULD - just that he COULD) make the JSR rung conditional and “jump” over into Ladder File 3 every half second or so. This type of structure can be used to great advantage in lengthy programs where an excessive processor scan time becomes an issue.
For those who might not have gotten a full dose of “subroutines” yet, the figure above contains a handy “tester” rung. Just insert one of these into each subroutine ladder file and run your own experiments on how the processor scans a sample “subroutine” program. This is quite similar to plugging a table fan into a wall receptacle to “see if we’ve got power”. If the fan is turning then the power is on ... likewise, if the accumulator is changing, then the processor is scanning this rung. (Note: be SURE to use a different timer address for each “tester” that you program - otherwise you could get false indications.)
Want even more knowledge along these same lines? Research and experiment with passing “input” and “return” parameters between your subroutines. I wouldn’t recommend spending too much time on this particular feature since it isn’t used very often. Still it’s nice to know that it exists just because it’s extremely handy for those rare instances when you really need it. Also research and experiment with STI (Selectable Timed Interrupt) files. For you PLC-5 people, also research and experiment with MCP (Main Control Program) files - the SLC doesn’t support these but they are used occasionally in PLC-5 programs.
And if you STILL want more, just ask. There’s a lot of juice still left in this “program scan control” lemon.
first minor point ...
for the few readers who might still be confused ... the JMP (Jump) would not have solved bikerdude’s “not-scanning-the-SCP-rung” problem ... simply because a JMP cannot jump between ladder files ... specifically, if you put the JMP in Ladder 2, then you CANNOT “jump” out of Ladder 2 and over into Ladder 3 ... now you CAN jump forward to an LBL (Label) in Ladder 2 - or you CAN jump backwards to an LBL in Ladder 2 - but you CANNOT jump OUT OF Ladder 2 and over into another ladder file ...
second minor point ...
when bikerdude said:
he was technically correct ... but that word “previous” could be setting him up for some potential problems down the road. What he said was absolutely correct IN THIS PARTICULAR CASE because he wanted to tell the processor to go scan Ladder 3 - and the JSR needed to go in Ladder 2 - that is, in the “previous” file. No problem so far. But where the potential problem MIGHT arise is if he keeps the same “put-the-JSR-in-the-PREVIOUS-file" pattern and goes too far with it. Take a look at the “nested” subroutine pattern at the bottom of this picture ...
[attachment]
With the SLC-5/04 that bikerdude is using, the limit on “nested” jumps is eight times. (Note: Different processors have different limitations - check the online help for JSR’s to see how your specific processor handles this.) Now if bikerdude were to keep on stringing his files together by programming “this file’s JSR jumps to the next file” ... and then “this file’s JSR jumps to the next file” ... and then “this file’s JSR jumps to the next file” ... and so on - then something bad is going to happen when the processor tries to make the ninth jump ... the processor faults and shuts down everything it controls ... bummer ... if there are any witnesses around, bikerdude’s professional image might become slightly tarnished by this obvious programming flaw. And yes, this is a fairly common programming error that even experienced programmers can occasionally get into trouble with.
I think that rogerhollingsworth had this effect in mind when he said:
This is the way that most professionally written programs are structured and it’s diagrammed at the top of the figure above. Most programmers name Ladder File 2 as “master” or “main” or “sequencer” or “linker” or “index” or something along those lines. This ladder file generally contains little or no ladder logic. Instead it contains numerous JSR rungs which tell the processor to go scan the other ladder files. Just like chapters in a book, Ladder File 3 might contain logic to control the “grinder” ... Ladder File 4 might contain logic to control the “conveyor” ... Ladder File 5 might contain logic to control the “wrapper” ... etc. ... etc. This structure has obvious advantages to the maintenance crew who won’t have to scroll up and down past the “grinder” logic while they’re troubleshooting the “conveyor” system.
Another thought: does bikerdude really and truly need to execute that SCP to update his tank temperature reading every single time that the processor makes a scan? Probably not - since the tank’s temperature can’t change all that rapidly. So maybe he could (notice I’m not saying that he SHOULD - just that he COULD) make the JSR rung conditional and “jump” over into Ladder File 3 every half second or so. This type of structure can be used to great advantage in lengthy programs where an excessive processor scan time becomes an issue.
For those who might not have gotten a full dose of “subroutines” yet, the figure above contains a handy “tester” rung. Just insert one of these into each subroutine ladder file and run your own experiments on how the processor scans a sample “subroutine” program. This is quite similar to plugging a table fan into a wall receptacle to “see if we’ve got power”. If the fan is turning then the power is on ... likewise, if the accumulator is changing, then the processor is scanning this rung. (Note: be SURE to use a different timer address for each “tester” that you program - otherwise you could get false indications.)
Want even more knowledge along these same lines? Research and experiment with passing “input” and “return” parameters between your subroutines. I wouldn’t recommend spending too much time on this particular feature since it isn’t used very often. Still it’s nice to know that it exists just because it’s extremely handy for those rare instances when you really need it. Also research and experiment with STI (Selectable Timed Interrupt) files. For you PLC-5 people, also research and experiment with MCP (Main Control Program) files - the SLC doesn’t support these but they are used occasionally in PLC-5 programs.
And if you STILL want more, just ask. There’s a lot of juice still left in this “program scan control” lemon.
Last edited:
