To Latch Or Not To Latch

Re: I guess I'll take that as a compliment ...

Glad you took it as a compliment - that is absolutely how it was meant!

Originally posted by Ron Beaufort
they ain't all that easy to write either ...

Click to expand...

Don't I know it. You make some of the best posts on the board (particularly on issues like this). That's part of why I keep coming back . . .

Originally posted by Ron Beaufort
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” ...

Click to expand...

I also don't want to start an argument, but anyone who doesn't buy 100% into what Ron said in this quote should re-read everything that Ron posted in this thread.

Latches (or 'sets') can be dangerous if used improperly. Seal-in construction can also be dangerous if used improperly. MANY of the "to latch or not to latch" questions MUST be answered by answering (A) and (B) above.

ONLY in the cases where safety is NOT an issue should other drivers/preferences be considered. In these "non-safety" cases, 99 times out of 100 I think that the ease of troubleshooting the "use-once" seal-in construction outweighs the scan time improvements that might be possible with other constructions.

Marc

i see your point ron,

i guess it depends alot on what type of industry you are in.
and what type of machinery you are programming.

i deal mostly in robotics where i do not want things to start moving
after a power flicker or outage.

i am always open to learning new things, that is why this place is so good.

5% of my programming knowlege i learned in school. the other 95% i learned from studying other programmers and the way they wrote there code.

no two people program the same, many follow the same patterns but programming is a very personnal characteristic like a fingerprint.

thanks for your input, i will still try to use my kung fu brainpower to find a different way out of your situation.

regards
mark

well played, bakerboy ...

Greetings Mark,

thanks for not getting all bent out of shape ... after I re-read my “ok-show-me-how” post, I realized that it might have sounded a lot more “combative” in print than I had originally intended it ... I’m glad that you took it in the proper friendly spirit ...

anyway ...

just to nail things down, the reason that I’m so confident that !NO! type of “seal-in” rung will be able to solve the “come-back-on-after-a-power-cycle” requirement is because of the Allen-Bradley processor’s “prescan” routine ...

basic idea: if there is an OTE instruction ANYWHERE in the program (including in your “seal-in” rung), then the bit for that OTE will absolutely be written to an “OFF” (=0) condition after each and every processor power cycle ... so EVERY “seal-in” rung which makes use of an OTE instruction is automatically doomed to failure if it needs to bring its output back up in the “ON” (=1) condition ... think about it this way: during the “prescan”, it’s actually as though the processor automatically “unseals” the bit each time the processor starts up ...

back in post #27 you said:

I was always taught to not use latching and unlatching instructions.

Click to expand...

I know exactly where you’re coming from ... several years ago I worked as a “PLC lab technician” for a local technical college ... one of the PLC instructors had exactly the same “no latches” philosophy that you mentioned ... the students took a total of 48 weeks of PLC training – but they were supposedly forbidden to EVER use a single latch ... but ... since I was the guy who ended up writing all of the guidelines and requirements for the students’ lab exercises, I took it upon myself to include quite a few “this-must-come-back-on-after-a-power-cycle” requirements for the students to program ... the “no latches” policy was quickly dropped ... simply because the requirements could NOT be met by using any variation of the instructor’s favorite “seal-in” rung construction ...

you also said:

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 !!

Click to expand...

I’d be interested in knowing how the pundits who wrote those particular specifications would handle an output having the “this-must-come-back-on-after-a-power-cycle” requirements that I’ve been talking about ... or has that situation just never come up on the jobs you’ve worked on? ... maybe that’s it ... but I’d be willing to place a small bet that no one has ever simply stopped to consider just exactly how the machinery is going to react after a power cycle ... if that’s the case, then MAYBE someone should think about it ... then again, maybe it’s no big deal ...

after all ... as you said in post #32:

i guess it depends alot on what type of industry you are in.
and what type of machinery you are programming.

Click to expand...

exactly ...

There is a way....

Ron:

First off, let me say that I absolutely agree with everything you've said here.

But, there IS a way for the PLC to remember the states of outputs, and to re-engergize them on startup, without using latch/unlatch instructions.

[attachment]


Proper programming technique would put the third rung shwn as the first rung in the program, but I felt that this order told the story better.

Now, even with this example, I feel that use of latches and unlatches are vastly superior to the method shown here. The only reason I've posted this snippet is occasionally I've been in situations described above, where I'm not allowed to use latches by Code Standard, but required to use them by Safety Specification.

The masked move in the third rung allows you select WHICH outputs you want to turn on, and which you don't.

---

bakerboy_99ca said:

i deal mostly in robotics where i do not want things to start moving after a power flicker or outage.

Click to expand...

I'm surprised you don't use latch/unlatch more, if you work with robots. Naturally, you don't want things to move. But I would think that you would want to know Where-In-Space things were before the lights went out, so that you can navigate back to a safe position. A seal-in circuit won't do that for you, as Ron describes. Although perhaps you are using a variation on the code I've posted to accomplish the same thing.

Greetings Allen,

yes, you are certainly correct in that there are “other ways” to bring an output back on after a processor power cycle without using a “latch” ... but as your comments indicate, a “seal-in” rung construction will not do it – in spite of what some of the other responders were saying ...

as an alternative method, I like your use of a rung to “store” the bit status during run time ... and then another rung to “retrieve” the bit status at start up time ...

your approach makes perfect sense as a valid “here’s-one-way-to-do-it-without-a-latch” solution ... but ... you and I are in full agreement that this method is certainly more convoluted than the “latch” arrangement that the other responders have been trying to avoid ...

as you said:

... I feel that use of latches and unlatches are vastly superior to the method shown here. The only reason I've posted this snippet is occasionally I've been in situations described above, where I'm not allowed to use latches by Code Standard, but required to use them by Safety Specification.

Click to expand...

finally ... I’ve seen that “store/retrieve” approach used for Allen-Bradley systems where the programmer had come from a Texas Instruments background ... as you probably know, the TI has blocks of “internal bits” that are retentive and other blocks which are NOT retentive ... the approach that you’ve laid out can be used to emulate the TI functionality on an Allen-Bradley system – which of course does not have the same blocks of “retentive” bits ...

thanks for bringing this method up for discussion ...

Hello guys!

This is some interesting reading....

As commented before the use of latch/unlatch (or set/reset as I would use since I'm mostly working with Siemens) is highly dependent on how you want it to work. But it's important that you take everything into consideration before deciding which method to use...

Like mentioned by bakerboy the approach depends on what kind of machines you are working on...

A comment on the

I'm surprised you don't use latch/unlatch more, if you work with robots

Click to expand...

by Allen:

I'm also working a lot with robotics (both programming the robot and the plc part) and here is how I use set/reset (viewed from the plc side only)...

I always use set/reset for status bits like part in position A, hence... the robot would tell the plc: part delivered to position A, set bit A. Machine uses part, reset bit A.
I'm using set/reset since I don't want it to be reset if the power fails. At start up I would recheck if the part is still there (if possible), if I'm unable to check I would tell the operator to remove the part (regardless if present or not) since I can't trust the status of this bit.

This status bit will in turn affect the status signal to the robot saying "ready for delivery of part".

I would never use set/reset for outputs on the other hand; the reason for this is that I don't want things to happen at start up of the machine. Like for a cylinder movement I would keep the output on based on the status of the position sensor of the cylinder instead of using the output.

This was just a comment about how I use the set/reset functionality.

Regards
Borte

Greetings to all,

my apologies for dredging up this old thread ... but I just wanted to "close the loop" for future searchers by mentioning a new thread about "latches" and "unlatches" (well, actually for "sets" and "resets") for the Direct Logic platform which is closely related to this older one which was mostly concerned with Allen-Bradley systems ...

while everyone is on the subject is it common to use an OTU without a OTL? It's the first I've seen it.

ddear said:

while everyone is on the subject is it common to use an OTU without a OTL? It's the first I've seen it.

Click to expand...

I'm not sure I would call it common, but it is a method to turn a bit off.

I have seen it a few times and have also use it myself.

ddear said:

while everyone is on the subject is it common to use an OTU without a OTL? It's the first I've seen it.

Click to expand...

I don't think anyone has been on the subject for 11 years But always good to see Ron's content bumped.

All kidding aside, I will use an OTU to ensure something will never be true. For example any interlock bits. By default my AOIs can process an interlock bit and turn off a Valve, motor...etc. The interlock logic is outside the AOI as who knows what the conditions may need to be to turn it off until you get into the design process.

By using an OTU, it just ensures that an interlock bit doesn't get 'stuck' true, per the retentive nature as discussed in this thread. It's also a nice visual to scroll through the logic and easily identify which devices have some type of interlock logic associated with it and which which do not.

I guess I should expand on my post above.

I use the "OTU" to turn off bits controlled by HMI/SCADA systems because I don't trust the HMI/SCADA to turn them off.

Also to disable fault bits (overflow,divide by zero etc.) that I don't care about.

Eric Nelson said:

I use both methods. As Terry stated, each one has their advantages/disadvantages.

When I use latch and unlatch, I try to keep them on adjacent rungs, so you don't run into the troubleshooting headaches that you mention.

beerchug

-Eric

Click to expand...

While there are times and places where Latch/Unlatch pairs make sense, and, to second Eric's point - they make the most sense when they are close in the program - that is, proving the point that they were used because it made sense...

I try not to use them, at all.

And, when I teach first-time programmers, I generally offer up that "any time you are using multiple LATCH or UNLATCH instructions to the same bit, there is almost always a better way to do it, which makes troubleshooting your code easier."
And, of course, while I do teach what the LATCH and UNLATCH do, I also teach what they do NOT do, and what responsibility it put on the programmer to address all conditions not in the logic....power up, power down, reload, upload, etc.

I will add that I have grown pretty fond of using OTL instead of OTE for device activations. Of course, I'm very specific about it, and it correlates to when I started to use grafcet to design my logic on paper prior to programming. I've found that using OTLs make the PLC logic (primarily ladder) align better with my grafcet designs because I can get away with duplicate OTLs without a concern. This alignment makes it much easier to program, test and validate. It also makes troubleshooting easier. Simply go to the rung that has the step logic that you need to troubleshoot and see what device OTLs are programmed.

Of course, one critical concept is that the OTL instructions are not used directly to activate device outputs. The OTL is an 'Output Request' flag used in the sequence logic. The sequence requests devices to activate and be controlled via the OTL flag, however its the device AOI/FB logic that does all the work in controlling the OTE for the actual output.

The 'Output Request' is processed in the device AOI/FB and the logic will energize an OTE for the actual output to the device if the 'Output Request' is true. Once this 'Output Request' is processed it is immediately reset via the OTU. As the next PLC scan runs, the OTL is re-energized and the device AOI/FB processes it, maintains the output OTE and de-energizes the request. Every scan the OTL/OTU is being processed. Once the sequence advances to the next step, if the OTL isn't programmed in the sequence logic the actual output OTE is de-energized due to the OTU of the 'Output Request' from the previous PLC scan. This means I really don't have to think about the OTU as it's a given in the AOI/FB.

One could argue that the fact that the sequence and AOI processing are a scan off could be an issue, but it's never been in my world. when I first saw this concept it took me a bit to accept, but once I did I found I could program and troubleshoot really easily, and the PLC code is extremely clean and repeatable. It has a good rhythm to it.

I don't use OTL/OTU for much else, I will second the HMI/SCADA situation where a pushbutton will set a bit to TRUE and the PLC code will use and OTU to reset it once it's been processed.

Any unique code I require that needs a latching mechanism, I will write the logic so it is self-latching.

ddear said:

while everyone is on the subject is it common to use an OTU without a OTL? It's the first I've seen it.

Click to expand...

Shift register.
Bits get set/latched/OTE'd depending on action/detection.
Bits get shifted per step.
Actions occur depending on status of bits.
Want to disable action of certain step due to detection/action in previous step.
Use an OTU.
Crossref won't find the OTE/OTL for that bit, even though it's being set.

Common? No. But it gets the job done.
If you use proper tag names, it's nice. If you use tags like B3 DINT[32] - B240 DINT[32] as main memory/tag usage, including shiftregisters, it's not so nice.