Simple Ladder Logic Problem

[MrSHME]

It would be awesome if someone could help me out with this problem. We can only use basic XIC XIO OTE OTL and OTU instructions. I'm not sure on how to make the horn silent when there is still an alarm active when the silent button is momentary.

" [FONT=&quot]A HIGH PRESSURE fault (N.O. pressure switch) causes a red LIGHT and a HORN to both come on. If the pressure goes back to normal the LIGHT will stay on and the HORN will shut off. When there is an alarm and the SILENCE button (N.O. momentary) is depressed the HORN will shut off. The LIGHT will stay on. The HORN will stay off(locked out)when the silence is released. If the SILENCE is pressed when there is no alarm the HORN will not be locked out. If the HORN is locked out and the pressure goes back to normal the lockout must be automatically reset so that a further alarm will cause the HORN to come on again. Only when the RESET button (N.O. momentary) is depressed and there is no alarm will the LIGHT go off. This system must be fool proof, in that if someone holds down the RESET switch and there is still an alarm the LIGHT will stay on.[/FONT]
"

 

[LadderLogic]

It is customary on this forum to ask a student poster to show some work he has done before suggesting advice. Don't take this the wrong way, please: we all have climbed the infamous learning curve in our time.

"The root of learning is bitter yet its fruits are sweet".

 

[osmanmom]

fill the blanks

 

[OkiePC]

Read the problem again, and think about it from the perspective of each output device.

Write the problem down again, and this time by each device. Write down the condition, in your own words, under which the light comes on.

Do the same for the horn.

You will also have a statement or two for a "Silenced" bit or something like that. You can make mention of it in your other statements about the horn and the light, but define it (what turns it on and off) in a statement by itself.

The result will much more closely resemble ladder logic statements, and the goal is to get all the stuff that drives the light onto one rung or into one "human readable statement" and all the stuff that drives the horn into another.

Then going to ladder logic is much simpler when you have things organized by output devices.

 

[Lancie1]

MrSHME,

Here are a list of your total PLC INPUTs:
High-Pressure Switch
Silence Pushbutton
Reset Pushbutton

Here are a list of your total PLC OUTPUTs:
Alarm Red Light
Alarm Horn
Alarm Horn Lock-Out Relay

There are no buzzer, no buzzer bit, no silence bit, no My buzzer, no My Red Light. Use the terms and information given in your instructions, so you get started in the right direction. Add rung comments to each rung that explain what it DOES.

Here is an outline of your final PLC program:

 

|   HIGH PRESSURE SW.                ALARM RED LIGHT |

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

|  |                          |                      |

|  |???? ??? ????  ????? ??   |                      |

|  +-----| |---------|/|------+                      |

|                                                    |

|   HIGH PRESSURE SW.  ???? ????????     ALARM HORN  |

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

|                                                    |

|   HIGH PRESSURE SW.  SILENCE PB.    HORN LOCK-OUT  |

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

|                    |               |               |

|                    | ???? ???????? |               |

|                    +-------|/|-----+               |

|--------------------------------------------(END)---|

 

[cphelps79]

Start from Square 1

IMHO, you should not be using Latches and Unlatches in this logic. You should be using seal-in circuits. Using Seal-in circuits will help you better understand the logic and how it works. I would also do this in Relay logic in lieu of PLC Logic. Call me old school but I prefer knowing that my logic is both electrically and logically sound. P.S. Seal in circuit requires the output of a circuit to hold itself in until it is broken by a NC contact.

 

[Lancie1]

IMHO, you should not be using Latches and Unlatches in this logic.

I agree, and I did not use any latches.

There is no real advantage to using actual relay logic, where you have to figure out if you have enough contacts on each switch and each relay, and the contact number for each relay contact. No one is going to build this circuit using relays.

 

[cphelps79]

Lancie,

My apologizes sir I was not intending for the comment to towards your post just to the original poster, who in his example used (L) and (U). Also I have designed and built many of these over the past 13 years. I could not agree with you more, absolutely can't believe there are people who still want it done this way.

 

[daba]

Lancie,

My apologizes sir I was not intending for the comment to towards your post just to the original poster, who in his example used (L) and (U). Also I have designed and built many of these over the past 13 years. I could not agree with you more, absolutely can't believe there are people who still want it done this way.

I feel I must reply in the opposite..

A PLC must come back on in the state it went off... Seal-in circuits don't do that in the Allen-Bradley world. It is up to the user's logic to decide what is retentive and what isn't, not what the power supply or mode-change switch does.

Of course I am not saying that real-world physical outputs should come back on until the logic decides they should be off, and I would definitely not use (L) or (U) on physical outputs. But the internal "memories" of the control logic should not be influenced by a power-cycle, period.

In the OP's scenario, if the "Horn" is latched with a seal-in from a momentary conditional, then cycling the power will silence the horn. That is definitely not what the control system should do. The circumstance says it should be sounding, because it has not been acknowledged by the operator, and so it should sound again after a power-cycle.

There is a place for both seal-in, and latched circuits, and if used correctly, and in the right context, everything is fine.

 

[Lancie1]

In the OP's scenario, if the "Horn" is latched with a seal-in from a momentary conditional, then cycling the power will silence the horn.

Great, that is what I would want. Having an alarm horn blaring after a power outage would just compound the problems, when every plant operator will be up to his eyeballs in aligators. There are big differences between the theoretical world and the real, hard-*** world. Believe me, most plant operators know how to handle a blaring horn that gives them headaches on top of the real headaches.

The horn should not come back on, because all the moving equipment that caused the alarm should now be off. If the horn does come back on due to a previous unacknowledged alarm, it is always a mistake and an aggravation. The operator does NOT want to know about an unacknowledged alarm that happened before the power outage. He will have his hands full trying to restart the plant, and having a pesky left-over alarm is not what he needs at the moment.

I have been present during a process upset when an operator grabbed a sledge hammer and knocked the loud blaring alarm horn off the wall. Then there was complete silence for a long time, everyone afraid to speak in case he might get a sledge hammer against his head.

From then on, I tried to reduce the time that the alarm horn was on. I always used a cycling horn, ON 0.6 seconds, OFF 1 second. Operators loved that type of alarm horn. If the power went off, the horn was definitley NOT coming back ON due to an old, now-irrelevent, alarm condition.

 

[daba]

Great, that is what I would want. Having an alarm horn blaring after a power outage would just compound the problems, when every plant operator will be up to his eyeballs in aligators. There are big differences between the theoretical world and the real, hard-*** world. Believe me, most plant operators know how to handle a blaring horn that gives them headaches on top of the real headaches.

The horn should not come back on......

You have actually reinforced what I said, Lancie1 - it is up to the programmer which bits should be remembered, not "the system". If the horn coming back on is an issue, then the program can be changed to stop it, I still maintain that the system shouldn't kill it automatically.

And anyway, what's the problem with someone pressing the "Mute" or "Acknowledge" button.....

I used the horn by example only, but the same principle could be applied to any status bit that is set in the control program. It's the same scenario as the now-infamous "toggle" situation, many of the published solutions do not retain the toggled-on state through a power-cycle or mode-change. I always use a toggle circuit that does, and any I want reset on power-on I do so, in my code.

I, the programmer, decide, and that's the way it should be.

 

[Lancie1]

I, the programmer, decide, and that's the way it should be.

We will have to agree that we disagree about this. I was trained to think about ways to allow the customer or user to decide, and I, the lowly programmer, only add the logic to allow the user to decide. If you have spent many long days in control rooms, you know that the user does not want the alarm horns on any more than absolutely necessary. Making the user perform an alarm acknowledge on power-up for a long-dead-and-forgotten alarm is adding poision to a festering wound.

 

[daba]

We will have to agree that we disagree about this. I was trained to think about ways to allow the customer or user to decide, and I, the lowly programmer, only add the logic to allow the user to decide. If you have spent many long days in control rooms, you know that the user does not want the alarm horns on any more than absolutely necessary. Making the user perform an alarm acknowledge on power-up for a long-dead-and-forgotten alarm is adding poision to a festering wound.

We are NOT only discussing alarm horns. I made that comment thinking it would strengthen my case for a PLC coming back ON, in the same state it went OFF. You took it upon yourself to argue a case about alarm horns in particular, and I was trying to make a general statement about the control system should not "lose" any information, state, or data, just because it had power-cycled. That is fundamental to me.

But you want to make a case based on horns, so I still maintain that if the control system is supposed to sound a horn, which the operators are comfortable dealing with, day in, day out, and that horn is there for a reason. They have to acknowledge it, it is their job to do so, and act on it. It is not always about "moving equipment", as you stated.

So what if a power-cycle occurred, the horn will come back on, and they will know instinctively how to deal with it, they will silence it first, then check the alarm list to see what caused it. It was the alarm horn that directed them into performing the actions they have done 24/7 for the lifetime of the control system, that is their job, and it is the job of the alarm horn to alert them to perform theirs.

And you said "Making the user perform an alarm acknowledge on power-up for a long-dead-and-forgotten alarm is adding poision to a festering wound" - NO that is absolutely NOT the case, the alarm is current, has not been acknowledged, so there is no guarantee that the operator has seen it, to act on it accordingly.

I see absolutely NO distinction between the importance of an alarm horn before, or after, a power outage.... That "event" has absolutely NOTHING to do with the control system, its design, its functionality, and must never change the information given to the people in charge of the operation.

An alarm is an alarm, period. You have made a case that an alarm can be acknowledged by cycling power on a processor, and that is just plain WRONG. I will not make any further comment on this issue.

 

[Lancie1]

Your logic will work, MrSHME. You have one extra part that is not needed. You can remove the HP contact below the Reset pushbutton. That does nothing for you, and your circuit will work without that extra contact.

 

[MrSHME]

Your logic will work, MrSHME. You have one extra part that is not needed. You can remove the HP contact below the Reset pushbutton. That does nothing for you, and your circuit will work without that extra contact.

I believe because of the last part of the question I need it in there to keep on the light if someone goes and holds down the reset button.