Good Programming Practice: Latches?

[brucechase]

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.

Unless you know all the programs out there, you can't say it's the inexperienced people who use them. I've been using and programming PLCs for 20 years and my process and my programming style is fine for using latches.

Quite the contrary, I find that inexperienced people who don't know the program blame things like too many latches when they can't figure out the problems.

 

[OkiePC]

One of the worst programs I ever had to fix was written by a real smart guy who had a background in C programming. His code was about 1000 rungs with several hundred latch and unlatch instructions. It seems that during the debug process he added more and more latched/unlatched bits to the logic to deal with things he did not think of at design time. When we pointed out something that the machine needed to do (or not do) he'd go far above and beyond and ended up with quite a monstrosity at the end of the week.

Eventually, after the machine was in production, and the OEM programmer was gone, we found occasional hiccups here and there...it would "forget" whether or not it had applied a strip to the fabric, and do it twice, or not at all. The issue was the logic was sensitive to the order of events which could on rare occasion trip up the logic. This was not because he used a particular instruction, but because his program lacked the structure and organization that would have made dealing with changes easier to implement on the fly.

I ended up replacing that code with about 200 rungs in a more organized fashion and reduced the number of latching instructions to very few. I still found them useful to "remember" what parts of the process had completed successfully, and for things like alarms, etc.

It isn't that the instructions are bad, even when used excessively, it is just that I see more poorly written programs that are band-aided into production with lots of them...and sometimes the programmer does not consider or fully understand what might happen during a power cycle as Ron pointed out...

 

[twu026]

I use latches in step sequences all the time and it works well.

Lets say there is a motor that needs to run in steps 2, 3, 5, 10 & 12 of a step sequence.

I simply unlatch the motor run bit every PLC scan before the step sequence.
Then I latch the motor run bit when I am in the steps that the motor needs to run.

The advantage of writing the code this way is that you can focus on the question:

What should happen in this step?

Rather than the questions:

What steps turn this output ON?

Since I am unlatching the bit every scan there is no risk of the bit staying ON unless I specifically latch it in a step. Essentially, this is a multi output coil work around.

 

[S7Guy]

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 same condition that "unseals" the latch would normally be the same condition that resets a S/R. I mean, what is the functional difference between these two code samples:

      A     M     10.0
      S     M     12.0
      A     M     10.1
      R     M     12.0
      NOP   0

      A(    
      O     M     10.0
      O     M     12.0
      )     
      AN    M     10.1
      =     M     12.0

On startup, the results are the same whether the bits are retentive or non-retentive.

For me, the S/R is easier to read an program, and I can swap the priority just by changing it to R/S.

 

[PLCMentor]

I avoid latches. I recommend that new programmers avoid latches until they have a feel for programming. With that said, there are times that they make sense and times when they are a must. If I dont have to use them then I will not. For new programmers, they generally cause more problems than they solve.

 

[curlyandshemp]

Years ago I worked with a guy on S5 projects. In the S5 world, the input/output image tables are updated then the logic is solved. This guy used to wrote 0s to all QBs ( output bytes) at the very beginning in OB1 before any logic was called. His thinking was any output that set by conditional scan logic would be reset after the first scan when the conditional logic was no longer called.

 

[rootboy]

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.

Well, not necessarily.

On conveyor systems for example, it is best to locate your "Carrier at Stop" limit a foot or so before the carrier actually gets into the stop. This allows the stop time to open without de-dogging the carrier if the zone ahead is empty. This not only improves throughput, but it also reduces unnecessary wear and tear on the conveyor system.

But if you were to use a standard relay coil (OTE) instead of a latch, and had a power cycle to the PLC, you would lose track of where the carriers were in your system. You would lose your "Carrier at Stop" bit as well as your "Zone Ahead Blocked" bit. This would potentially allow a carrier to advance into a stop that was already being occupied.

Latches will prevent this. However, I guess careful (and additional) coding would do the same for regular relay coils as well, but why not use the latch for what it was intended for?

I always liked the GE Series Six style of latch. The set and reset were part of the same rung and couldn't be separated.

This kept things much cleaner than the way that AB (and GE 90-30's) do it. Not that you can't do the same thing with AB or 90-30's, but I find that people tend to put the unlatch rung wherever they like in practice.

 

[Peter Nachtwey]

This thread is full of superstitious nonsense.

In C and C++ there are no latches. Think about that.

 

[LadderLogic]

There are no one-shots either.

 

[Gerry M]

Just write code that will make sense to you and someone else.
There is always more than one way to do it.

and

Never say never.

 

[OkiePC]

In C and C++ there are no latches. Think about that.

It's not that a C programmer is used to having latches, but he is used to having control over the program flow, and lots of other things that are "missing" or otherwise defeated by the cyclic nature of a PLC program.

I have seen more than one PC programmer write ladder logic that was very messy, overly complicated, etc...Not saying that a PC programmer can't write good ladder logic, but there are those that don't make the transition very smoothly...

 

[CowDung]

The same condition that "unseals" the latch would normally be the same condition that resets a S/R. I mean, what is the functional difference between these two code samples:

      A     M     10.0
      S     M     12.0
      A     M     10.1
      R     M     12.0
      NOP   0

      A(    
      O     M     10.0
      O     M     12.0
      )     
      AN    M     10.1
      =     M     12.0

On startup, the results are the same whether the bits are retentive or non-retentive.

For me, the S/R is easier to read an program, and I can swap the priority just by changing it to R/S.

I have no clue how to read the code you posted. Here's my example.

The first two rungs show bit N7:0/0 being set with a digital input and being held in with a seal branch. The second two rungs show that same bit being set with a digital input and held in by being a Latch coil. In both cases, input I:1.0/1 will unset the N7:0/0 coil.

Using the seal circuit method in the first two rungs, coil N7:0/0 will not be on after a power cycle. Using the Latch-Unlatch method in the second two rungs, it will. N7:0/0 is a retentive data type.

I also could have just used the I:1.0/1 in the seal circuit directly it makes no difference.

 

[mellis]

The argument against using latch/unlatch boils down to this:
I've seen them used improperly.
I don't understand how to use them properly.
I'm afraid other people don't know how to use them properly.
Let's just ban them outright!

This discussion should probably stick to AB PLCs, since other manufacturers equipment may operate differently.

There is more than one good use for OTL & OTU instructions in a PLC.

If all you do is simple motor stop/start controls then I doubt "you" have a good reason to use OTL & OTU. If you are using OTL and OTU because you can't figure out how to do a simple motor start/stop using an OTE and a sealin or what the implications are, that is a "bad" reason to use them.

Here is a real world example of where OTL & OTU can be very useful. We have a process using 100 automated on/off valves. We have several long complex sequences to make product, or washout the equipment. There are two basic approaches to how to setup the controls for each valve.

Each valve could be setup with its own logic that has for an open command a parallel branch with one XIC instruction for every step in every sequence that this valve is opened. The close command would be done in the same manner. The sequences would turn on a unique OTE for each step of each sequence. The parallel branches can get large quickly, a "popular" valve may be commanded more than 30 times.

Or, each valve could be setup with its own logic that has a single sequence open command bit and a single sequence close command bit. The sequences would OTL each valve's open command bit to open a valve, and would OTL each valve's closed command bit to close a valve. The valve logic would OTU the command bits after the valve reached the desired position or faulted. (Oh horror, there are more OTLs than OTUs and they are nowhere near each other in the code.)

Now which one would you like to be programming sequence changes on?

The first one, where every time you make a change to a sequence you have to make matching changes to any number of separate valve logics? And look out if you have to insert more steps than anyone ever planned for. It is very easy to make mistakes and very time consuming to check that the sequence is correct.

Or the second one where you make changes to the sequence in the sequence code and nowhere else. Inserting steps affects nothing but the sequence code.

I've done it both ways and I know what I prefer.

Safety - How to make a system like this safe is a lot more complicated than which instructions to use. Yes, you need to understand how the PLC actually works. Do we really have to state that? You do plan to test power failure recovery during commissioning right?

 

[kdcui]

The first one, where every time you make a change to a sequence you have to make matching changes to any number of separate valve logics? And look out if you have to insert more steps than anyone ever planned for. It is very easy to make mistakes and very time consuming to check that the sequence is correct.

This can be avoided by making a standard set of logic and passing in parameters and/or by using indirect addressing and FOR loops.

 

[gas]

I worked for a packaging machine company. The program used latch bits to sequence thru the complex program and was written by a mechanical engineer. We received many positive comments from the users about the readability of the program.
Isn't that what it's about?