Follow up on more-about-timers-than-you-really-wanted-to-know. Apologies in advance but this is the way my mind works.
First, a TON is NOT a “timer” – not really. Now you may call a TON a “timer” – and I may call a TON a “timer” – and people will look at us funny and laugh behind our backs if we call a TON anything other than a “timer”. Still a TON is NOT really a “timer”. A TON is, in reality, an INSTRUCTION to the PLC processor which tells the processor to “service the timer”. In other words, whenever the PLC processor scans a TON instruction (specifically a TON which is enabled), the processor takes certain steps in order to “service the timer”. Look at this experimental program.[attachment]First, let’s enable the timer with the switch and get it running. Then let’s toggle bit B3/0 OFF and watch what happens. Answer: the timer keeps running right on past the Preset value. That’s because the processor has been fooled into thinking that the timer isn’t “done” yet. We fooled the processor by “forcing” the Done bit OFF with rung 0000. Now to be honest, once the Accumulator is “equal-to” or “greater-than” the Preset value, the processor DOES actually turn the Done bit ON each and every time this rung (0001) is scanned. (That’s why it looks green on the screen). But we’re “hijacking” the Done bit in rung 0000 and turning the Done bit right back OFF again – before the processor comes back around to this rung (0001). This is the condition shown in the program screen dump.
Now for the next experiment, let’s reset the timer – and then start it running again – but this time, BEFORE its Accumulator reaches its Preset value, let’s toggle bit B3/0 ON and look what happens. (This situation is not shown in my sample program – but use your imagination). Answer: the timer stops running and “freezes” at its current value. That’s because we’re telling the processor (by way of rung 0000) that the timer is already “done” – so the processor does NOT add time to the timer. It figures the timer doesn’t NEED any more time since it’s already “done”.
So here is my own personal (read that “subject to error”) way of looking at the TON instruction. I’ve left out the Timer Timing bit and a few other minor items for brevity:
When the processor scans a TON which is enabled by true logic, the processor “services” the timer by executing the following steps:
(1) the processor checks to see if the Done bit is ON or OFF.
(2) if the Done bit is ON, then the processor ignores the TON and moves on to the next instruction in its scan.
(3) if the Done bit is OFF, then the processor checks to see how much time needs to be added to the timer’s Accumulator. The processor determines the amount of time to be added by comparing the value stored in the processor’s internal clock with the “note” value stored in the low byte of the timer’s first word. From this comparison, the processor knows how much time to add to the Accumulator. The processor adds this amount to the Accumulator.
(4) the processor now checks to see if the Accumulator is “equal-to” or “greater-than” the timer’s preset value. If either of these two conditions is true, then the processor turns ON the timer’s Done bit. (In case you’re wondering, if the processor checks and finds that the Accumulator is “less-than” the timer’s preset value, it will NOT turn OFF the timer’s Done bit. Come back later and change rung 0000 to use an OSR and an OTL if you want proof of this).
(5) the processor then records a “note” of the value from the processor’s internal clock into the low byte of the first word of the timer. It will need this value when it comes around to scan the rung again (specifically if the timer is NOT done).
(6) the processor has finished “servicing” the timer and moves on to the next instruction in its scan.
Now back to my initial assertion that a TON is NOT really a “timer”. Open the T4 data file and take a look at T4:0. Now THAT, my friends, IS a “timer”. In other words, the actual data structure which contains T4:0 – including its status bits – and its Preset value – and its Accumulated value – all of that structure together IS a “timer”. Keep that in mind and think about the TON. The TON is NOT a “timer” – the TON is an INSTRUCTION which tells the processor to “service the timer which lives back in the data file”. If you accept that – as I have forced myself to accept it – then the following technique makes PERFECT sense. (From my earlier post #10)
If a TON timer is placed in a program which has an excessively long scan time, the timer will keep poor and inconsistent time. But if the SAME timer address is used in several places throughout the scan (in other words, several identical TON's), then the timing action will be greatly improved. I've tried this technique before and found that it will NOT cause the timer to "double-time" or advance too rapidly.
With that in mind, something that Allen said in his post #12 might need clarification.
So there is something that's keeping any timer from being updated more than once in a scan.
Actually we CAN tell the processor to “update” any timer many times within the scan. That is, if your definition for “update” is the same as mine. To me the word “update” means “service the timer and bring it up to date”. We can do “updating” of the timer by programming several identical TON “instructions” to tell the processor “do it again ... do it again ... do it again” all within the same scan. And each time the processor encounters one of these TON’s and “does it again”, he will add JUST THE CORRECT AMOUNT of time to the Accumulator.
I think what Allen meant by his use of the word “update” could be paraphrased as: “So there is something that's keeping any timer from ACCUMULATING TOO MUCH TIME in a scan.” If that is what he meant by the word “update” then I would completely agree with his statement.
Summing up my personal philosophy of timers:
(1) I think of the “timer” as being that 3-word STRUCTURE in the data table file – with the address T4:0 in our example.
(2) I think of the TON as NOT really a “timer” but rather as an INSTRUCTION in the program which tells the processor to “service the timer”.
(3) I understand that if I were to program multiple identical TON’s in my ladder file, then the timer T4:0 would keep excellent time. Specifically, it would not “double-time” or “go too fast”.
Finally (to the beginners in the audience), I have NEVER seen any program which actually NEEDED this “multiple identical TON’s” technique in order for a timer to keep accurate time. I have included the technique here for educational purposes. If you (as a beginner) get the irresistible urge to use it in one of your programs, please post your intentions and give us (as non-beginners) a chance to talk you out of it.