Beginner Question on Unlatch Behavior

crono141

Member
Join Date
Apr 2018
Location
South Carolina
Posts
14
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 regards to the functionality of the unlatch bit operator (OTU) on an AB Micrologix 1400.

I have a number of bits which are control bits used for HVAC control over modbus tcp. I have some logic that turns these on and off based on sensor data, but this logic is blocked during an emergency stop situation. But in an emergency stop situation, I want to set all of these bits to off. Based on reading various forum posts and the Micrologix instruction set, unlatch appears to be the operator I need to use.

Here's how my logic looks. I have a bit that is energized when E-stop is triggered. Behind that bit on a rung I have the unlatch operators for my HVAC control bits above.

My question is, if an estop is triggered and all these bits are set to off, if the estop is cleared (and the rung with the unlatch becomes inactive) will the other logic in the program that normally addresses these bits still be able to modify them, or will they remain in the off position? :confused:

Cool On Logic.jpg Estop Unlatch.jpg
 
In this case, the way the logic is written, it will completely depend on WHERE in the ladder file those unlatch instructions are. If they are AFTER the "turn on" runs, they will function that way, if they are BEFORE, they will have no effect.

It's not good to mix Coils (OTE) and Unlatch (OTU), it can cause problems and make troubleshooting difficult.

You're better off to but a "NOT ON" (XIO) bit [--|/|--] in line with the outputs, that way if the e-stop is pressed, they will turn off.

Once the E-Stop is cleared, the logic will work again as it is written. If you want to avoid that, you'll need to get into one shots (OSN/OSR) and perhaps Latch (OTL) and Unlatch (OTU).
 
Welcome to the forum. Post whatever questions you would like, there are many great people to help out here.

The unlatch output only works with the latch output. So on rung 5, instead of using OTE or the regular output operator, you need to use OTL or the latch operator. This way, those outputs will remain latched on, and will be on all the time, until you unlatch it.

Looks like right now, the only condition unlatching your outputs is the E-stop (O:0/0).

And yes, once the unlatch bit becomes inactive, you will be able to re-energize those outputs (so in this case, you need the timer to be done and the HVAC should not be in run mode, as seen on rung 5. These should go green again to turn those outputs back on).
 
So by adding the NOT ON bit operator to my regular Cool On logic, it will ensure that these bits remain off? Picture described will do what I need it to without using unlatch?

There's another wrench in this though. These bits are also exposed coils for modbus interaction from an outside system (customer side). I don't want these bits to be changed manually through modbus if there is an estop situation either.

Cool On Logic Estop.jpg
 
I'm unsure, what if the e-stop doesn't disable the timer? Wouldn't everything just pop back on again after the e-stop is pulled back out? I think with this new code, the e-stop is acting more like a pause rather than stop.
 
I wouldn't want to be having my (standard) PLC turning anything off in an E-Stop situation, your safety rated device should be doing this and just letting the PLC know what state it is in.
 
Welcome to the forum. Post whatever questions you would like, there are many great people to help out here.

The unlatch output only works with the latch output. So on rung 5, instead of using OTE or the regular output operator, you need to use OTL or the latch operator. This way, those outputs will remain latched on, and will be on all the time, until you unlatch it.

Looks like right now, the only condition unlatching your outputs is the E-stop (O:0/0).

And yes, once the unlatch bit becomes inactive, you will be able to re-energize those outputs (so in this case, you need the timer to be done and the HVAC should not be in run mode, as seen on rung 5. These should go green again to turn those outputs back on).

The highlighted statement is not correct. Although they are usually utilised "in pairs", it is not mandatory, and I have seen successful logic using rare mixes of the OTx instructions.

OTE, OTL, and OTU are just "bit" instructions that operate on Binary (BOOL) tags or data, and can be used whenever and wherever you want to achieve the desired logic, however strange it may look.

The prime thing to remember is that there isn't a single instruction that has any knowledge of what precedes it, or succeeds it, in the code. Each instruction as it is scanned knows only one thing, and that is the current true or false state of the rung at that time.

After each instruction is executed, it passes the rung state to the next instruction, unmodified if it is an "output" type instruction, or possibly made false by a "conditional" instruction (Note that once the "Rung Logic Continuity" is false, no instruction can make it true again).
 
The highlighted statement is not correct. Although they are usually utilised "in pairs", it is not mandatory, and I have seen successful logic using rare mixes of the OTx instructions.

OTE, OTL, and OTU are just "bit" instructions that operate on Binary (BOOL) tags or data, and can be used whenever and wherever you want to achieve the desired logic, however strange it may look.

The prime thing to remember is that there isn't a single instruction that has any knowledge of what precedes it, or succeeds it, in the code. Each instruction as it is scanned knows only one thing, and that is the current true or false state of the rung at that time.

After each instruction is executed, it passes the rung state to the next instruction, unmodified if it is an "output" type instruction, or possibly made false by a "conditional" instruction (Note that once the "Rung Logic Continuity" is false, no instruction can make it true again).

You are correct, you can use them independently in rare situation, but definitely not good practice to do so. You can always self-latch an OTE instruction, which works better in majority of situations in my experience, especially when turning motors on, or starting machines up. Due to this, there should never be a reason to use OTL or OTU on its own, when you can always self-latch the output.
 
So by adding the NOT ON bit operator to my regular Cool On logic, it will ensure that these bits remain off? Picture described will do what I need it to without using unlatch?

There's another wrench in this though. These bits are also exposed coils for modbus interaction from an outside system (customer side). I don't want these bits to be changed manually through modbus if there is an estop situation either.

You should not be using the same bit in an output instruction AND a modbus command as one will generally overwrite the other and you will get unpredictable erratic behaviour. You can try something like this below, it will also hold the system off once the e-stop is pressed, until a start command is issued.

2018-04-23_11-43-14.jpg
 
I wouldn't want to be having my (standard) PLC turning anything off in an E-Stop situation, your safety rated device should be doing this and just letting the PLC know what state it is in.


Agree and disagree.

Yes, the safety circuit should be the first line of defense; cutting power to motors and dumping air to solenoids.

But the PLC should also mirror those actions; breaking seals and stopping sequences. This way, when the e-stop circuit is restored, the system is still in its safe state, and doesn't just jump unexpectedly into action.

The e-stop reset button is not a RESTART button.
 
You are correct, you can use them independently in rare situation, but definitely not good practice to do so. You can always self-latch an OTE instruction, which works better in majority of situations in my experience, especially when turning motors on, or starting machines up. Due to this, there should never be a reason to use OTL or OTU on its own, when you can always self-latch the output.

There are plenty of good times to use a single OTL or OTU without its opposite:

OTL a bit in a bit-shift array, to flag an event that will be XIC'ed at a different address in the array.

OTU a bit that an HMI button has set. This is almost always preferable to having the HMI writing both the '1' and the '0' with OnDown and OnUp scripts.

OTU or OTL the sign bit in an integer, to force it to be positive or negative.

OTU bits from instructions, like .DN, .FD, .EN, .CTU, and so on.

One can even do "interesting" things like OTL the .DN bit of a TON to pause the clock and OTU to release the pause, instead of using an RTO instruction with the requite RES to clear the timer when the RTO rung conditions are false. Why? Because sometimes your hands get tied in the stupidest of ways.
 

Similar Topics

Hi all, Writng a FB in ST on Beckhoff TC for a pulser which turns on and off on a cycle, is paused by turning bControlInput to FALSE, but resumes...
Replies
2
Views
57
So I work for a company that doesn’t allow code change without going through a lot of people. Anyway my question is I have a sensor and when it...
Replies
12
Views
1,757
How do you code it to when you push a button attached to X001, it turns on Y001. Then, the next time you push the button attached to X001 it...
Replies
4
Views
1,600
Hi all, this is my first thread on here, completely new to plc. Have been given a 1769 L24ER QB1B to play with. I have a PA2 power supply and a...
Replies
3
Views
1,765
Hi all, I'm just starting out in the plc world. For school we had some introduction into codesys v3.5, basically we get given visualizations and...
Replies
9
Views
2,337
Back
Top Bottom