Sign in to follow this  
Followers 0
gravitar

When to latch and when to seal?

9 posts in this topic

I was just wondering.. What do you guys think about when it is best to toggle a bit on/off with OTL/OTU, and when is it better to seal the contact in logic? I have always preferred sealing the rung, as it insures everything goes back to the default state if the machine is unexpectedly halted. With a latched output, you have to make sure it gets unlatched!

Share this post


Link to post
Share on other sites
I generally use a Latch when I want to retain the state even after a power cycle or processor restart. I use them sometimes just to clean up the appearance of the logic. Often, it's more efficient and easier to read with OTU and OTL instructions. I try to use only one OTL and one OTU per bit to keep confusion to a minimum. Just my practice, I'm sure there are dozens of other opinions out there...

Share this post


Link to post
Share on other sites
Greetings, this post on another forum pretty well sums it up for me ... in many cases there are more safety issues involved than might first be apparent ... best regards, Ron

Share this post


Link to post
Share on other sites
This could be a fairly lengthy discussion I am sure there are a lot of different opinions on this one... Myself, I will only use OTL and OTU when dealing with a program written with bit shifting (In limited use), or when there is no other logical way of retaining a rung true. I have seen many programs written with latch instructions, and in many of these programs they are bandaided with fix on top of fix making for some tempermental and unstable logic. Some using multiple OTU , which is an entire other topic... I think there is a place for OTL/OTU instructions but to develop an entire program using them is asking for trouble.

Share this post


Link to post
Share on other sites
I try to avoid OTL and OTU (SET and RST). I agree with TechJunki, some of the worst spaghetti code I have been asked to look at was a tangled mess of SET's and RESET's. If you use them, I suggest putting the RESET (OTU) code immediatley following the SET (OTL) code when possible and NEVER use double coils! It's a pain to search a 15000 step program to find the RESET is buried 1000 rungs from the SET, and the coil is SET in 5 different spots There are always exceptions, bit I usually view excessive use of these as kind of a novice technique. My view on sealing the coil is you are creating a 'self contained' kind of an object, where all the logic for the outputs true/false condition resides within that ladder block. Now I'm ramblin', hope I made some sense!

Share this post


Link to post
Share on other sites
I agree with techjunki in some way there is a place for set/rst programming and I use it all the time. However I keep the rst with in the same program sequence as the set and not a 1000 rungs away. I would never double coil but I have had to work on programs that others have written and have been amazed by what some others can create. Rodney

Share this post


Link to post
Share on other sites
Wow. "NEVER"? "ALWAYS"? If the code works, it's not wrong, it's different. Could it have been done better? Probably. Is there a better way to do it? Probably.

Share this post


Link to post
Share on other sites
As mjrx stated, the beauty of a self-sealing coil is that it is “self-contained”. If you are trying to determine why, say, a valve is “not working”, all you need to do sit on the rung and watch the conditions on the rung that generate the output. No flipping back and forth between the OTL rung and the OTU rung. More importantly, the self sealing rung gives you more information at a glance: which are the steady state conditions and which are the transitory conditions. The transitory conditions are those that require the output sealing branch around them! In many cases, you don’t even have to wait for the transitory event (such as a push button pressed or a float switch made) to diagnose the problem: If an element outside the sealing branch is “false”, then you start your search there. Not impressed? Suppose you are debugging the same program WITHOUT the descriptor database, as is typical in emergency service calls. Then this steady state/ transitory state differentiation is especially useful. All things being equal, and in spite of the incorporation of high-level programming language utilities, a program should be written so that an electrician who knows how to read an electrical schematic can look at your program print-out and figure out how his malfunctioning valve is supposed to run. He can relate to coils and contacts which seal the electrical flow. OTL / OTU pairs are not analogous to his experience. Never say ‘Never’? I dare say so!

Share this post


Link to post
Share on other sites
"OTL / OTU pairs are not analogous to his experience" Actually they are. 11 pin magnetically held latching relay is one example.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0