about AB's timer

qikuidg

Member
Join Date
Feb 2007
Location
shenyang
Posts
29
there are several timers in a routine,i want to use the "jsr" to run the routine for twice or more ,then the timer in the second
routine is very slowly,why and how will i do? thanks
 
If a timer is in a subroutine that isn't being called/scanned, then the timer values do not change. This is one of the classic gotcha's, a lot of consideration has to be given to timers when they are used in conditional subroutines.
 
Ken,

Can you clarify please?

I understand that if a subroutine is not called at all, the timer within won't start. Let's assume the timer is programmed with no input instructions. It runs if scanned. What if I run the subroutine once to start the timer? Are you saying that I must return to that subroutine to allow the timer to continue timing? It won't run without subsequent scans? I would have thought otherwise, since the first scan would have set the enable bit and the timer would run until done. Is that not the case?
 
A 'timer' is not a seperate process taking place all by itself outside of the PLC scan. The way a timer 'runs' (in AB at least) is, each time it is scanned it compares the current 'high speed time' (as kept by the system) with its copy of that time which it recorded during the last true scan. It uses this difference to update its accumulator (which is kept with more precision than that shown for the timer itself).

This would be all well and fine for a timer being only occasionally scanned except that the 'high speed time' as kept by the system is of limited duration. I believe for the SLC/Micrologix class CPUs it's only a couple of seconds. Thus, if the timer is not called at least once during each of these cycles the timer's accumulator will be inaccurate the next time it is scanned.
 
Last edited:
As bernie indicated, each time the timer is executed it stores an image of the system time. This time reference is stored in the low order byte of timer word 0. Because its the low order byte, only 8 bits are stored and therefore the number stored is between 0 and 256. Thus a timer must execute at least once every 2.56 seconds to remain accurate. If 2.57 seconds elapse between executions, the timer won't know it, it will only "know" that .01 seconds have elapsed.
 
Ron Beaufort said:
my distinguished colleague Bernie has already given you the answer ... but if you'd like more detail, then this thread should take care of you ...

This thread as well as the one you linked to provided alot of info. I wish the guy in the linked thread would have come back and let everyone know what happened other than just using a different timer#.

thanks to all for the info.

Bob
 
Hello,

To my knowledge, the timer status bits are set by the instuction itself (TON, TOF). Therefore, if your program is not scanning the rung containing the timer instruction, it's status bits (words) are not being updated.

Perhaps you can run the timers from an STI file, and access the Done bits and so forth from your SubRoutine.
 
thanks every for reply.in my program, the timer is scan cycle.there are two rungs in program,every rung has a subroutine call the same timer,after the ton instruction,i backup the timer's DN,TT,EN and acc to some tags and before the ton instruction,i restore the DN,TT,EN and acc from the tags i backup them.then i monitor the timer online ,the value "acc" in the second rung increase very slowly.then i exchange the subroutine in rung 1 with rung 0,there are always a slowly increase "acc" in the second rung.
 
Somehow, that just sounds like a bad idea to me.
If you are really trying to monitor the scan time, or a long running cycle time, use the scan time monitor in the CPU status file (SLC/PLC/MicroLogix) or GSV Query the tasktime in Control/Compact/Flex logix.

OR create an STI, and increment a 'roll-your-own' timer value there.
 
If you use timers in a subroutine, that's a bad idea.
If you use timers in a program with a lot of subroutines, that *can* be a bad idea.

Make a separate ladder subroutine that is ALWAYS called from the main, every scan, and duplicate every single timer you have, using the timer's own bits (EN and DN) to determine whether to increment. If you have started one in a subroutine, use the DN bit to re-enter the subroutine.

Then you might start running into nesting issues... Yeah, keep 'em only one sub deep, if possible.

We had a PLC3 that took days to increment timers. The scan time was nearly twice as long as the required timer "hit rate" (1.5 seconds!?!?), and whoever programmed it used .1 and .01 timers when 1 second ones would do. I changed the timers to 1 second, and then figured where "halfway around" was in the program, and duplicated every single timer, there was a couple hundred of them. No problems after that.
 
qikuidg said:
thanks every for reply.in my program, the timer is scan cycle.there are two rungs in program,every rung has a subroutine call the same timer,after the ton instruction,i backup the timer's DN,TT,EN and acc to some tags and before the ton instruction,i restore the DN,TT,EN and acc from the tags i backup them.then i monitor the timer online ,the value "acc" in the second rung increase very slowly.then i exchange the subroutine in rung 1 with rung 0,there are always a slowly increase "acc" in the second rung.

Do I understand you correctly? You are copying the values of DN,TT,EN and ACC in one place in your program and then you are copying them back into the a timer somewhere else in your program. That is very bad programming practice and it is most likely the source of your problem. I'll wager you are not copying the reference time in the low order byte of timer word 0, so when you restore it all the reference time is still all wrong.

Why are you exchanging the internal bits of the timers?

Good programming practice is to leave the DN,TT,EN bits alone, and program every timer at a unique timer address. You have an unlimited number of timers available (up to the memory limits of the PLC).

Why don't you post your program and we'll take a look at it and see what is going on and help you out.
 
there are 14 rountines in my program,they have the same technics.so i want to make a common subroutine, other routine call this subroutine with different parameter and make different result.the common subroutine mainly use the timer to work, if make 14 programs with different timer in is the only solution.
 
I learned a long time ago not to try to be smarter than the PLC.

Sometimes repetitive, bulk editing is the best, both for you, and the guy who will be troubleshooting it later.
 

Similar Topics

Hi all, I have a simple question that I have overcomplicated and gotten stuck on. I have a variable, we can call it "light" that I need to stay...
Replies
4
Views
215
Question to anyone with ideas about my thoughts on upgrading a very vintage timer, which is being used to switch between 2 5hp domestic water...
Replies
14
Views
364
why my timer only executes once here? After first time i use it, ET stays at 0ms all the time. It is in FB
Replies
5
Views
288
Good morning guys, I'm searching for a Timer relay which accomplishes the "flasher" condition in the photo attached, however, I need the ability...
Replies
2
Views
532
Hello all, I am trying to improve my skills, so I decided instead of moving a value into every single .PRE of an array of timers, I thought I...
Replies
6
Views
314
Back
Top Bottom