Use or not Latch/Unlatch instructions
- Thread starter joaco1993
- Start date
jdbrandt
Lifetime Supporting Member
If you search this forum, you will find lively discussions about the viewpoints of latches.
Opinions vary, of course.
When I teach PLC classes, I simply caution students that if they insist on using latch/unlatch instructions, that they consider ALL conditions of the controller and its associated hardware.
JeremyM
Lifetime Supporting Member
I don't think there's a silver bullet approach, but I tend to use OTE for outputs themselves and OTL/OTU for process/machine states.
OTL/OTU requires complementary logic to change states.
OTL/OTU requires complementary logic to change states.
Last edited:
It's rather simple actually. You use latch/unlatch when you need to latch or unlatch something and you use a regular output coil (OTE) when you have a logical condition that controls the output.
If you think about something simple like a motor, you could use either depending on what determines when the motor is running or not.
The advantages of the latch/unlatch instruction is that you will have one rung with the logic to start and another rung with the logic to stop.
If you are using a self-latching rung with OTE you have the logic to start and the logic NOT to stop on one rung. Sometimes that is an advantage but it could also be a disadvantage if you have lots of complicated logic.
Either way I would use the way that works the way you want and is the simplest to understand and troubleshoot.
Don't pay too much attention to "rules". They're written for absolute beginners mostly.
As an example I consider using the same output multiple times in a program very good practice. It's obviously confusing when you don't know what you are doing and are mistakenly using the same output in multiple places. That is bad.
However, if you have a complicated program it's different. For instance let's say a machine that are running in two different modes, fully automatic and semi-automatic. You put the logic that only applies for fully automatic into one subroutine and whatever applies for semi-automatic into another and you call either of them depending on the mode of the machine. Now you will would likely have the same outputs in both subroutines. But looking at each of these different rungs that energizes the output, each one of them will only contain the logic that is relevant for that situation. It makes them less complicated and easier to understand. So when it's easier to write, maintain and troubleshoot, it's good practice.
If you think about something simple like a motor, you could use either depending on what determines when the motor is running or not.
The advantages of the latch/unlatch instruction is that you will have one rung with the logic to start and another rung with the logic to stop.
If you are using a self-latching rung with OTE you have the logic to start and the logic NOT to stop on one rung. Sometimes that is an advantage but it could also be a disadvantage if you have lots of complicated logic.
Either way I would use the way that works the way you want and is the simplest to understand and troubleshoot.
Don't pay too much attention to "rules". They're written for absolute beginners mostly.
As an example I consider using the same output multiple times in a program very good practice. It's obviously confusing when you don't know what you are doing and are mistakenly using the same output in multiple places. That is bad.
However, if you have a complicated program it's different. For instance let's say a machine that are running in two different modes, fully automatic and semi-automatic. You put the logic that only applies for fully automatic into one subroutine and whatever applies for semi-automatic into another and you call either of them depending on the mode of the machine. Now you will would likely have the same outputs in both subroutines. But looking at each of these different rungs that energizes the output, each one of them will only contain the logic that is relevant for that situation. It makes them less complicated and easier to understand. So when it's easier to write, maintain and troubleshoot, it's good practice.
bob1371
Lifetime Supporting Member
An older thread here but a ton of useful info. Be sure to read in it's entirety.
http://www.plctalk.net/qanda/showthread.php?postid=70568#post70568
http://www.plctalk.net/qanda/showthread.php?postid=70568#post70568
The retentiveness of the coils should also be considered.
The latch/unlatch outputs on AB (OTU/OTL) are "retentive" (don't know if that applies to them all) but on other PLCs retentiveness and latching are two different things and not intertwined.
I think this is probably the single biggest cause why latching or not, is a discussion at all.
Still, I consider it almost a must to have some form of initialization/resetting of things at start up.
.
The latch/unlatch outputs on AB (OTU/OTL) are "retentive" (don't know if that applies to them all) but on other PLCs retentiveness and latching are two different things and not intertwined.
I think this is probably the single biggest cause why latching or not, is a discussion at all.
Still, I consider it almost a must to have some form of initialization/resetting of things at start up.
.
Last edited:
MasterBlaster
Lifetime Supporting Member
When I first started programming, I used Latch/Unlatch quite a bit. With experience, I got to the point of using them ONLY when absolutely necessary. In most cases, it is cleaner to use logic to "seal in" an output.
Tom Jenkins
Lifetime Supporting Member
+1
The problem I see with latch/unlatch is that it is much more difficult to trouble shoot.
Agreed - ease of visibility and troubleshooting is the #1 reason to use either.
Typically, I use OTE for most things, and only use OTL for things that are turned on, used, and turned back off. For example, I'll use an OTL to turn on a "tare" command to a weight transmitter, and then have the weight transmitter controls turn it back off once it completes the tare.
One other place I use OTL/OTU is when I have a lot of conditions to OR in ladder logic. So, instead of having 15 rungs in parallel powering up one OTE, which means you can never fit the whole rung on the screen, I do this:
|----( L )-----|/|-----|/|-----|/|-----|/|-----|/|-----|/|-----|/|-----|/|-----|/|------(U)---|
So the OTL will set the tag, and if any one of the subsequent tags are set it will retain it's set status. If none of them are set, the OTU unlatches the tag at the end of the rung, and the rest of the program is none the wiser.
Of course, you have to be careful of interrupts and asynchronous things that might access it at the wrong time, but if you're careful about how you do it, it's a whole lot easier to see at a glance which area your alarm is in, for example, than having to scroll up and down past them all. And as the only instances of the OTL and OTU are on the same rung, it's nice and clear and easy to troubleshoot.
Typically, I use OTE for most things, and only use OTL for things that are turned on, used, and turned back off. For example, I'll use an OTL to turn on a "tare" command to a weight transmitter, and then have the weight transmitter controls turn it back off once it completes the tare.
One other place I use OTL/OTU is when I have a lot of conditions to OR in ladder logic. So, instead of having 15 rungs in parallel powering up one OTE, which means you can never fit the whole rung on the screen, I do this:
|----( L )-----|/|-----|/|-----|/|-----|/|-----|/|-----|/|-----|/|-----|/|-----|/|------(U)---|
So the OTL will set the tag, and if any one of the subsequent tags are set it will retain it's set status. If none of them are set, the OTU unlatches the tag at the end of the rung, and the rest of the program is none the wiser.
Of course, you have to be careful of interrupts and asynchronous things that might access it at the wrong time, but if you're careful about how you do it, it's a whole lot easier to see at a glance which area your alarm is in, for example, than having to scroll up and down past them all. And as the only instances of the OTL and OTU are on the same rung, it's nice and clear and easy to troubleshoot.
Ron Beaufort
Lifetime Supporting Member
well, as far as controlling machinery goes ...
suppose that you have something turned ON and running - and then the power to the system fails ... when the power finally comes back up again, how do you want the machine to react? ...
(A) stay OFF until the operator restarts it on purpose ... or ...
(B) come back ON again without any operator intervention ...
once you've made that decision, THEN (and only then) is it time to start deciding whether a "seal-in" or a "latch" construction would be more appropriate ...
you might want to take a look at the figure attached to the following post - and read the text that explains it ...
http://www.plctalk.net/qanda/showpost.php?p=70681&postcount=15
.
suppose that you have something turned ON and running - and then the power to the system fails ... when the power finally comes back up again, how do you want the machine to react? ...
(A) stay OFF until the operator restarts it on purpose ... or ...
(B) come back ON again without any operator intervention ...
once you've made that decision, THEN (and only then) is it time to start deciding whether a "seal-in" or a "latch" construction would be more appropriate ...
you might want to take a look at the figure attached to the following post - and read the text that explains it ...
http://www.plctalk.net/qanda/showpost.php?p=70681&postcount=15
.
Last edited:
If we are talking about a machine, a PLC shall NEVER be able to restart anything by itself, regardless of how you program it. That is a serious system design failure. You'll get prosecuted for that kind of design if something happens.
That is why we have safety relays and safety PLCs nowadays.
As a programmer we are in the same situation after power goes off/on again as we are after an emergency stop.
If we have a safety relay it will also be in the same situation, requiring manual reset to be able to issue a start again. So just to be clear a safety relay after cycling the power is always in it's "stop everything" mode.
When you as a programmer see that the safety relay has been activated, you have to reset all outputs, registers or whatever you use to put the machine in the same state in your program, as it is in real life - at stand still.
Last edited:
Ron Beaufort
Lifetime Supporting Member
am I misreading something here? ...
Every time I hear this question, it reminds me of how I started learning to program.
At first, I started thinking of the program in terms of "what do want to happen when this input comes on"? Each input was probably used only a couple times, but the outputs needed to appear in many rungs, and many outputs were triggering off each input. I used a lot of latch/unlatch/set/reset instructions, so that I wouldn't have coils fighting each other. I typically wrote the code input by input as I figured out the machine, and I had no idea where things would end up when I started.
Later on, as I had more experience and I was able to understand the big picture of the function as I was programming. This allowed me to group the functions by the outputs instead. I could often program the logic where each output had one coil, and the inputs appeared in many places in the program.
My original method resulted in bad code because I was a bad programmer. I now write better code because I'm a better programmer. HOWEVER, I'm a better programmer because I've learned a lot, not because the 2nd method is inherently better than the first. What I learned is to code to my audience, and they prefer the one coil method.
Last edited:
trentg@felixconstruc
Member
I love these opinion topics... it really brings out the "I am better than you" people.
Bad Program/Programmer = Code does not work as end-user intended/needs. (FYI - All clients need a safe work environment so save safety first replies!)
About 5 years ago I went into a clients data center and on one of their most critical processes they were still using a Modicon 984 and Modsoft. The program was written with a bunch of jumps and was extremely hard to follow. But at the end of the day, it had literally been 10+ years since anyone had even looked at the code and the process had been chugging along for nearly 20 years. Regardless of how pretty I thought the code was written, it was good code... Met the clients needs, no bugs and no unforeseen expenses due to code or hardware.
There are very few right/wrongs in our industry. Make your process/code safe and make it meet the needs of your client. As you become more experienced you can go back to your WORKING code and change all your latches to the "good coding method". LMFAO!
Bad Program/Programmer = Code does not work as end-user intended/needs. (FYI - All clients need a safe work environment so save safety first replies!)
About 5 years ago I went into a clients data center and on one of their most critical processes they were still using a Modicon 984 and Modsoft. The program was written with a bunch of jumps and was extremely hard to follow. But at the end of the day, it had literally been 10+ years since anyone had even looked at the code and the process had been chugging along for nearly 20 years. Regardless of how pretty I thought the code was written, it was good code... Met the clients needs, no bugs and no unforeseen expenses due to code or hardware.
There are very few right/wrongs in our industry. Make your process/code safe and make it meet the needs of your client. As you become more experienced you can go back to your WORKING code and change all your latches to the "good coding method". LMFAO!
Maybe...I'll try to be a little more clear.
There are no safety issues with using latch/unlatch. Any motor or object that is a safety concern (can cause harm), are not allowed to be controlled by a PLC alone. So if the power goes off and then on, it doesn't matter if the outputs on the PLC are on or off.
The same thing happens when you press the emergency stop. It doesn't matter what the PLC is doing, if PLC outputs are on or off or in between. There has to be something else that is cutting the power to the motor, air supply or whatever it is.
This is machine safety 101.
In it's simplest form you can use a safety relay and you shutoff 24V to all outputs with it. A safety relay also needs a manual reset button hooked up to it. If you press the E-stop you have no 24V anymore and everything stops. To restart you need to pull out the E-stop and push the reset button.
If you cycle the power on the machine you have the same situation. The safety relay cuts all 24V and you have to push the reset button to get the power back. Then you are allowed to start machine again.
The safety relay is also connected to an input on the PLC so you know when it has been activated. You use that input to stop everything in the program, just like an additional stop button. So every rung that sets the output or latches it off is activated when the safety relay is activated.
For example
Code:
start_no stop_nc [COLOR=Red] safety_nc [/COLOR] output
+---| |---+---| |-------[COLOR=Red]| |[/COLOR]-------------( )---
| |
| output |
+---| |---+
Code:
start_no output
+---| |---+------------------------------(L)---
stop_nc output
+---|/|---+------------------------------(U)---
| |
|[COLOR=Red]safety_nc[/COLOR]|
+---[COLOR=Red]|/|[/COLOR]---+On larger machines you often have a bunch of stuff going on with guards, light curtains, different safety zones and you use a safety PLC which is a PLC that can do both regular PLC stuff as well as doing the job of a whole case of safety relays. The principles are the same though.
.
Last edited:
Similar Topics
Hello All,
Can someone see what I did wrong here.
My "PA" bit never seems to get energized despite hitting "SOFTKEY7" many times
Hi guys, I have a question regarding studio 5000 with processor 1769-L33ER V33.011 and Factorytalk View SE V12.
I have an home-made pop-up...
I'm troubleshooting a machine for a customer right now, and the output that is not working needs this bit to go high to activate the coil. But the...
I am trying to convert an old PLC5 program. I have several instances in the unlatch instruction where they give a B file on top of the unlatch...
Hi everyone. First time poster here. I am very new to PLC programming (my programming background is more in computers). I have a question with...