Good Programming Practice: Latches?

I was wondering was considered good practice when it comes to programming.

When I first started out doing ladder, I went crazy with my Latch / Unlatches ( Set / Resets ). I was told by many older engineers that to try and avoid using them, and when I did, to manually latch the bit or output rather than the latch/unlatch instruction.

That said, latch and unlatch are very useful in many instances, and I find if the code is well organized and commented you can be a little more liberal with your usage of those instructions without making things too confusing.

I just wanted to get some input from some of the more experienced programmers.

Thanks.

kdcui said:

I was told by many older engineers that to try and avoid using them, and when I did, to manually latch the bit or output rather than the latch/unlatch instruction.

Click to expand...

As soon as I heard that, it would be a sign that I should ignore the rest of what they said. It's just dumb.

The S/R, Latch/Unlatch are just instructions, and are there to be used. Use them. It's much more important to concentrate on writing robust code.

S7Guy said:

As soon as I heard that, it would be a sign that I should ignore the rest of what they said. It's just dumb.

Click to expand...

Ha ha - I agree.

I think what he meant by manually latch, was using a seal-in branch...

Latch and Unlatch can be abused. I have seen that many times, turning what could be a straightforward program into a bowl of chopped spaghetti.

They are sometimes necessary for things that need to be retained following a power cycle, and sometimes cleaner and simpler than alternatives for keeping track of things, like states of products for example. It sounds like the O.P. may have abused their use in the beginning...

OkiePC said:

I think what he meant by manually latch, was using a seal-in branch...

Click to expand...

Yes, what I mean it a manual seal in for a maintained output. Forgive my poor wording.

In this case it is particularly easier to see what is maintaining or disabling something.

OkiePC said:

Latch and Unlatch can be abused. I have seen that many times, turning what could be a straightforward program into a bowl of chopped spaghetti.

They are sometimes necessary for things that need to be retained following a power cycle, and sometimes cleaner and simpler than alternatives for keeping track of things, like states of products for example. It sounds like the O.P. may have abused their use in the beginning...

Click to expand...

Yep, my first couple of programs, I went particularly overboard with the latch and unlatch. But lately I am beginning to be a bit more liberal with them given that I can make the flow of logic and program easy to understand. That said, I am mindful of how and when they are used.

OkiePC said:

I think what he meant by manually latch, was using a seal-in branch...

Latch and Unlatch can be abused. I have seen that many times, turning what could be a straightforward program into a bowl of chopped spaghetti.

They are sometimes necessary for things that need to be retained following a power cycle, and sometimes cleaner and simpler than alternatives for keeping track of things, like states of products for example. It sounds like the O.P. may have abused their use in the beginning...

Click to expand...

I second Okie's statements. I have seen too many messes created by using Latch/Unlatch Set/Reset Logic. Multiple Latches and Unlatches on the same bit are hard to troubleshoot etc.

These are the rules I live by for Latch/Unlatch Instructions;

1) Never Latch a Real World Output.

2) Have a single Latch, and a single Unlatch for each bit.

3) Use sparingly when there is a real requirement to remember state through a Start/Stop, Power Bump, or Program/Run Cycle.

Having said that, there are times when these rules may need to be bent or broken, but only after forethought, and due investigation that there is other effective means of achieving your goal.

I do use Latch instructions regularly for very specific reasons, but I have never written a program full of them as I have seen some others do. In my opinion, that is poor programming practice.

Stu.....

OkiePC said:

I think what he meant by manually latch, was using a seal-in branch...

Click to expand...

I know what he meant, which is why I said I would ignore the rest of what he said. A latch, whether it is done programatically or with an explicit instruction, is still a latch.

If the use of latches becomes a hairball, it's an issue of bad programming, not an issue of using latches.

I'm sure I will hear about this here, but I just checked the last program that I wrote and this is what I had:

1000 rungs of code ( many will have multiple branches so there are much more than 1000 outputs)
280 OTL latch instructions
220 OTU unlatch instructions


I don't understand why anyone would have a problem with them. I have some bits that have multiple latch or unlatch instructions.

You can't just make blanket statements about programming and using instructions. There are probably 10 technicians that can regularly troubleshoot our PLCs and none have any problem with the use of latch/unlatches. They have more of a problem with sequencer codes - but that is a different thread for debate.

but don't forget the SAFETY issue! ...

actually there's a LOT more to be considered than just "design/neatness/readability" etc. ...

as mentioned by my distinguished colleague OkiePC, there are some things that NEED to be "latched" and other things that should NOT be latched ... the following link might be helpful ...

http://www.plctalk.net/qanda/showthread.php?postid=70681#post70681

and if you're using something other than an Allen-Bradley system, then this next link might be of interest ...

http://www.plctalk.net/qanda/showthread.php?p=71786&postcount=1

the point of this one is that "sets" and "resets" are NOT always the same as "latches" and "unlatches" ...

With the proper use of Cross References I'm sure technicians and programmers are able to figure it out.

But wouldn't you agree that having to chase down 3 or 4 different places where a bit is being set can be a bit tedious and confusing to someone who might not know the program, especially when you have 1000 rungs of code?

I'm not trying to make a blanket statement about latches, in the right circumstances you can liberally use them, but the code needs to be in a logical sequence and documented with comments to indicate what is going on.

Nice links Ron, Thanks. I hadn't seen that thread before I posted, even though I did a search.

S7Guy said:

I know what he meant, which is why I said I would ignore the rest of what he said. A latch, whether it is done programatically or with an explicit instruction, is still a latch.

If the use of latches becomes a hairball, it's an issue of bad programming, not an issue of using latches.

Click to expand...

The big difference is that a seal type latch will not ride through a power cycle like a Latch-Unlatch bit will. In most cases, you will want the PLC code to relatch them as needed in a controlled manner rather than having them retain their latched state on power up.

I see it as more of a safety issue than a 'programming neatness' issue.

I can program a manual latch to stay latched on a power up. In fact, I see it all the time. If the bits that are used to create the manual latch are retentive, it will stay latched just like a S/R will.

And as Ron noted, it isn't even consistent from PLC to PLC, but the bottom line is that people need to understand how to use the instructions properly and how the memory is reset on startup. I don't even rely on the retentiveness of the PLC and just reset everything on the startup anyway.

I'm not sure that I agree that a seal circuit will reseal if retentive bits are used.

When the PLC powers up, the condition that originally sets the output bit will probably be false (otherwise you wouldn't have needed the latch/seal in the first place). When the rung is evaluated on the first scan, the input conditions will be false and the output coil will be turned off, breaking the seal.

The problem with latch instructions is that they introduce a lot more scan order dependency issues.
I avoid them at all costs, they make commissioning and troubleshooting a hundred times harder. Its is also an indication that most beginner PLC programmers use them constantly, whereas more experienced programmers avoid them.

Sometimes you cannot avoid them, but unless you cant find an alternative, I would not use them.

I'm with Stu and Chris. The biggest problems I've had in my current job are a couple of work cells that were programmed by my predecessor using OTL and OTU everywhere, repeatedly and on physical outputs. When those cells went down, bringing them back up required a laptop because he never wrote any kind of initialization. Fault handling was pretty much non-existant, and an E-Stop might take 30 minutes to straighten out.

Of course, I got a little better with them after the first year. And, we rebuilt one last year (YAY!!) and we'll do the other this year.

Having said that, I can grudgingly say that latches and unlatches are ok if:

- They are used as, and labeled as, flags
- They are not used as states
- They are never used with physical I/O
- They are reset and the machine is left in a start-ready condition following an E-Stop

I'm sure that there is acceptable programming that would use them as states, but for that I prefer writing a state-based program using integer words for subroutine steps. In fact, nearly everything I do any more is state based. I've also done it using coils, but I prefer words. But, state or step programming is a whole other argument!