SLC Timer (TON) details?

[Ken Moore]

Consider a self resetting one second timer.

[Ken Moore]

At a glance we would think that the done bit is set once every one second. We could then use this done bit to trigger events on a one second time base.
However, I don't think this is true, here is what I think happens.
PLC scan: accum is less than preset, nothing happens
PLC scan: accum equals preset, done bit set
PLC scan: since done bit is true, TON is reset

So....
In fact it is not a one second timer it is a one second plus one scan timer, or does it take two scans to reset?

I guess I lead a dull life, sitting around on Saturday thinking about timers?
Hopefully Ron Beaufort can straighten me out.
That's a compliment to Ron, he explains the AB plc details better than anyone I've ever encountered.


Ken

[Steve Bailey]

Ken,

I'm not an expert on the details of AB's timers, but that's my understanding of how they work.

That's also the way that GE Fanuc timers work, which I have verified. In GE Fanuc, if you wanted a timer that pulsed every second, you could do something like this:

 Always        _____    Done

--] [---------| TMR |---( )-

              |HUND |

              |     |

              |_____|



  Done         _____

--] [---------| SUB |

              |     |

          ACC-|     |

              |     |- ACC

          100-|     |

              |_____|

This approach has the added advantage of not losing the 'sub-increments' in the accumulated value.

Think about how the timer works 'backstage'. Every scan that the timer is enabled it has to add the amount of time since the last update to the accumulated value. For maximum accuracy, the timer has to keep track of time in smaller increments than it displays. The GE Fanuc timer does this in the first twelve bits of the third register assigned to the timer. It adds the elapsed time since the last update to this value. Then it divides the updated value by the timer increment (tenths of a second, hundredths or thousandths), adds the quotient to the ACC value and stores the remainder back in the twelve bits.

The act of resetting the timer not only loses the time for the scan while the timer is reset; it also clears out that remainder from the twelve bits. The method I presented retains that remainder.

[Rube]

"Consider a self resetting one second timer."

Okay, I did. (But only for a second...wait! I'm considering it again).

I would venture a guess that with most scan times being what they are, the timer would go done and the current scan would see that immediately, not on the next scan. Anyone with scan times longer than one second, (or 1/2 sec), probably has other concerns to worry about.

[Gerry]

Originally posted by Ken Moore

So....
In fact it is not a one second timer it is a one second plus one scan timer, or does it take two scans to reset?

It takes one scan.

Note that if the program scan time is longer than the 10 msec. time-base, you will occasionally see the accumulator go past the 100 preset, adding to the inaccuracy of the desired one second.

[93lt1]

Check out this thread for an in-depth discussion of the ins-and-outs of AB timers.

[Jordan.C.Clark]

I would think that, unless you needed extra-hi precision, the extra scan is not going to noticably affect the application.

Anyway, here's what happenns:

TON Instruction is executed
compares Accumulated value to Preset value
if T4:0.ACC => T4:0.PRE then Done bit is Immediately turned on.
otherwise it moves on

The done bit will stay on until the SLC sees that the TON instruction is false.
Reset Enable Bit (T4:0/EN)
Set Accumulated Value to 0 (T4:0.ACC)
Reset Done Bit (T4:0/DN)

I've worked with several different platforms and so far they've all worked the same way. Tomorrow, I'll see the one that gets me!

Hope it helps!

Regards,

Jordan

[Ken Moore]

Thanks for the replies.
I have a couple of older machines with >100 ms scan times, and it explains a few things.

Ken

[Ron Beaufort]

Greetings Ken,

first of all, thank you for the kind compliment ... it looks like you’ve already gotten all of the help that you needed ... I’m afraid that there’s not much that I can add to what’s already been posted ...

but here’s something that you might be interested in ... the next time you’re “sitting around on Saturday thinking about timers” why not try running something like this through a spare system? ...

[attachment]

the basic idea is that with a little bit of imagination you can set up your own little “super histogram” that will faithfully record the TON’s status “rung-by-rung” ... this is the type of kung-fu that I use whenever I need to go “beyond the books” to answer a question like yours ...

of course this screen shot only shows the basic idea ... I’ll attach the actual .RSS file to another post just in case you’re interested enough to take a look at it ...

now on to the next post for a sample of the type of data that this thing can collect for you ...

[Ron Beaufort]

basic idea: just before the TON gets executed, we jump into a subroutine ... that subroutine stores:

(a) the current value from the timer’s accumulator BEFORE the TON instruction gets scanned ... and

(b) the current condition of the timer’s status bits (etc.) BEFORE the TON instruction gets scanned ...

once we’ve run through the subroutine, we come back to our original ladder and execute the TON instruction ...

and then just after the TON gets executed, we jump into another subroutine ... that subroutine stores:

(a) the current value from the timer’s accumulator AFTER the TON instruction gets scanned ... and

(b) the current condition of the timer’s status bits (etc.) AFTER the TON instruction gets scanned ...

think about it ... now we can have a series of scan-by-scan snapshots to show us exactly what was going on inside the timer both BEFORE and AFTER it gets executed ... this is the type of technique that can take you WAY BEYOND what the “books” can teach you about the nuts-and-bolts of how the PLC instructions and scan sequences operate ...

[attachment]

here’s a quick rundown of what this data is showing us ... I’m skipping over some details but you’ll be able to figure out what I’m leaving out once you’ve looked at the .RSS program file ...

here’s scan #13 ...........................

A. on scan #13 BEFORE the TON gets executed, the timer’s accumulator contains the value “99” ...

B. on scan #13 BEFORE the TON gets executed, the timer’s done bit (bit 13) is off (=0) ...

C. on scan #13 AFTER the TON gets executed, the timer’s accumulator contains the value “100” ...

D. on scan #13 AFTER the TON gets executed, the timer’s done bit is on (=1) ...

here’s scan #14 ...........................

E. on scan #14 BEFORE the TON gets executed, the timer’s accumulator contains the value “100” ...

F. on scan #14 BEFORE the TON gets executed, the timer’s done bit (bit 13) is on (=1) ...

G. on scan #14 AFTER the TON gets executed, the timer’s accumulator contains the value “0” ...

H. on scan #14 AFTER the TON gets executed, the timer’s done bit is off (=0) ...

that should give you a good idea of what kind of detail this technique will provide ... and if you want to go deeper and explore the inner workings of exactly how the timer “keeps time”, then take a look at those “extra” bits that are being recorded in files N10 and N12 ... you can find the details of what’s going on there by reading that “overkill” thread that Allen Nelson (and others) and I worked on some time ago ... 93lt1 provided a link to it just a few posts back ...

now on to the next post for the .RSS program ...

[Ron Beaufort]

and here is the program just in case you want to take a look at it ... I think that I’ve added enough documentation to make it understandable ... warning! ... the way it’s presently written it will fault the processor when the indirect addressing runs out of data storage room ... I never worry about “fixing” stuff like that when I’m just experimenting in the lab ... I just let it go ahead and fault ... the data that I’m looking for will still be right there where I’ve recorded it ...

I hope that this helps ...

[Ken Moore]

Thanks Ron,
Another outstanding job.
I've download your file and will play around with it later. I have a ML1000 and a SLC 504 test system I can run it on.

I now see how you discovered so many of the little details. This technique has a lot of potential "learning" applications.




Ken

[mordred]

no kidding I've been studying it between breakdowns most of today. Very informative.

[jstolaruk]

Wouldn't a rung following the timer rung with a compare of the timers accumulator to 100 and a clr timer output eliminate the extra scan?

[Ron Beaufort]

Greetings jstolaruk,

you asked:

Wouldn't a rung following the timer rung with a compare of the timers accumulator to 100 and a clr timer output eliminate the extra scan?

if I understand exactly what you're asking, the answer is "yes, that would eliminate the EXTRA scan" ...

but you've got to ask yourself: "why are we building this 'pulsing-timer-thingy' in the first place?" ...

the answer is (usually) that we're going to make use of the Done bit to "trigger" something (downstream in our program) into execution ... and so if we were to "reset" the timer IMMEDIATELY (even before we complete a scan) then the Done bit would not be available for our "triggering" purposes ...

going deeper ... in your question you suggested using a "compare of the timer's accumulator" to initiate a “reset/clear” operation for the timer ... actually you wouldn't really need the "compare" ... instead, a simple XIC for the timer's Done bit would be just as effective - and a lot more efficient ... to nail that idea down, look at the data for scan #13 in one of my posts above ...

C. on scan #13 AFTER the TON gets executed, the timer’s accumulator contains the value “100” ...

D. on scan #13 AFTER the TON gets executed, the timer’s done bit is on (=1) ...

basic idea: as soon as the timer's accumulator reaches its preset value of "100", the Done bit comes on simultaneously (on the same scan) ... so even though comparing the accumulator to the preset would certainly work, simply examining the Done bit for an “on” condition would be a much more “elegant” programming approach ...

always remember: there is “programming” ... and then there is “ART” ...