RSL 5k subroutines

I was reading some "tips and tricks" about RSL 5k. One of them said " If you want a subroutine to run every scan, copy the first instruction and paste it right next to the original, tag them both the same then put an AFI in front of the copy. Huh?
First question in my mind is do subroutines not run every scan?

Routines run when they are called.

Generally every program has a Main Routine, which runs every time the Program is executed. In turn, the Programs are triggered by the Continuous, Periodic, or Event Tasks.

"Subroutines" are any Routines that are not the Main Routine in a Program. They are only called by JSR instructions.

I'd have to see where that "tip" came from to suggest what it is trying to say; there's no exotic syntax about similar rungs that is used to execute a Routine.

this is just a GUESS – but here's what might be going on ...

One of them said "If you want a subroutine to run every scan, copy the first instruction and paste it right next to the original, tag them both the same then put an AFI in front of the copy.

Click to expand...

let's change the wording a little – to this:

One of them said "If you want an FAL instruction to run every scan, copy the first instruction and paste it right next to the original, tag them both the same then put an AFI in front of the copy.

Click to expand...

here's the trick (IF my guess is correct) ...

certain instructions (such as an FAL) are "transitional" ... in simplest terms, that means that they only execute whenever they see a transition (a change) from FALSE to TRUE ... in other words, if you put the FAL on an unconditional rung, then it will execute ONCE – but ONLY once ... in order to execute/function again, it would have to be scanned as FALSE – and then scanned again as TRUE ...

in normal situations, that would require TWO scans of the instruction – in order to obtain just ONE actual execution ...

I actually had a programmer send me a copy of the FIRST rung (Rung 0) shown below – with the following question:

I found this rung construction in a working program at my plant – and I don't understand it ... apparently the bottom FAL is USELESS – since it will never execute due to the AFI in front of it ... so to "clean things up" I deleted the branch with the bottom FAL and the AFI – leaving only the top FAL ... but then the remaining FAL wouldn't work ... so then I put the branch, the AFI, and the "extra" FAL back in – and everything started working again ... what's going on? ...

Click to expand...

here's the answer:

the top FAL instruction sees TRUE logic coming in – and so it executes normally ... next the bottom FAL sees FALSE logic coming in – due to the AFI instruction ... this FALSE logic acts as a RESET for the CONTROL tag (MUTT) and gets things ready for the processor's next pass through the rung ...

so ...

when you took out the bottom FAL instruction, all that MUTT ever saw was TRUE – TRUE – TRUE on each pass through the rung ... specifically, there was NO "transition" from FALSE to TRUE ... more specifically, there was nothing to "trigger" the remaining FAL into operation again ...

Click to expand...

now look at the second rung (Rung 1) shown in the figure below ... this is more along the lines of what I THINK that you read about in your "tips and tricks" ...

this would give the same "execute the FAL instruction on each scan" operation as the top rung that I've shown ...

frankly I do NOT like this type of construction – but it DOES work – and it's hard to argue with success ... personally I'd use an RES (Reset) instruction for MUTT to get the same "every scan" operation – rather than entering the FAL instruction twice ...

so ...

is there a chance that when you read the "tips and tricks" article, you simply misinterpreted what was written? ... as you pointed out, the statement doesn't really make any sense the way you quoted it – but maybe the terminology/definitions being used weren't precisely correct ...

like I said – this is all just a GUESS ...

can you give us a link (etc.) to where you read your "tips and tricks" article? ... or maybe a screen shot? ...

NOTE: in this discussion I've used the FAL instruction just as one example of a "transitional" type instruction ... there are other instructions which also work this same way ...

and just for completeness – since we started out talking about subroutines ...

in RSLogix5000 systems, a subroutine may be called into operation by using a FOR instruction ... this is in addition to the much more commonly used JSR instruction ...
.

T Gibbs said:

I was reading some "tips and tricks" about RSL 5k. One of them said " If you want a subroutine to run every scan, copy the first instruction and paste it right next to the original, tag them both the same then put an AFI in front of the copy. Huh?
First question in my mind is do subroutines not run every scan?

Click to expand...

The advice is mis-quoted, if Ron is correct.
But, moreover, I take a hint from Mark Cuban (SHARKTANK), who says: "Never take advice from someone who doesn't have to live with the consequences of following it."
The same can be said for responders to questions in this forum. (sometimes)

http://www.plcdev.com/book/export/html/507

Go down under the routines heading and go down about 3/4 of the way.

•If you want a subroutine to execute every scan, copy the first instruction and paste it right next to the original instruction. Use the same tags on the duplicate instruction as on the first instruction. Then insert an AFI instruction before the duplicate.

(copied and pasted)

Based on the context of the sentence it is either a typo or the "suggester" doesn't know what they are talking about. Other than the initial occurrence of the word "subroutine" it doesn't occur at any other point in the sentence. "Instruction" is in the locations you would expect to see "subroutine".

I think Ron is right. It shouldn't say "subroutine". It should say "edge triggered instruction" or something similar.

Keith

I was just "guessing" before - and now that I've read it - I'm STILL just guessing ...

maybe the terminology is just wrong - but the statement doesn't make sense the way it's been written ...

or as someone famous once said: "It all depends on what your definition of is is." ...

Wow, great thinking on this topic, you guys.

I admit that if I encountered that logic without comments explaining precisely how it was supposed to work, I would assume that somebody had abandoned an FAL instruction that they had disabled with an AFI.

I do a lot of brute-force logic that I reinforce with comments saying "this is done in a simple, easy-to-understand, inelegant way on purpose".

Agreed - I'm probably as guilty as anyone of trying to "tidy" redundant code...I would probably have deleted the AFI'd rung without a second thought! Well, until everything came to a grinding halt, and I went "surely not!"

I'm impressed that the connection was made given the highly misleading nature of the statement! Some brilliant minds on here.