Good Programming Practice: Latches?

It's not the same thing. The difference is if the PLC loses power. If that happens, then the OTE will be set to 0, while the OTL will remain in its last state.

What are OTEs and OTLs? Can you show an example of what you mean? In the example that jstolaruk posted above, the outcome will be the same.


I've used thousands of latches (it was part of the PLC spec for the code we wrote for Saturn), and never had problems with the software because of the use of latches.

I'm with Peter on this, fear of latches is just superstition.

That's my opinion too. It drives me nuts when some old guy tells new programmers not to use latches or whatever the other superstition of the month is.
 
What are OTEs and OTLs?

These are Allen-Bradley commands for what in more general parlance are called "a coil" and "a set coil" respectively.

The problem is superfluous indeed. Some PLCs have all the internal memory retentive; some designate specific memory areas to maintain its states over the power cycle.

It is not a big deal to have a few rungs of the code or a whole subroutine to initialize the necessary data upon power-up. In particular, to reset all the latches wherever it is important to. It is commonly done for any type of PLC, no matter how its memory retention is organized.
 
These are Allen-Bradley commands for what in more general parlance are called "a coil" and "a set coil" respectively.

So in jstolaruk's post above, the bits would have the same state after a power-up? Because the other poster said that they wouldn't, but I can't see how that is possible.
 
So in jstolaruk's post above, the bits would have the same state after a power-up? Because the other poster said that they wouldn't, but I can't see how that is possible.

In my example using Allen Bradley products (and a few more that I've used), the bit that is sealed will not retain its state through a program restart or power cycle (off at restart); the latched bit will retain its state.
 
What are OTEs and OTLs? Can you show an example of what you mean? In the example that jstolaruk posted above, the outcome will be the same.

An "OTE" is AB-speak for a standard coil, one that turns off when the logic driving it opens up (or goes to 0).

An "OTL" is what AB (Rockwell) calls a latch. It gets set when the logic driving it goes hi (or 1, or true. However you like to express it). It will remain on until a separate rung containing an "OTU" (what we would call an unlatch coil on different PLC platforms) gets energized.

What makes things confusing (and potentially dangerous) is that in certain PLC platforms, you can put your unlatch rung anywhere you want in the program, or leave it out entirely if that's what you want to do. Or have any combination of OTL/OTU rungs in your program.

Or, put the unlatch coil in a different subroutine. Or, if you're really nasty, leave it out, and use an indirect reference to reset the coil. The opportunities for abuse are endless.

But what latches are useful for, are for "remembering" events should you lose power to your PLC. However, if you lose power to your PLC, I would say that you had bigger problems than the improper use of latches. :)


That's my opinion too. It drives me nuts when some old guy tells new programmers not to use latches or whatever the other superstition of the month is.

Well, the way that AB (and the GE 90-30's for example) do it they can easily be abused causing the problems that the other guys here are warning about. So they do have a point.

And I think that the asynchronous aspect of the I/O on the early AB PLCs (meaning that inputs show up in your program whenever they darn well please) led AB to create their Latch/Unlatch (OTL/OTU) coils this way.

So, there is reason for concern, but the good carpenter doesn't blame the tools, right? ;)
 
Last edited:
In my example using Allen Bradley products (and a few more that I've used), the bit that is sealed will not retain its state through a program restart or power cycle (off at restart); the latched bit will retain its state.

Ok, that is very surprising. In the first example, assuming that all logic is solved on the left before the output is determined (as opposed to a Modicon), I would expect that the output bit would retain it's state because the logic is resolved before it even knows how it was orginally set (if that makes sense; don't know another way to say it).

In the second example, the PLC remembers the orginal state, but since it was originally set with a Latch instruction, it remains set?

What would happen if the first example was preceded by the second example in the program? I'm just trying to understand the rhyme and reason behind this.

And they say Siemens is hard to understand. :)
 
In the seal example, b3/1 will energize with X true and Y false. On the very next scan, b3/1 is now energized and will "seal" around X and keep b3/1 energized until Y is false OR the if program is taken out of run (either by a power failure or the switch on the CPU, or through the program s/w).

In the latch example, if the last operation on b3/1 (be it a latch ON or unlatch off), if the processor stops and restarts, b3/1 will retain its value.
 
In the seal example, b3/1 will energize with X true and Y false. On the very next scan, b3/1 is now energized and will "seal" around X and keep b3/1 energized until Y is false OR the if program is taken out of run (either by a power failure or the switch on the CPU, or through the program s/w).

So AB doesn't have a concept of retentive bits? Because I would think that if the state of b3/1 was a '1' and the state was rententive, the bit would remain '1' after a power up on the first scan ecause of the 'seal'. No?
 
Another example: The OTL and OTU instructions on a bit is the s/w version of a latching relay.

The OTE instruction on a bit is just like a regular relay; take power away (program stops) and the relay turns off until conditions return true to energize it.
 
In the second example, the PLC remembers the orginal state, but since it was originally set with a Latch instruction, it remains set?

Yup.

What would happen if the first example was preceded by the second example in the program? I'm just trying to understand the rhyme and reason behind this.

Then (I suspect) that the latch would generally follow the state of the OTE coil. If one of the conditions that set the coil was off (not including any bit that was branched around by the OTE seal-in bit of course), then the output would be turned off.

If the order was reversed, with the latch placed after the coil, then the output would be on if the coil rung was true, or when the latch rung was true. But if the conditions necessary to turn the latch rung went from true to false, then the fate of the output would be controlled by the coil rung. Ummm, I think so anyways. :)


And they say Siemens is hard to understand. :)

It IS!!!

As is every other make of PLC. :)
 
If the order was reversed, with the latch placed after the coil, then the output would be on if the coil rung was true, or when the latch rung was true. But if the conditions necessary to turn the latch rung went from true to false, then the fate of the output would be controlled by the coil rung. Ummm, I think so anyways. :)

Interesting scenario, may have to test that. As a firm rule, I haven't mixed latch/unlatch instructions with regular coil instructions on a specific bit regardless of the PLC brand so I haven't run into this one.
 
Interesting scenario, may have to test that. As a firm rule, I haven't mixed latch/unlatch instructions with regular coil instructions on a specific bit regardless of the PLC brand so I haven't run into this one.

I certainly wouldn't. The only time I have actually come across it is when the previous programmer grabbed the wrong instruction by mistake. I've seen it maybe half a dozen times in the last twenty years or so.

But the good thing is that it tends to stick out like a sore thumb. Right after you find it. :)
 
An "OTE" is AB-speak for a standard coil, one that turns off when the logic driving it opens up (or goes to 0).

An "OTL" is what AB (Rockwell) calls a latch. It gets set when the logic driving it goes hi (or 1, or true. However you like to express it). It will remain on until a separate rung containing an "OTU" (what we would call an unlatch coil on different PLC platforms) gets energized.

What makes things confusing (and potentially dangerous) is that in certain PLC platforms, you can put your unlatch rung anywhere you want in the program, or leave it out entirely if that's what you want to do. Or have any combination of OTL/OTU rungs in your program.

Or, put the unlatch coil in a different subroutine. Or, if you're really nasty, leave it out, and use an indirect reference to reset the coil. The opportunities for abuse are endless.

But what latches are useful for, are for "remembering" events should you lose power to your PLC. However, if you lose power to your PLC, I would say that you had bigger problems than the improper use of latches. :)




Well, the way that AB (and the GE 90-30's for example) do it they can easily be abused causing the problems that the other guys here are warning about. So they do have a point.

And I think that the asynchronous aspect of the I/O on the early AB PLCs (meaning that inputs show up in your program whenever they darn well please) led AB to create their Latch/Unlatch (OTL/OTU) coils this way.

So, there is reason for concern, but the good carpenter doesn't blame the tools, right? ;)

Can ypu expand on this? I did not think older ab controllers had asynchronous i/o only contrologix? Or am i missing something?
 
Agreed, my understanding was that the older A-B PLCs updated I/O memory images between scans (unless the immediate instructions were used) and that the ControlLogix were ansynchronous. OTLs & OTUs have been around a very long time and it always seemed to be a natural s/w version of latching relays.
 

Similar Topics

I'm looking for some starter kits but there aren't so many on the market, so I'm thinking about buying individual components for my needs. I just...
Replies
15
Views
2,532
Good Day Friends! I really want to advance in PLC Programming like our guys here in this forum, and I'm Pleading to all friends here to help by...
Replies
5
Views
2,777
hi al.. i am a bigginer to plc programming..ladder logic can anybody pls suggest the best programming practices using in industries..
Replies
21
Views
5,214
Morning folks--I have been programming in RS 5 and 500 for quite a few years. I need to get proficient in navigating in 5000 and I would like to...
Replies
3
Views
1,800
Hi, Following a large project our company recently finished, I would like to ask what is the best method for object oriented programming. We...
Replies
10
Views
12,473
Back
Top Bottom