Pausing a sub routine

Currently I am using a bunch of TON's and TOF's to start up and turn off a motor sequence. I created a sub routine for the manual sequence and I was wonder if I put a selector switch if front of the routine it would definitely skip that sub routine scan, but it the timers were already activated how would I be able to pause their sequence.

i think what your trying to do is have your timers retain their accumulated values when the subroutine is not called. I don't know what programming software you are using, but look into using retentive timers that way whatever is accumulated will retain its value when the rung enabling the timer goes false.

That is exactly what I plan on doing, Thanks I'll try that, I also thought that retentive timers will only work as a TON, Is this correct? I am using RS logix 500 on a PLC 5

I assume it is a typo as RSLogix 500 does not work on PLC5's you need RSLogix5 for PLC5's.

yes it is a typo. It is RsLogix 5

Nab23 said:

Snip....
I also thought that retentive timers will only work as a TON, Is this correct? I am using RS logix 500 on a PLC 5

Click to expand...

With proper logic you can use TON timers to accomplish a TOF function.

Yes but I have already worked in mid cycle starts and stops, and it would be a hassle to replace all the TOF's with TON's

Are you asking about using a separate subroutine to control the actual outputs? Or just conditional internal control subroutines?

The thing you get into when doing this, is handling transitions between modes. It is simpler to have a mode selected bit as a simple XIC instruction, always scan both modes subroutines, if you want manual controls not to work in the existing auto mode, then XIO auto mode and please avoid controlling real outputs this way, with multiple OTE instructions in selected subroutines.

Your OTEs will not turn off any bits when the JSR goes false, now what? As long as you cover all transitions of all modes necessary with extra logic, it will function, but is not as flexible nor simple as keeping it all scanned, and just pasting one tiny bit instruction to a number of rungs.

Every time i study a TOF, I lose three to thirty seconds wrapping my head around the fact that the DN bit is inverted from normality, so I too prefer TONs, but there are cases where a TOF is either very simple, likely in your case, or on rare occasions make a much less ugly rung, so I have nothing against the TOF.

The retentive timer is RTO, and it is an on delay type of timer instruction, the DN bit is off until the preset number of seconds has elapsed, and you must reset it with the RES instruction, since just making the rung go false causes it to pause with the present accumulated value, and when the rung goes true, it continues to accrue time in the .acc register. So to replace the TOF with RTO, you will need to examine the input conditions, invert any usage of the DN bits in the code and add a RES (reset) rung or branch. You want to make sure you are done processing the DN bit before you execute the RES. For me, I put the RES always immediately preceding the RTO instruction, keep the DN bit alive for a full scan by default as a standard programming practice.

If you want to pause the TOF, make the "EN" bit of the Timer high and leave all the rest of your logic as is. (this also works for TON's by making the "EN" low)

OkiePC said:

Are you asking about using a separate subroutine to control the actual outputs? Or just conditional internal control subroutines?

The thing you get into when doing this, is handling transitions between modes. It is simpler to have a mode selected bit as a simple XIC instruction, always scan both modes subroutines, if you want manual controls not to work in the existing auto mode, then XIO auto mode and please avoid controlling real outputs this way, with multiple OTE instructions in selected subroutines.

Your OTEs will not turn off any bits when the JSR goes false, now what? As long as you cover all transitions of all modes necessary with extra logic, it will function, but is not as flexible nor simple as keeping it all scanned, and just pasting one tiny bit instruction to a number of rungs.

Click to expand...

+ 1 for keeping the sub routine on scan... You will cause someone confusion down the track when the outputs aren't following the inputs...

kiwi sparky said:

If you want to pause the TOF, make the "EN" bit of the Timer high and leave all the rest of your logic as is. (this also works for TON's by making the "EN" low)

Click to expand...

This is NOT how TONs and TOFs work....

If you make the EN of a TOF true, then the TOF resets. The accumulator is cleared to zero, and the TT bit is cleared. This is clearly not "pausing" the TOF

If you make the EN of a TON false, then the TON resets. The accumulator is cleared to zero, and the TT bit is cleared. This is clearly not "pausing" the TON


Put simply, there is NO WAY to PAUSE a TON or a TOF, because they aren't physical timers. A detailed explanation of that statement is available if requested.

daba see attachments for what I meant. Maybe this doesn't work with PLC5 like the OP has? I use this logic often and it works. I don't like using RTO's in my logic because of having to manage when to reset timers

kiwi sparky said:

daba see attachments for what I meant. Maybe this doesn't work with PLC5 like the OP has? I use this logic often and it works. I don't like using RTO's in my logic because of having to manage when to reset timers

Click to expand...

It may (or may not) 'work' but it certainly isn't clear as to the intent of that code. Why not do the same thing (pause) with the same number of rungs (two) using an RTO and RES, which is much more clearer? I don't understand the difficulty of managing a RES when you're having to 'manage' the .EN bit of the timer?

I prefer when the rung conditions before a timer go false that the timer acc automatically resets.
Hopefully this has given the OP some options. I agree with others, always keep the subroutine on scan

kiwi sparky said:

daba see attachments for what I meant. Maybe this doesn't work with PLC5 like the OP has? I use this logic often and it works. I don't like using RTO's in my logic because of having to manage when to reset timers

Click to expand...

Ok, I've learnt something new. Yes it does work, by taking advantage of the highlighted path on the enclosed flowchart of how the TON works, especially the green highlighted part, where it keeps the internal reference time updated. Without that, it would not restart from where it was paused.

The only thing I'm not too happy about is that the .TT bit remains set while it is paused, which is not in keeping with the way a RTO clears the .TT bit when it is "paused". That .TT bit will be the only thing you can pick up on that the timer is actually accumulating time, so I think it right that it shouldn't remain set while the timer is paused. Relatively easy to unlatch that bit as well as the .EN when you want to pause it.

If I were to use this method, I would do it all on one rung, so that there is considerably less chance of the pausing logic getting separated from the timer, or even deleted, by mistake !!