ONS in Parallel - Latch Output

[MTPLCUSER]

I am trying to use level switches to control a valve. If a level switch goes hi, it closes a valve. I am using ONS to keep the switches independent, so any switch will trigger the the valve. They want to then open the valve after a switch goes high, so I unlatch the output using a button on the HMI.

What I cant tell from my logic is after a switch goes high (and remains high), will the output be able to be unlatched?

And then if another switch goes high with the first one still high, will the output latch again?

Thanks for the help

 

[RVaughan]

.What I cant tell from my logic is after a switch goes high (and remains high), will the output be able to be unlatched?

And then if another switch goes high with the first one still high, will the output latch again?

Yes and yes.
Unerstand how the PLC scans -- solves and executes the logic, then starts over and does it again. DrBitBoy has written up the sequence numerous times in different threads.

When the conditions preceding an ONS are solved high (green color flowing in to the ONS), the ONS will put out a high signal (green) to the right on one single scan — the scan where the preceding logic was solved low (blue) and now it is solved high.
The preceding logic can stay high, but on the second scan the result flowing out of the ONS will be low, and will stay low until the preceding logic drops low and goes high again.

You used separate memory bits for the ONS (this is essential!) And each condition is in parallel. Each branch is solved independently so different switches going high at different times will each trigger a 'pulse' from the One Shots. It will work as you expect.

 

[MTPLCUSER]

Thanks!

 

[drbitboy]

I am not trying to add anything to what @RVaughan said, but I am curious why this approach was taken.

As noted, a rising edge on any of those alarm switches will trigger the valve to close.

But then an HMI button, i.e. operator action, will open the valve again, even if the alarm state is still active.

Alarm states are usually driven by either of two conditions:

• the alarm condition itself e.g. a high level switch
• the alarm state being active after the alarm condition is removed (e.g. the level drops) and the alarm has not yet been acknowledged by the operator

In this case, the operator HMI button does not acknowledge the alarm condition (the high level) so much as ignore it. I don't know your process, but I find that alarming .

One other aspect here is that I assume the driver for the alarm conditions, i.e. the level switches, have some hysteresis, so an alarm condition does not go from active (after a high level) to inactive until the level has dropped to some offset below the high level alarm point. One alternative, where that does not happen i.e. no hysteresis, would be a single greater-than level test of an analog level input signal; if there is any noise in that input signal, a one-shot could be firing repeatedly over several seconds or minutes as the level measurement (signal; not necessarily the level itself) oscillates above and below the knife-edge limit.

 

[Operaghost]

Another key point to this is understanding what the OTL is doing. Remember, it is a logical instruction, not an actual coil or contact out in the field. Understand that the tag tied to this instruction only has two states. It is either On ("1"), or it is Off ("0"). There isn't a third state that says it is latched, or a fourth state to say it is unlatched. It is either On or Off, that's it. In other words, there is no distinction between On and Latched On. They are both just a "1" as far as the tag itself is concerned.

Put simply, if the rung ahead of the OTL is true, then the OTL writes a "1" to its tag. Easy enough right? If the rung is true, the OTL goes high. That happens on each subsequent scan of the logic as long as the rung remains true. It rewrites a "1" to that tag over and over each scan of the program. When it is true, there is no difference between an OTE and an OTL. Although, in your case, it will not continuously rewrite a "1" due to the use of the ONS instructions. Which is probably a good thing to include here.

Where misunderstanding sometimes creeps in is what happens when the rung goes false. Literally, nothing happens. The OTL takes no action whatsoever. It no longer writes a "1" to that tag, but it also does not write a "0". It leaves the tag unchanged. So if the tag had a "1", it will remain as a "1". An OTE instruction writes a "0" when it is false. But the OTL leaves the tag unchanged. This is the "latched" effect that the OTL provides. In your example, if one of the other LS_Alarms went true, then it would rewrite a "1" to the tag that already had a "1". So, no impact. The tag will remain with a "1" until something writes a "0" to it.

And of course, drbitboy's comment about the HMI button is 100% valid. Hopefully the logic that includes the HMI button also specifies that it cannot clear (unlatch) the latched alarm if any of the alarm conditions still exist. Likewise, based on the logic that was posted, I would know that I have/had an alarm when the OTL is on, but I don't necessarily know which LS triggered the alarm. Ideally there is logic capturing that as well (if it is important to know which LS caused the alarm).

OG