Ton Timer

ICAPALDO

Member
Join Date
Sep 2002
Posts
2
EQUIPMENT: AB 503

WE ARE HAVING PROBLEMS WITH A TIMER TON IN A PLC PROGRAM THAT IT IS SET TO 300 ms(30x0.01) BUT EVERY 2 OR 3 DAYS RESETS ITSSELF TO 4500 (4500x1).WE HAVE CHANHGED THE CPU AND CHECKED FOR NOISE. THE PROBLEM
STILL PERSIST.

DOES ANYBODY HAVE ANY SUGESTIONS?
THANKS
 
If I understand you correctly, both the timer's PRESET and the timer's TIME BASE are both changing for no apparent reason. And they always change to the same values of "1" and "4500". You've changed the processor so that isn't the problem. If you're SURE that noise isn't causing this (not likely since the values aren't random), then your problem must be caused by (a) something external to the processor, or (b) something in your program. Here is a list of things to consider. Is the SLC-5/03 on a DH-485 network with an HMI/SCADA such as RSView32, Wonderware, or the FIX? Is it on a DH-485 network with other processors? Do any of the processors on this network (including yours) use MSG commands? Is anything such as a PanelView, barcode reader, etc. plugged into the RS-232 port on the processor? Would you like to post your RSS program file so that we can take a look at it? Have you replaced the original timer (example: T4:4) with another one (example: T4:9)? If so, did the problem follow the "new" timer? Are you using an EEPROM chip with this system? Is the processor connected to a MODEM for dial-in connections?
 
As what Ron Suspected, it could be caused by an overwrite from external devices or moving/copying the new value to the timer presets from inside your programs upon an event. Do a search for mov or cop, you may grab it. If not the hard work is to sweep through your externer devices such as HMI (Panelview/RSView)
 
I had a simular problem. :( We had a 5/03 running a puch press operation with a stepper motor feed. The values for the stepper configuration were storred in a N file. The maintenance dept had made several changes to the values over time and the EEPROM was never updated. :rolleyes: Each time the power was lost the program reloaded from the EEPROM on power up and the original values were used instead of the new ones. Once the EEPROM was updated I had no further problems. :eek:
 
The time base cannot be overwritten except in a true online edit or program reload.

Rick:

Not true. The time base is stored in the first word of the 3-word block of the timer. The bits (I forget which) that control it are not accessible via standard programming techniques, but CAN be changed on the fly

The instruction COP #T4:0 #N7:0 3 will bring all three timer words into N7:0, :1 and :2.

The instruction COP #N7:0 #T4:0 1 will put the three N7 words back into T4:0. If between the two instructions you were to maniplulate the lower bits in N7:0 (where the time base along with .EN, .TT, and .DN are stored), the time base could be changed.

To find out which bits are which - do the following:
  1. Create a small PLC program with 3 T4 timers, each with a different time base.
  2. SaveAs the program to a library file. Make sure you save the entire file, not a partial.
  3. Open the resulting .SLC (or .PC5) file in notepad. You will see the export of the T4: data table, with .ACC, .PRE and some hex code.
  4. It's not hard to interpret the hex code to figure out which bit pattern stands for each time base.

I use this stuff when I'm doing Autu-gen programs, and I want to set up, for example, all my alarm timers, and I'll import the .SLC which I generate via Excel. I've also done the programming part when I'm synchronizing two timers between two PLCs and transmitting all the data via N files.

CAUTION: Rockwell warns agains changing the time base of timers on the fly.

I happen to agree with that.

Timers are still a mystery to me. I can't figure out how they work.

Don't get me wrong - I can program the hell out of them. But think bout this:
  • If your time base is 1 second, and your scan time is 10 msec, then the TON instruction must wait 100 scans before updating the .ACC. Where is that counting done? Is it in the lower bits of word 0.
  • What happens if the TON is in a subroutine that's only called every other scan - will the TON increment the .ACC after only 50 scans?
  • What about if your scan time is wildly variable (say between 10 and 50 msec) - how does it keep track of how many msec have accumulated before it can add the 1 sec to the .ACC ?

<hr>

Back to the original topic:

It could be the eeprom.
It could be a SCADA problem. To change the time base, the SCADA would have to have the T file configured as an N, or more likely an F. (That is, some SCADA tag configured for F4:0. That would write 2 words to data table 4, element 0. Those 2 words would be the time base and the .PRE (the .ACC is the third word of the T file block)
It could also be a programming problem. For example. If the S:2/3 bit is set ("Index across data files") and if B3 is sized at 10 words, and S:24 ("Index Register") has a value of 12 (e.g, two words past the limit) when the instruction MOV 4500 #B3:0 executes, it will move 4500 into T4:0.PRE !

(I first learned of this from a programmer who put an almost untracable "time bomb" in the code to ensure payment. This was the method he used (although he set up a negative timer to fault the PLC). I disapproved of the "time bomb", but I hung onto the technique.

But you can see why something like this would not be findable using normal debug techniques. T4:0.PRE is not refereence. There is no indirect addressing to T4 anything. Data just seems to get there by "magic".

Good luck.
 
Last edited:
So how about posting that program so we can all take a look at it? That could find the problem - or at least eliminate several of the trees that we're barking up.
 
Timers and book keeping

Rick,
You have raised an interesting point. How is the timing really done inside the PLC.
I had a look at Micrologix' guts and found that it uses Dallas
Semiconductor DS80C320-MCG screaming chip.
As I am familiar with 8051 architecture and assembly programming,
here is my opinion on how timers are implemented within the
8051 chip. 8051 chips and derivatives have 2 to 4 internal
timers/counters. These run asynchronously with the normal
program. You start them and when they overflow you can
trigger an interrupt routine. What is most probably happening is that
one of these timers is set to overflow at 10 ms. Each time that happens an interrupt routine will update a tick counter for each
ladder timer. The timer itself will only get updated when it is
scanned in the ladder. Since the real time tick count is updated
asynchronously to the ladder, when you scan the timer instruction
in the ladder, you will see the correct time appear in the .ACC
field. It's not going to make a difference if the ladder scan time
varies wildly.
 
My best guess - for what it's worth.

When the processor scans a TON which is enabled, the processor checks to see if the timer's Done bit is on. If the Done bit is on, then the processor takes no further action with the timer and moves on to the next instruction in its scan. If the Done bit is not on, then the processor adds "the appropriate amount of time" to the TON's accumulator. Then the processor checks to see if the TON's accumulator is "greater-than or equal-to" the TON's preset. If either of these conditions are true, then the processor sets the Done bit to "1" and then moves on through the scan. Now the question is: how does the processor know what to add for that "appropriate amount of time"? My best guess: each time the processor scans the (enabled) TON, the processor records a "note" in the lower byte of the first word in the timer's three word structure. In other words, the processor uses these "extra" eight bits to keep track of "how long has it been since I checked this TON the last time?"

I wouldn't bet the rent on any of this, but I think that it is correct based on some experiments I conducted several years ago. One is quite simple: just put this rung below an enabled TON (T4:0 in this example) and watch the accumulator go higher and higher.
               T4:0/DN
----------------(U)--


Plus, although I haven't been able to find it lately, I distinctly remember reading something along the following lines in an Allen-Bradley book: 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.

I ran across an interesting note in the following manual:

http://www.ab.com/manuals/cp/1785654.pdf

Look on Adobe Reader page 106 of 161 - or on the book's page 7-9. This goes along perfectly with what Allen said in his post above. Someday, if I ever get the chance, I intend to play around with the "bit recovery" techniques which Allen brought up. This is BOUND to come in useful someday.
 
Last edited:
Re: Timers and book keeping

Jiri Toman said:
The timer itself will only get updated when it is
scanned in the ladder. Since the real time tick count is updated
asynchronously to the ladder, when you scan the timer instruction
in the ladder, you will see the correct time appear in the .ACC
field. It's not going to make a difference if the ladder scan time
varies wildly.

But that's my point. In a 1 sec TON time-base, where does that "Updated" time go? I'm guessing the first 7 bits of the T-word. But that would only allow a count of 255 msec = 0.255 sec. Unless a 10 msec base is used there, which might be enough.

But I'm not convinced it's stored there, nor if that's how a TON operates. My real, basic question is "How does the TON know how much time has elapsed since it was last scanned, and where does it store it?"

Your description of only 2 "real" timers in the SLC chip is even more confusing. Remember that there can be hundreds of TONs programmed, all running simultaneously, each incrementing their own private .ACC?

And what about indirectly addressing timers - does that work.

The SLC can't indirectly address timers, you say (the PLC-5 can, BTW)?
What about this code:

COP #T24:[N7:0] #T4:0 1 - Get all the elements of an indirectly addressed timer into T4:0

TON T4:0

COP #T4:0 #T24:[N7:0] 1 - Put all the elements back.

Will this keep track of time accurately? What happens if you put this in a for-next loop, so that the TON is scanned 20 times in a single PLC scan? Will it increment by the last scan time? -by the elapsed time since it was last scanned (which means the first T24 timer will be about right, but all the others will measure just the time it takes to perform the loop).

Inquiring minds want to know. (Ron Beaufort - you seem to have more time/ willingness/ available equipment to do these sorts of experiments than I do. Can you give it a try?
 
Excerpt from the link Ron posted:

The hardware timer of the primary processor is completely asynchronous to the hardware timer of the secondary processor. If the whole three word timer structure, including this timer byte is transferred from the primary to the secondary processor during a switchover, then the timer could encounter a large positive increment in the timer accumulated value. The worst-case increment may be up to 2.55 seconds, which may cause a large bump.

2.55 sec = 7 bits of 10 msec counting. It's beginning to make sense.

: 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.

So there is something that's keeping any timer from being updated more than once in a scan. Perhaps that's what the Reserved bits in word 0 (bits 8 to 12) are for. 2 are for time-base, which leaves 3. Perhaps one is set when the TON executes, and reset during housekeeping between scans.

It's just speculation though. I'd love it if AB (or any other PLC manufacturer for that matter) would give this kind of detail as to how the thing REALLY works.

I can only imagine the programs that such info would inspire.
 
Timers and counters are essentially the same thing...

Actually, Timers and Counters are Actually the same thing!

One is subject to a "regular" event (a timed update by the system).
The other is subject to relatively "random" events.
 
I largely agree. It's no coincidence that AB timer and counter elements are both 3 words long.

But a counter updates it's accumulator on the scan that it is 'activated'. A timer (with a timer base longer than PLC scan) updates it's accumulator after X number of scans.

What I'm interested in is how the bookkeeping is accomplished to know when "it's time" to increment the accumulator.

I've always taken it on faith that if it says "60 seconds", it will be 60 sec (± some msec). But now I'm interested in the science behind the faith.

<hr>

I don't want to limit to just the AB line of PLCs. If anyone KNOWS how other PLCs keep track of time in their 1 sec time-base timers, I'd like to hear.

<hr>

To ICAPALDO: If you've got any more info/questions, please jump back in. We go off on tangents a lot on this forum (sometimes quite unrelated to the topic at hand). But tangents give this site its distintive flavor, and it's a practice I don't want to see stopped.
 
Last edited:
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.

timer_fun.jpg
 

Similar Topics

Hello everybody, Since my experience is mainly with AB ladder I am having little bit of a problem with EasySoft.. Does anyone knows is there a...
Replies
4
Views
807
Does anyone know of a library that already has a implemented RTO? I was going to write my own but I'd rather not take the time.
Replies
35
Views
11,097
Hi there i was wondering if we can change in the TON the ms to min..... or how can i make a transformation... that shows up in c-more. cuz I am...
Replies
8
Views
2,127
All, I've got a TON that keeps resetting itself even though the rung remains true, I've slammed my head over this for some time now and cant...
Replies
16
Views
4,551
Ok guys I have a strange one. I just added a timer to to ML 1400 program, and it is not accumulating anything. But the OTE after the XIC TT...
Replies
6
Views
1,945
Back
Top Bottom