Latch or sealed-in?

Reading seems to point to using latches as bad practice, and using a sealed in rung is better.

I'm sketching out a project now and trying to use sealed-in rungs instead of latches but as far as I know, the way to turn off a sealed in rung is to add an XIO set and open that elsewhere. That would mean that the XIO used to open that rung must be closed again at some point for the process to repeat, multiple XIO's if I want to open it in various places?
This seems more complex than simply using an OSR-OTU pair wherever needed to unlatch a bit.

Is there a real issue with using latched bits and having more than one OTU command?

Am I correct that if OTL/OTU is used then a reset section of code should be executed once at each power up to clear all the latches?

Am I missing something?

...as far as I know, the way to turn off a sealed in rung is to add an XIO set and open that elsewhere.

Click to expand...

What do you mean by "XIO set"? It is much simpler than you are thinking. Here is an example of typical Start-Stop logic for to control a motor output, not using latches.

| Stop  Stop  Enable                                |

|  PB1  PB2   Conditions    Start PB1     Motor RUN |

|--| |--| |------|/|------+-----| |-----+-----( )---|

|                         |             |           |

|                         | Start PB2   |           |

|                         +-----| |-----+           |

|                         |             |           |

|                         | Motor RUN   |           |

|                         +-----| |-----|           |

This logic can be easily programmed on one rung. It can STOP the motor from any number of Stop Pushbuttons, and allows other sensors and conditions that need to be closed before the motor is allowed to run. It can START the motor from any number of pushbuttons or control stations, and it can seal in the RUN condition with a contact from the motor starter, or even a Zero-Speed switch that detects if a mechanical device is actually moving.

All this in one compact logic rung. Compare that to the number of Latches and Unlatches you would need to get the same functions.

Compare the ease of having all this on one rung for troubleshooting, to the difficulty of hunting down all the Latches and Unlatches scattered through the program for one lousy motor. A single latch/unlatch pair looks easy to understand, but when you get 3 or 4 for the same device, it becomes confusing, and hard to find all the cases when you are troubleshooting.

But I realize most of us (me included) have to learn the hard way - by experiencing latch he!! at 3 AM on a cold night with the aligators nipping at your backside.

IMHO OTLs are with rare exception only used on bits that have to retain state after power cycling.

IMO it depends entirely on what you're doing. OTL/OTU has it's place, as does OTE and a hold in contact.

If it's easy to understand, easy to troubleshoot, and easy to make changes to, it's good practice no matter how you achieved it. If it becomes difficult to read and changing one rung upsets two others, then it's bad practice.

Lancie1 said:

But I realize most of us (me included) have to learn the hard way - by experiencing latch he!! at 3 AM on a cold night with the aligators nipping at your backside.

Click to expand...

Ain't that the truth. After a few of these experiences you'll soon work out where OTL and OTU is or is not good practice! My favourite example of this was a machine with a MicroLogix 1400 where they had used latches for EVERYTHING. But then, instead of using unlatches, they'd used a masked move instruction, with the mask shown in hex, to mask all but the one bit they wanted to turn off. Occasionally they would turn off two bits at once with the masked move instruction. So not only were there 5-10 places your bit could be unlatched, but YOU COULDN'T CROSS REFERENCE IT. You had to search for the entire B3 element and trawl through 70-80 results with a hex calculator beside you. I have never seen a worse example of PLC code in my life.

In Lancie's example of a straight motor starter, yes, here a hold in rung is definitely easier to understand, easier to troubleshoot and easier to change than an OTL and OTU pair. So OTL and OTU would probably be considered bad practice there IMO.

I first learned PLC programming on the old Omron brick PLCs. The only latch available was a single function (KEEP) with 'set' and 'reset' inputs, which forced you to keep the latch/unlatch logic on adjacent rungs (I think Siemens S5 was the same way).

I have maintained that practice, and always keep my OTL/OTU on adjacent rungs. I also never use multiple OTU instructions. One exception is for latching bits that I don't want to be retentive through a power cycle. Since I normally group them all together, I will use a FLL instruction to write zeros to my latch word(s) on the first scan. This is usually the first rung of the program as well.

As ASF stated, each method has its place. The trick is to make is easy for the next guy that has to figure out your program.



-Eric

If you organize your code into state machines and have multiple states that need to change a variable value, or have a case where in one logical condition you want to control some things this way and in another condition control them another way you either have to use latch/unlatch, intermediate variables, or horrendous spaghetti code.

Of course, seal-in is good to organize things in simple logic situation and there is some specific stuff about one shots or something that requires a seal in vs a latch to work (a Rockwell feature), but just categorizing latch and unlatch as bad and something to be avoid is silly. Like anything, if you're a bad coder you will make bad code if given the opportunity, regardless of if it is via seal-in, latch, or jump instructions. A good programmer writes well documented code that is elegant, easy to follow logically, and in bite sized chunks; if latches simplify your logic to make it easier to follow, use latches.

^^^^^^^^^^This.

Thanks all,

I will try to keep my code simple and also only use latches if really needed or to simplify things, bearing in mind their retentive nature.

Some good replies, thanks

Dave

Here is an example of "good" use of the OTL/OTU Combo. Assume the AOI in reference is always running in the background.

***** RUNTIME LOGIC ******



|  Condition   AOI.Request_To_Turn_On     |

|------||----------------(L)--------------|

|                                         |



***** DEVICE AOI LOGIC ******

| Request_To_Turn_On     Output_CMD         |

|------||-------------+------( )------------|

|                     |                     |

|                     |  Request_To_Turn_On |

|                     +------(U)------------|

|                                           |

You can now use latch the "Request_To_Turn_On" anywhere in your logic as it will always unlatch itself in the AOI. Probably more of and advanced method, but can be very valuable in projects where devices are shared among various logical sequences.

The key here is that it's just a request to activate the device, the AOI.Ouput_CMD is still a single use OTE that would activate the physical IO.

I'll usually only use Latches to represent the End of Stroke of something.
If it has to travel to one end, then turn around and come back. Latch at the end. Unlatch at the start. Make them retentive through a power-cycle. So when the robot boots up again, things will want to return to home in the correct direction.

Or, I had a trolley that was moving material, and 2 limit switches. First one was the "Slow Down" switch. Second one was "End of Stroke". On the VFD, it was an extra output to move Slow. It would Unlatch when: Moving back to home, and engage that same first switch (slow down). So when moving Back to Home, it would move fast, but if the direction were reversed to travel to Drop location, it would still move slow. More safe that way.

At my former job, we only used latch / unlatch bits for the main steps.

step 1 - latch a bit.
do the process.
step 2 - latch a bit. this bit kills the previous process bits.
and so on.

it takes a while to get used to, but that was the way we designed all the programs. When the machine crashed or faulted, the latch bits showed us where to look and the latched fault bits told us the error.

I do agree that one MUST be careful when using this type of programming. you latch bit A and unlatch bit A in only one specific location.

multiple latches / unlatches of the same bit leads only to heartache. an OEM programmed a machine with 14 latches and 23 unlatches of the same bit. What a mess to put it kindly. It took weeks to rewrite the code.

regards,
james

regards,
james

multiple latches / unlatches of the same bit leads only to heartache.

Click to expand...

James, I agree. We see many students and beginners on this site. In a majority of cases, the only way they know to turn on a bit is to use a latch. Apparently they are allowed to get away with this in class, or are convinced that it is the only way to program. The problem is that latch/unlatch are the only tools in their toolbox.

Lancie1 said:

Compare the ease of having all this on one rung for troubleshooting, to the difficulty of hunting down all the Latches and Unlatches scattered through the program for one lousy motor.

Click to expand...

+1

The immense advantage of Lancie's method comes in troubleshooting. The program doesn't care, it will execute either way. But a good programmer should ALWAYS keep the needs of the next guy trying to de-bug the logic in mind.

In the US we usually call Lancie's arrangement a holding contact. Elsewhere they use the terminology "seal in". Go figure!

Whenever I use a latch...the next rung is the unlatch logic.
You could latch.... perform logic based on latch.... and then unlatch. But now you have to search to find unlatch.