To Latch Or Not To Latch

Some points related to Ron’s example:

1. Saw example: I am not sure about SLC500 PLC's but in ControlLogix5000 I believe that outputs will stay "sealed" in during prescan. Other Booleans do not but outputs are treated differently.

2. Saw example: One note about inputs and power cycles. I have seen a couple of cases where a lot of confusion was caused by the fact that during a total machine power cycle the power supply to the inputs can die before the PLC power supply dies. In these cases the PLC is happily cycling along and interpreting the inputs going off as real events rather than being due to the power going off. Depending on the robustness of the code this can lead to interesting and confusing situations when the power is restored.

Example: I had a fellow programmer of a indexing dial/machine move the part data related to the nests when the index encoder counts went through zero degrees. Power cycle just the PLC and every thing was fine 100% of the time. The indexer was at X>0 degrees before, during, and after power cycle. However when the "turn off the mains" power cycle was tried the data would somehow be off by one position 100% of the time. He tried many things to fix the problem during start up of the PLC but could not locate/fix the problem. It ended up that the problem was actually occurring during the power down. The inputs were dieing before the PLC stopped scanning. Thus during the mains power cycle the PLC would "see" the encoder go through zero degrees and erroneously move the part data.

3. Adding points one and two together: I think this means that the saw example may or may not turn off depending on the circumstances. Power cycle just the PLC and it may stay on. Power cycle the main and it may turn off.

4. Another fun aspect to this is to add downloads into the mix. The output could be off before the maintenance guy downloads the code for some reason. Then you download the code and the outputs assume the value they were six months ago when the program was saved. And the machine was most likely running when the save was done.

Getting off topic here:
5. These issues always leave me in a quandary about what to do on first scan of the plc... More related to data than outputs. Most likely it was just a power glitch at the plant that is making the PLC do a first scan and the PLC still knows the real identity and location of all of the production parts. However if the first scan was due to download then the PLC has part identities and locations from some point many months ago and are completely wrong.

So do you always reject all parts even though most likely you'll be getting rid of perfectly good parts. Or do you try to continue processing even though you may occasionally get identity/good/bad status messed up. Or better/worse somehow leave it up to operator selection assuming they can understand your pop-up well enough to make the right decision.

Roy
 
With all due respect, and IMHO..... :rolleyes:

This is kinda a silly debate. Whether or not you decide to use latches is all a matter of the needs of your application, and if they are applicable to that application.. Just like any other instruction. Authough I find the arguments and examples interesting, I really dont get the point of it all...

Have a nice thread... Mike.
 
To latch or ???

We always use S:1/15 or Sp0 with AD to unlatch anything you don`t want to retain.
If you don`t and there`s much going on and the power cycles it looks like a you know what kind of fire drill. It`s a good idea to do this with AB SLC or Micros because what ever was going on the last time you uploaded is what is going to be going on after a download. If you don`t unlatch your out puts. Under all circumstances one of the main objectives should be to start up in a safe mode after a download or power failure. I`m sure at one time or another most all who deal with AB and some of the rest have made a small change downloaded it and whatched as all H*LL broke loose!! banghead It`such a humbling feeling, especially when all looking on thought you knew what you were doing??? lolis
 
Latches

I myself use latches from time to time but I do not use them when I can get by with a seal. If you are going to use latches, I would keep them all confined to a couple of words like B3:1 & 2 for example.
That way if you have a retun to home or a cancel sequence you can just use a Copy block and rezero them all at once.

Another thing I do is do is annotate the contact as a latch. For example: "Step 1 Complete Latch". This makes it easier for someone in the future to debug the program.

I have seen programmers who misuse latches and wind up in a mess if something goes wrong.
 
so how many worms are there in this can anyway?

Greetings to all:

responding to Roy C.’s excellent points and welcome comments in post #17:

1. Saw example: I am not sure about SLC500 PLC's but in ControlLogix5000 I believe that outputs will stay "sealed" in during prescan. Other Booleans do not but outputs are treated differently.

Roy, I’m not sure that I understand precisely what you’re saying here ... but I just finished trying out exactly the same “saw” and “grinder” program from post #15 on a set of ControlLogix hardware ... and I got exactly the same results as I did with the PLC and the SLC systems ... specifically, after a power cycle, the “sealed-in” saw did NOT come back on – but the “latched-on” grinder DID ... and I also got exactly the same results when I used internal BOOLEAN bits as when I used actual real-world hardware addresses for the rung “outputs” ... please post again and let me know if I’m missing anything here ...

2. Saw example: One note about inputs and power cycles. I have seen a couple of cases where a lot of confusion was caused by the fact that during a total machine power cycle the power supply to the inputs can die before the PLC power supply dies. In these cases the PLC is happily cycling along and interpreting the inputs going off as real events rather than being due to the power going off. Depending on the robustness of the code this can lead to interesting and confusing situations when the power is restored.

an EXCELLENT point (I was hoping that someone would bring this one up) ... and believe it or not, it has a LOT to do with whether the inputs (especially the inputs from normally-closed “stop” buttons) are powered by line-supply AC or by a DC power supply ... that’s right – there are DIFFERENCES between AC inputs and DC inputs ...

basic idea: during a “plant-wide” power failure, the AC line power drops out immediately - while the PLC keeps right on reading the field inputs for a number of scans ... so the PLC gets a chance to see a normally-closed “ON” input as an “OFF” signal ... that will cause the seal-in for the saw example to drop out ...

now let’s compare that to a DC-powered “stop” button ...

during a “plant-wide” power failure, the DC power supply for the inputs does NOT drop out immediately ... hint: think about that big old final “ripple-removal” filter capacitor on the output side of the DC power supply ... so while the PLC keeps right on reading the field inputs for a number of scans, it still continues to see the normally-closed inputs as ON (=1) signals ... that would NOT cause the seal-in for the saw example to drop out ... BUT ... PLEASE KEEP READING ...

the saw example in post #15 would STILL drop out (even with a DC powered “stop” button) if for no other reason than the processor’s PRESCAN routine which would automatically UNseal the saw’s “sealed-in” rung ...

so now let’s go back to post #15 and revisit our programmer “I-love-latches-Greg” and look at the grinder system in more detail ...

for my original grinder example, I had Greg use a “stop” button that was field-wired as a normally-open input ... (frankly I really expected someone to point out that this arrangement is not generally accepted as a good “failsafe” practice) ... so why did I choose a “non-failsafe” wiring method for my example? ... because that way, regardless of whether the power supply to the “stop” button is supplied by AC line power or by a DC power supply, I knew that the grinder would still come back up in the run condition after a power cycle ... I wanted to drive home the fact that “latched-on” and the “sealed-in” logic techniques can behave quite differently after a PLC power cycle ...

but now that we’re ready to dig deeper, let’s suppose that Greg had used a “failsafe” normally-closed “stop” button for the grinder ... and let’s suppose that the power supply for this particular input comes “right-out-of-the-wall” from an 120 volt AC line source ... in this situation the normally-closed “stop” button is usually giving us an ON (=1) signal ... so the XIC instruction on Greg’s “unlatch” rung will have to be changed to an XIO instruction ... once that programming change has been made, then during normal operation the unlatch rung will be false and the grinder will be allowed to run ... when the operator eventually presses the “stop” button, the XIO will be evaluated as “true” and the unlatch rung will stop the grinder ... perfect ... the boss checks it out ... he likes it ... he signs off on the checkout sheet ... life is lovely ...

so now ... how about a plant-wide power cycle? ... place your bets, gentlemen ...

when the power to the plant drops out, the AC supply to the grinder’s “stop” button INSTANTLY dies ... BUT (as Roy C. so wisely pointed out) the PLC processor keeps right on executing the ladder logic for a number of scans ... and (this is the point) the processor now sees the normally-closed field input from the “stop” button as an “OFF” (=0) signal ... and so the XIO on the grinder’s unlatch rung is suddenly evaluated as a “true” condition ... (hint if you need it: as far as the PLC processor knows, the operator reached over and pushed the “stop” button just as soon as the power failed) ... and the program logic tells the processor to unlatch (turn OFF) the grinder ...

that sounds GOOD to me ... I mean who wants the grinder to come back up in the run mode after a power cycle anyway? ... but think again folks: what if this happened to be the RECIRCULATION PUMP for our nuclear reactor instead of the grinder? ... with the setup I just described, the pump would still be turned OFF after a power cycle EVEN THOUGH we really-and-truly desperately wanted it to come back ON after the power cycle ...

interesting side trip: does "failsafe" always mean "go off"? ... it all depends doesn't it? ... sometimes "on" is safer than "off" ... now back to the main line of discussion ...

still with me? ... now let’s go back to post #15 and this time let’s suppose that Greg has once again used a “failsafe” normally-closed “stop” button for the grinder ... but this time let’s suppose that the power source for this particular input comes from a 24 volt DC power supply ... once again, in this situation the normally-closed “stop” button is usually giving us an ON (=1) signal ... and so once again the XIC instruction on Greg’s “unlatch” rung will have to be an XIO instruction ... and during normal operation the unlatch rung will be false and the grinder will be allowed to run ... when the operator eventually presses the “stop” button, the XIO will be evaluated as “true” and the unlatch rung will stop the grinder ... perfect ... the boss checks it out ... he likes it ... he signs off on the checkout sheet ... life is lovely ...

but again ... how about a plant-wide power cycle? ...

this time when the power to the plant drops out, the DC supply to the grinder’s “stop” button does NOT instantly die ... and even though the PLC processor keeps right on executing the ladder logic for a number of scans, (this is the point) the processor continues to see the normally-closed field input from the “stop” button as an “ON” (=1) signal ... and so the XIO on the grinder’s unlatch rung is still being evaluated as a “false” condition ... and this time the program logic does NOT tell the processor to unlatch (turn OFF) the grinder ...

that sounds BAD to me ... but ... regardless of whether it’s GOOD or BAD – do NOT (I repeat: do NOT) miss the point that it is DIFFERENT ... and !THAT! is the point of all of this ... many (most?) programmers do NOT know about this, folks ... most programmers are just interested in getting the darn machine to work ... PERIOD ... seldom (if ever) do they stop to consider what is going to happen in situations where the plant power eventually fails ... (or even in OTHER weird conditions beyond the scope of this post – yes, Virginia, there ARE other boogie-men out there) ...

so just to recap:

A. Greg uses a “stop” button which is field-wired normally-OPEN and is supplied by an AC power source ... when the system is power-cycled, the grinder stays “ON” ...

B. Greg uses a “stop” button which is field-wired normally-OPEN and is supplied by a DC power supply ... when the system is power-cycled, the grinder stays “ON” ...

C. Greg uses a “stop” button which is field-wired normally-CLOSED and is supplied by an AC power source ... when the system is power-cycled, the grinder goes "OFF" ...

D. Greg uses a “stop” button which is field-wired normally-CLOSED and is supplied by a DC power supply ... when the system is power-cycled, the grinder stays “ON” ...

[attachment]

now take a deep breath ... want to play hardball? ... then on to the next post ...

retain4.jpg
 
Last edited:
continued from the previous post ...

item D above isn’t really as simple as it might look ... to REALLY nail this beast down, we actually have to consider the “hold up” time of the DC power supply ... think about it ... the PLC has its own DC power supply – this is actually what keeps the processor going for quite a few scan cycles even when the plant power suddenly dies ... if the inputs we’ve been talking about have their own !SEPARATE! DC power supply, how can we be certain that the power supply will actually keep the inputs properly powered for at least as long (or a little bit longer) as the PLC processor keeps scanning? ... the truth is: we can’t be certain ... not until we carefully examine not only the specs on the DC power supply but also the LOAD on the DC power supply ... bad news: the higher the load (the more things presently turned on) then the shorter the “hold up” time of the DC power supply ... (think: the capacitor will discharge faster) ... and so ... we could actually get into certain intermittent situations (with something like example D above) where the grinder/recirculation pump MIGHT or MIGHT NOT sometimes actually come back up in the run condition ... worse case scenario: if the DC power supply just happened to be heavily loaded at the time that the plant power failed, then the power supply might not be able to keep those important normally-closed DC inputs in their correct (=1) states for as long as the processor continues to read them ... in this case, the DC-powered normally-closed input might still respond to a power failure with exactly the same results as an AC line powered input ... and so ... SOMETIMES our “we-really-want-this-thing-on” recirculation pump might not come back on ... but then SOMETIMES it does ... secret handshake: most people blame this type of situation on the “power surge” and let it go at that ... and then they just hope that it doesn’t happen again on their shift anytime soon ...

so ... ready for the big leagues? ... now let’s add some Uninterruptible Power Supplies to the mix ... how about one for the PLC processor? ... maybe one for the AC inputs ... and maybe one for the DC power supply ... too much to worry about? ... maybe ... but this is exactly the type of “beyond beginner” programming problems that Roy C. brought up when he said:

Example: I had a fellow programmer of a indexing dial/machine move the part data related to the nests when the index encoder counts went through zero degrees. Power cycle just the PLC and every thing was fine 100% of the time. The indexer was at X>0 degrees before, during, and after power cycle. However when the "turn off the mains" power cycle was tried the data would somehow be off by one position 100% of the time. He tried many things to fix the problem during start up of the PLC but could not locate/fix the problem. It ended up that the problem was actually occurring during the power down. The inputs were dieing before the PLC stopped scanning. Thus during the mains power cycle the PLC would "see" the encoder go through zero degrees and erroneously move the part data.

3. Adding points one and two together: I think this means that the saw example may or may not turn off depending on the circumstances. Power cycle just the PLC and it may stay on. Power cycle the main and it may turn off.

now ... a little bit of background for any newcomers ... technically I’m not what most people would call a PLC programmer ... by that I mean that I seldom get called upon anymore to write a program all the way from start-to-finish ... instead, a big part of my job for the last several years has been to solve knotty “why-the-heck-won’t-this-work” type problems for REAL programmers out in the field ... I’ve told you THAT – in order to tell you THIS ... I don’t make this stuff up, folks ... honestly I don’t have that much imagination ... this is all stuff that I KNOW has actually plagued people in the field ... over the years I’ve analyzed and corrected a LOT of “this-thing-is-driving-me-crazy” type programs for a LOT of frustrated technicians ... and to tell the truth, I actually enjoy it ... and my boss charges some pretty decent rates for it ... today I’m sharing it with you for free ... and yes, I’ll admit, it does go beyond the normal “traffic light” and “garage door” programming that some people never seem to grow out of ...

next ... for those who “just-can’t-get-enough” of this type of thing, you might want to take a look at this article which I wrote for another forum ... warning: pack a lunch ... in it you’ll find some “gotcha” reasons why the S:1/15 “first scan bit” trick won’t ALWAYS work exactly like you thought it would ... preview: if the duration of the power failure is very short (think: just a flicker) then the PLC processor might NOT actually fire the “first scan” bit ... even though the processor might still see a normally-closed input give an “OFF” (=0) signal ... oops! ... and so the carefully planned S:1/15 “let’s-always-do-this-when-the-processor-first-starts-up” logic might not really get the job done ...

and so ... regardless of whether you like “latches and unlatches” or whether you prefer “seal-ins” there ARE (usually but not always) various techniques which will allow you to use EITHER method successfully ... some of those techniques have already been suggested by other posters in this thread ... BUT ... the fact remains, there are some major DIFFERENCES between the two programming methods ... as some simple friendly advice, I strongly suggest that you make yourself aware of these differences ... in addition to the usually discussed “failsafe” issues of whether to use normally-open or normally-closed wiring for field devices, SOME critical situations actually call for careful consideration before deciding on whether the field inputs should be powered by an AC line source or by a DC power supply ...

now I’m sure that a lot of people out there might consider this material to be trivial information ... I’d say that those people just haven’t been bitten by this particular dog yet ... hopefully no one will get hurt when the lesson is finally brought home ...

so how much of this type of stuff do you really have to know? ... a lot of it depends on how much trouble NOT knowing can cause ... if the machines that you work with are less-than-threatening to life and limb ... and if the cost of an occasional “power surge” glitch is fully acceptable, then just go ahead and play the odds ... forget about all of this deep-dark-voodoo and get on with your life ... but on the other hand, if the machines that you work with can cripple and kill ... or if the money involved in a “what-the-heck-caused-that?” type situation could make or break your financial future ... then maybe you need to take a serious interest in this type of stuff ... trust me ... it’s out there and it will NOT go away just because you choose to ignore it ...

my work here is done ...
 
Ron's posts are always tough to follow . . .


Anyhow - I personally don't like latches and make only two exceptions to the "DON'T USE LATCHES" philosophy:

1. Safety on startup type issues like Ron describes.

2. Indication that a fault condition was active.


In both cases, I use the latch ONLY once in the code, AND use whichever reset method is appropriate in VERY close proximity to the original latch. As Tom said - commenting is critical whenever a latch/unlatch construction is used (not that it isn't important everywhere . . .).

Marc
 
I guess I'll take that as a compliment ...

from Marc:

Ron's posts are always tough to follow . . .

they ain't all that easy to write either ...

but for those who really want to understand, I'd suggest printing out the figures and then using a pencil to "mark-up" the "=1" and "=0" status of the various bits as you work your way through the description ... if you can't follow it, post and ask specific questions ... I'll see what I can do to elaborate ...
 
Last edited:
good grief

Thanks Ron You`ve given us alot to think about and it all makes perfect sense once it`s brought to your attention.
Thanks again :site:
Regards

Tom Sullens
 
I was always taught to not use latching and unlatching instructions.
There is always a way to accomplish the given task and latching/unlatching instructions is always the easy way out.
If a little time and brain power is put into it holding rungs will work and be alot safer in the long run.

When woking for large corporations and/or municipalities, townships, ect. you often are handed a book of rules and regulations about what is acceptable when programming pls, and i can guarantee 99% of the time one of the top rules is no latching/unlatching !!
 
Thanks the Merciful One, I don't have rules like that. Despite being employed by a pretty large corporation.

A few years ago, I was working for a small private company. We were avoiding using latch/unlatch (or, for that matter, set/reset) instructions unless absolotely necessary. For a simple reason: only one of several of our field techs could understand them. A naval battlegroup moves as fast as the slowest ship in it...

My choices between a "holding contact latch" and "set/reset" latch are rather of aesthetical nature. I don't like "macaroni code" (well, no one does, as far as I know). Think what an H.C. latch look like if it has three "on" conditions and five conditions to turn it off.

Another reason for me to prefer "set/reset" is that I commonly fire outputs from different locations in the program. Yea, I realize this is a big no-no for many, but I have to deal with scan time issue. My applications are mostly servo motion, scan time is fixed and I do not want to have it set too long. 2 to 5 milliseconds - that's it; anything longer, and I would not promise smooth motion or even accurate positioning. Therefore, I have to use selective scanning a lot, with number of subroutines being scanned or not conditionally.

So all the manual controls end up in one sub, which is being scanned only when the machine is in manual mode. The same outputs would also have to fire in sequence, in a different sub, while in automatic. Some PLCs would not even allow you to use the same coil twice in a program, some would but will display a nagging warning every time you validate or compile the program. That's when set/reset comes really handy! Another benefit of this technique is that everything remains in its last state when transitioning from auto to manual and back.

Of course, I do not use the output bits: there is an internal bit that gets set or reset in different places. One continuously-scanning sub links each bit to its corresponding output. By the way, this is a handy place to put any timeouts for those outputs that do need them: if the sequence was aborted in the middle and an output got stuck (since the sequence sub is no longer being scanned), it will always time out and turn itself off - by resetting the internal bit via simple timer. Gotta love those machines where some noisy air blow, vacuum or vibration parts feeder keeps hissing or buzzing forever?..

I don't mind using holding contact latch for something simple. But I would certainly use "set/reset" for something more complex. Yea, gotta be careful. A simple sub that runs upon E-Stop transition simply clears all the bits that must be cleared (like sequencers). That's all there is to it.
 
I've got to see it to believe it ...

from bakerboy_99ca in post #27:

If a little time and brain power is put into it holding rungs will work and be alot safer in the long run.

now, bakerboy, I certainly don’t want to start an argument ... and maybe I can actually learn something new here ... but please post again and show me how a “holding rung” will allow me to keep my recirculation pump running after a processor power cycle ... if there is any way to do this with an Allen-Bradley system, I personally don’t know about it ... the comments in the figure below sum up what I’m trying to say ... specifically ... with an Allen-Bradley system ... there is no way that a “holding” or “seal-in” type rung can bring an output back on again after a processor power cycle ... period ... and I don’t care how much “time and brain power” is devoted to the task ...

[attachment]

now just to keep the discussion to a minimum, let me nail down the fact that that there ARE some types of outputs out there in the real world that we DO want to bring back “on” again after a power cycle ... do you agree or disagree? ...

I’m using a “Recirculation Pump” as my example here because most people have no trouble visualizing that “Yes, we DO want this pump to come back on again after a power cycle.” ...

I’m saying that no type of “holding” or “seal-in” rung construction is going to satisfy that requirement ...

and another prime example would be the “log-in-position-A” bit that I mentioned back in post #15 ... again, we definitely want the processor to remember that there IS a log in position A after a power cycle ...

again ... I’m saying that no type of “holding” or “seal-in” rung construction is going to satisfy that requirement ...

and so if you can show me how to do this, I would sincerely appreciate it ... I’m not so old or so smart that I can’t be taught a new trick from time to time ... and I’ll be gracious enough to admit it if I’m eventually proven wrong ... I look forward to hearing from you again ...

PS edit ... bakerboy, please do NOT take this as a personal attack ... I certainly don’t mean it that way ... but I really would like to know what strange kung-fu you’ve got available ...

latchorseal.jpg
 
Last edited:
I promise I’ll be brief ...

Greetings to all,

I’m afraid that through all of this “latch” or “don’t latch” discussion, some people might still be missing a very important point that I've tried desperately to make ...

there can be !SERIOUS! !SAFETY! !ISSUES! involved when deciding whether to use – or not to use – retentive instructions such as latches! ...

let me spell this out:

(A) sometimes you SHOULD use a latch ...
(B) sometimes you should NOT use a latch ...

there is a LOT more to consider when making this decision than just your personal preferences about what “looks neater” and what makes for “easier troubleshooting” ...
 

Similar Topics

So I'm having issues with a certain rung and one of my coworkers mentioned it may not allow the signal past the latch coil. For example in the...
Replies
27
Views
3,692
Hello All, Can someone see what I did wrong here. My "PA" bit never seems to get energized despite hitting "SOFTKEY7" many times
Replies
5
Views
706
I am trying to use level switches to control a valve. If a level switch goes hi, it closes a valve. I am using ONS to keep the switches...
Replies
4
Views
1,011
There are some programs that have multiple latch instruction on the same rung of logic when RS Logix 5000 is the development software. The RS...
Replies
11
Views
1,555
I need to describe sections of a ladder logic program is a latch section to stop/start a machine also considered an or gate ??
Replies
1
Views
665
Back
Top Bottom