ControlLogix5000: Timers on Rungs

Sorry for these very basic questions, but I'm not a PLC programmer (per se):

It appears that timers always seem to appear at the very end of a rung.

It's still OK to put them in the *middle* of a rung (followed by a contact testing for DONE), correct? Then, while the timer is not yet DONE, the rest of the rung doesn't execute, right?

I have to re-load this application when I'm done and there's no way to test anything prior, so it kind of has to work right the first time.

Colt Hero said:

Sorry for these very basic questions, but I'm not a PLC programmer (per se):

It appears that timers always seem to appear at the very end of a rung.

It's still OK to put them in the *middle* of a rung (followed by a contact testing for DONE), correct? Then, while the timer is not yet DONE, the rest of the rung doesn't execute, right?

I have to re-load this application when I'm done and there's no way to test anything prior, so it kind of has to work right the first time.

Click to expand...

Yes, you can put a timer in the middle of a rung.
Go ahead.

Here is an example of how I typically like to structure a timer for use in a Logix 5000 project...



Note how the timer is still positioned to the right of the rung for clarity. The mapped input bit (im), in this case, precedes the timer to enable it. The done bit is addressed underneath in parallel. The final user-defined program flag is then positioned after the done bit. This is one clear way to structure a simple timer's logic. Wherever you need the flag you use that on the relevant rung(s).

You can position the timer instruction mid-rung, and then place the done bit instruction immediately after it, and then followed by the intended logic to be controlled by the timer, and that is fine too. But is it as clear to look at or to read?

It's a user preference to some degree. What do you think you would prefer though?

Regards,
George

Here is another example showing what you are proposing...



Not too bad looking either? Yes? No?

Which do you prefer?

G.

Geospark:

Yeah, that's the way I've seen it done in this application (and a few others I've had to look at): timer at the end of the rung. I guess it's a convention?

I dunno ... I'm not a PLC programmer ... and this timer is just going to enable the rest of an existing rung, so if I put it in-line it saves me from having to create an additional tag (other than the timer itself).

Ladder logic kind of drives me crazy because it just seems like you're always having to break down compound statements into tiny pieces that end up being chained together with all these bits.

Thank you for your reply. That was quick and very helpful!

In many PLC interfaces the Timer is an output instruction and has to be on the far right because of this. When 5000 came along, they added the ability to have multiple outputs in the same rung.
So...many folks still follow the output convention event though they don't have to anymore.

It's still OK to put them in the *middle* of a rung (followed by a contact testing for DONE), correct? Then, while the timer is not yet DONE, the rest of the rung doesn't execute, right?

Click to expand...

trust me - I'm not trying to make this any harder than it needs to be ... but ...

in your statement quoted above, the rest of the rung WILL indeed execute ... it's just that the rest of the rung will be executed with FALSE logic ...

NOTE that we're assuming that you've actually installed that "followed by a contact testing for DONE" as you indicated in your first post ...

EXAMPLE:

suppose that the very end of the rung that you're describing has an OTE instruction ... when the TON timer is NOT done, that OTE will NOT be simply ignored ... instead it will be executed with FALSE logic - and it will tell the processor to "Go Write a ZERO" into its associated bit/box ...

I doubt that this distinction is going to cause you a problem - but other folks are reading this too ... it's best to sort of nail things down ...

also ... RSLogix/Studio 5000 platforms are the only ones that will let you put a TON timer instruction in the middle of the rung ... with RSLogix 5 and RSLogix 500 - the software will not accept a TON instruction in the middle of a rung ... that's why most people are used to seeing them programmed at the end ...

good luck with your project ...

Ken and Ron:

Ah-HA! Thank you for that historical perspective for timer placement on rungs. I really appreciate that! So it wasn't allowed mid-rung in the earlier software versions, but now it is - and that's why you more often see them at the end of the rung. Got it!

And Ron, thank you for clarifying my statement for others. As I said, I'm not a PLC programmer and I certainly don't want to confuse the younger guys here who are (or aspire to be).

So the more correct thing to say is: the rest of the rung logic still executes, but with a FALSE "state" (which means this logic could *still* do something if it used the FALSE state as its enable ... like a Timer OFF?) ... correct?

Hi Ken,

Yes indeed, convention drives a lot of these decisions. Personally, I don't use timers-to-the-right by convention though. I also don't use it by default, or wholesale. It's just a structural choice I make when creating a subroutine to define generic timer functions. The key thing being that we do of course have a choice.

I do, of course, also use the timer-in-the-middle when I feel it suits or keeps it simple, as Colt Hero seems to just require here.

Another part of the same project...



It does have its purposes, and while I know it was introduced to streamline logical execution, I wouldn't advise it to be used absolutely everywhere. Still, as I said, it is a user preference.

And p.s. to Ron...I don't think it pedantic you pointing this out. Even though I'm sure many of us understood that they meant "not execute" as in "some" logic after the timer will not do "something" as in execute a program flag instruction as TRUE or an Output instruction as TRUE. "Execute" has a very definite meaning here and should be distinguished, so fair dues on that.

G.

Another part of the picture is that some other PLC's require you to use timers in the "mid-branch" method, or are at least more commonly used that way.


In AB PLC's, most instructions other than your standard XIC/XIO and comparators are what you might describe as "straight through" instructions - i.e. if the rung-in condition is true, so is the rung-out condition. This is useful, because it allows you to put several instructions in series as we're describing. The timer is included in this - if you felt so inclined, you could put 20 timers all in series and they would all start and stop their timing operations together.

However, in a Siemens S7 PLC, timers don't operate like that. They don't pass the "rung power" straight through. A delay-on timer in Siemens land will only pass the "rung power" out the right-hand-side of the instruction once the preset time has elapsed. While these timers do have a .DN bit (actually a .Q bit, in Siemens-speak), and could in theory be used the same way as the AB timer in George's post #3, it's often simpler to just put them in series, as with George's post immediately above this one. Even simpler, because unlike George's example above, you don't need to worry about the .DN bit after the timer - that operation is performed implicitly by the timer instruction itself.

So, all that waffle just goes to say - if someone is used to the Siemens way of doing timers, its quite plausible that when switching to an AB platform, they'd default to using timers mid-rung (with the necessary addition of the trailing XIC Timer.DN bit), since it's the most similar to their familiar programming workflow.

To me, this is an example of the double-edged power of AB PLC's - they tend to allow you to do things in a myriad of different ways, which is great because you have almost unlimited flexibility in how you approach and solve a problem. But it can be not so great, because if the wrong sort of programmer gets a hold of an AB PLC, they have almost unlimited flexibility in how they approach and solve a problem

What tends to irk many Logix 5000 users, though, and possibly myself to some degree, is the superfluous appendix to the Timer instruction that is the --(DN)-- bit. It just hangs there, begging us to append something to it? But alas, we cannot. It screams this more loudly, I feel, when we place it mid rung as it looks considerably more isolated and forlorn. Especially where we add an XIC instruction directly after it, showing the DN status twice in close proximity to each other. It can look a bit daft, no? If only we could make better logical use of it, beyond a simple graphical representation?

We could branch off it and add an output instruction before the branch would tie into the main rung after the --(EN)-- bit. This way the EN could continue as normal with unconditional rung-continuity but the DN bit could still flag its condition on this same rung.

Or more simply, allow the rung to be linked to either the top EN bit for unconditional rung-continuity, or to the bottom DN bit for conditional rung-continuity. No need to place an XIC DN at all.

The Timer instruction's placement options are useful, indeed, but I think it still falls a bit short in the above regard.

G.

While you can put the timer in the middle of the rung as stated,
please consider what maintenance is use to and what their capabilities are.

most maintenance guys can read and understand wire logic / ladder logic.
they may get confused by putting timers, counters, outputs in series because they don't understand logix programming yet.

at my plant, we program just like you wire it.
timers, counters, copy, move, outputs and so on are at the end and in parallel form.

maintenance understands it, they can trouble shoot the program, the machine has minimal downtime, I rarely get phone calls at 2 in the morning.
I ok with that, i'm ok with 2 am calls if it's a real issue, not how do I read this rung of logic.

james

+1 for James.

My advice would be to look at other parts of the program and format your timer to match the existing convention. You may not feel it is the best or most logical way of doing it, but it is what maintenance is used to seeing and they should know how to read it.

Bubba.

ASF said:

Another part of the picture is that some other PLC's require you to use timers in the "mid-branch" method, or are at least more commonly used that way.


In AB PLC's, most instructions other than your standard XIC/XIO and comparators are what you might describe as "straight through" instructions - i.e. if the rung-in condition is true, so is the rung-out condition. This is useful, because it allows you to put several instructions in series as we're describing. The timer is included in this - if you felt so inclined, you could put 20 timers all in series and they would all start and stop their timing operations together.

Click to expand...

Really? Now I'm confused! I thought the output of the first timer (while not finished timing yet) would make the rest of the rung FALSE. Wouldn't the timers to the right have to be FALSE-enabled timers to start their timing?

ASF said:

However, in a Siemens S7 PLC, timers don't operate like that. They don't pass the "rung power" straight through. A delay-on timer in Siemens land will only pass the "rung power" out the right-hand-side of the instruction once the preset time has elapsed.

Click to expand...

This is how I was initially thinking it was going to work. Seems more intuitive to me this way.

ASF said:

So, all that waffle just goes to say - if someone is used to the Siemens way of doing timers, its quite plausible that when switching to an AB platform, they'd default to using timers mid-rung (with the necessary addition of the trailing XIC Timer.DN bit), since it's the most similar to their familiar programming workflow.

Click to expand...

I've never worked with Siemens PLCs, but I have worked with a Swiss-made DCS which used graphical software, and the timers worked like Siemens (maybe no surprise there?)

James Mcquade said:

While you can put the timer in the middle of the rung as stated,
please consider what maintenance is use to and what their capabilities are.

most maintenance guys can read and understand wire logic / ladder logic.
they may get confused by putting timers, counters, outputs in series because they don't understand logix programming yet.

at my plant, we program just like you wire it.
timers, counters, copy, move, outputs and so on are at the end and in parallel form.

maintenance understands it, they can trouble shoot the program, the machine has minimal downtime, I rarely get phone calls at 2 in the morning.
I ok with that, i'm ok with 2 am calls if it's a real issue, not how do I read this rung of logic.

james

Click to expand...

At least where *I* am, no Maintenance person has ever touched, or even perused (on their own), a PLC application. A few have shown interest and may occasionally sit down beside me while I'm fumbling through logic even *I'm* only looking at for the very first time, but that's it.

So for the purposes of this one Plant, nobody has ever been concerned about what a Maintenance person can or cannot understand in a PLC application. However, I *have* tried to promote making the applications smarter - with more, and better, Maintenance/Debug Displays ... so that Maintenance (and Operations) could use *that* to debug at a higher level, but that takes time that nobody ever seems to have around here with such a tiny staff responsible for a couple hundred controllers.