RSLogix 5000 - Reusing timers

Hi Guys,

Is there a way to reuse TON timers in RsLogix 5000?

I used TON, then after it's .DN, then I RES it.
Later on, I reuse the same timer. But doesn't count.

It .EN is on, and accumulator is 0. But for some reason, the accumulator never increments, and .DN is never set.


I know you there's enough memory to declare millions of separate timers, but it's tedius to create a new timer every time, or try to give it a useful name, or keep track of numbered names.

Thanks!

You need to use a seperate timer for each TON/RTO/TOF timer.

This is a common mistake. People often think that when a timer or OTE instruction is on a false rung that it is not doing anything. And continuing that false assumption, since it is not doing anything, you can reuse them elsewhere in your logic.

This is of course incorrect. The instruction you are using is categorized as "non-retentive". Meaning the instruction does not retain it's data following a power cycle or a false rung. In other words when the TON timer goes false it really is doing something. It resets back to zero. Every scan as long as the rung is false, it continues to reset. That is why your other timer is enabling but won't time. The false timer keeps resetting it.

As suggested, use a different timer tag for each timer. Another hint, and this is going to sound like I am being mean, but that is not my intent. In RSLogix, click on the timer instruction in your logic window and then press F1. There is a wealth of information there with everything I just explained.

Good luck,

OG

Thanks for the good info.

Yes, I didn't take into account the False rung-in condition.

I did look at the F1 help, but it wasn't explained as nicely as you just did =)
Now that I look at the F1 help again, it does (finally) makes sense to me.

Thanks!

Clementcbc,

Normally you will not run out of timers and do not have to worry about reusing one. But if you really want to use a timer more than once, there are ways.

The timer instruction box should only appear once, but the rung logic on the input side of the timer can contain many parallel branches, each used for a differnt part of your program and for differnt functions. It is smart to make sure that none of these functions need to use the same timer at the same time. The timer Preset value can be changed to different values as needed in the differnt parts of the program.

I will try to find an example and post it.

@Lancie1
That sounds like a pretty smart idea!
It'll probably be easy to create a EnTmr1 Tag. And whichever rung needs to use it will just energise EnTmr.
E.g.
|---|EnTmr1|-----Ton(Tmr1,5000)-----|

|---|Input1|-----(EnTmr1)-------------|
|---|EnTmr1.DN|---------RES(Tmr1)----|

|---|Input2|-----(EnTmr1)-------------|
|---|EnTmr1.DN|---------RES(Tmr1)----|

etc....

clementcbc, be careful of the specific construct you show. Using EnTmr1 as a tag in an output instruction (OTE) in multiple locations can be an issue. You are better off using the input conditions directly.

Keith

Here is an example of using a timer (T4:0 in Rung 7) more than once, that actually happens a lot for alarm logic.

Hey Keith,
What could be an issue?
As long as the Input1 and Input2 are never on at the same time it should be OK, right?

At first glance, I thought you were modifying the Timer element EN bit directly with your tag called EnTmr1.

Keith was warning you about the double coil situation...with two OTE assigned to the same tag.

Your best bet is to use a separate timer tag for every timer. You can get cute and use the same timer in multiple situations, and even write in different presets if you want, but it is going to be a clusterfudge to troubleshoot.

Memory is cheaper than downtime.

PLC logic (generally) executes top to bottom, left to right. This means that if a tag is operated on in two locations in a program, the last location in the program scan will determine the state of the tag. In your example, the state of Input2 will determine the state of EnTmr1 from the rung containing Input2 until the rung containing Input1.

When you use a normal output (OTE) a false rung condition sets the output tag to false.

Logically an OTE is

IF (Input = 1) Then
Output = 1
ELSE
Output = 0
ENDIF

Keith

To make it work, put Input2 on a branch in parallel with Input1, remembering that Input1 and Input2 are mutually exclusive - they must not need to operate Timer1 at the same time, or if they do, it must not create a conflict.

|---|EnTmr1|-----Ton(Tmr1,5000)------|

|                                    |

|---|Input1|--+--(EnTmr1)------------|

|             |                      |

|---|Input2|--+                      |

|                                    |

|---|EnTmr1.DN|---------RES(Tmr1)----|

|                                    |

clementcbc,

One thing is really clear from your questions so far...

You are not clear on how timers work in the PLC. Specifically, check out the instruction help in RSLogix5000 it actually does a fair job of explaining what is going on.

I used TON, then after it's .DN, then I RES it.

Click to expand...

It is rare that you need to RES a timer, they are reset when the rung goes false.

As for the hassle of naming lots of timers, a suggestion:
Try to limit the scope of your naming.

Timers that are simple delays and do not need to be referenced outside the current program should be declared local. This allows you to reuse the timer names for common functions and not have to keep coming up with unique names.

If the timers are associated with specific types of equipment, consider embedding them in a udt with the rest of the data associated with that type. One tag per device with all the associated data as members is much easier to manage from a naming point of view.

Add On Instructions also allow you to embed timers without having to name them separately.

Bottom line, if naming timers is such a hassle that you are considering reusing them, you are probably doing something the hard way. While it is possible to reuse timers, I don't see any good reasons to do so. In a limited PLC where you may need more timers than are available, it can be useful to know how. But in the ControlLogix I find it difficult to believe that reusing timers will result in less hassle overall.

You might get more useful advice if you would describe what you are trying to accomplish that is requiring so many timers.

clementcbc said:

Hi Guys,
I know you there's enough memory to declare millions of separate timers, but it's tedius to create a new timer every time, or try to give it a useful name, or keep track of numbered names.

Thanks!

Click to expand...

If you are to lazy to create some reasonable documenation for others that may follow you, then please don't come to our neck of the woods.

Anyway, since you are using RS5000, why not create an array of tiemrs, called TIMERARRAY for example, that way you do not have to create a new timer every time, and can just adjust the array index.

Just my 2c

You guys are right, creating a new timer for each one is the most reliable way.

I'm more used to C-programming (or other non-PLC programming), and having give a new name every time you use a function just doesn't rub well with me.

As for declaring an array of timers, or using numerical names.
I just find it tedious that i need to keep track of which TimerArray[X], has been used and which haven't. You come back to your code few days later, or change some old code, and you'd need to do a cross reference before you use a timer to make sure it hasn't been used before.

It's just a personal dislike/annoying thing.
I don't have a technical difficulty as such, just trying to find a better way of doing things.

I should just stop complaining and get back to some real work.

Learnt a lot. Thanks guys!