LEQ instruction

It seems as I'm missing something basic here. I have a LEQ controlling our plant air pressure. Air pressure is at or below 90, it turns on an alarm bit which sets off our horn etc. When it goes below, the alarm bit blinks. the value blinks in our controller tags window as well. I can't find anything that is turning it off. If the A is less than or equal to B, the value of the LEQ instruction goes True(1) and the output is energized.. correct? Even when I put in a latch instruction it blinks.. And i hadn't even created the unlatch instruction anywhere in the program yet. I cannot understand why it is turning on and off when it should be true. I'm sure it's something simple and embarrassing, but someone please tell me what I am missing.

Thank you in advance

Many alarm inputs only turn on an alarm bit. That alarm bit then starts a flashing or blinking Output, using one of the S:4 bits (for RSLogix), or a timer. Do a search to see if your alarm bit triggers a blinking output somewhere else in the program.

Your first job is to find the actual Output that is causing the blinking alarm light. Most likely it is not the alarm bit you are turning on with the LEQ instruction.

Even when I put in a latch instruction it blinks..

Click to expand...

Please don't latch on an alarm bit. Plant Operators have to put up with too much noise already. Don't add to their problems. Even better, use a blinking output to power your horn also - will do the same job with much less stress. They will thank you many times.

If you can't find the bit then make sure that you are not writing to the bit word anywhere. e.g., if the bit is B3:7/5 then make sure that B3:7 is also not being written to somewhere, or if its O:2/5 then make sure O:2 is not being written to.

I agree with Lancie on horns. A horn should be like someone who whistles in a crowded room. When everyone hears a whistle they look up to see who whistled. They all see someone waving, but only the one person they are actually waving to pays it any further attention. Everyone else goes back to what they were doing. The alarm horn is to get attention. Once attention is obtained, it is no longer necessary for most kinds of events. Reserve the continuous horn for serious hazards.

I apologize for my first post. I wrote that post at the end of my day, right before I clocked out, when I was frustrated. I realize more information would have been helpful in helping me diagnose this issue.

First, this is written in RS logix 5000. Second, I agree that it seems like something is overwriting the output value. I also appreciate you guys looking out for our operators.. As far as our annunciator goes, I also agree about how an alarm should work. This alarm should work like all the other alarms I've installed in our boiler. The alarm will trigger and flash the light and the annunciator until the alarm is acknowledged etc. The latch instruction was strictly to see if the bit would trigger and hold after the LEQ went true. I had no intention of using it in the final program. I still don't understand what could be changing the OTE status in that rung.. A is staying below B by a good margin, yet the OTE instruction is flashing.. but Not at any specific rate that I can tell. Definitely not at the rate of any of our flashing logic. I can also see this bit changing status in the controller tag registry. I realize you don't always see the bit's response due to lag time between processor, display, etc, but I don't believe that to be the case here.

There are quite a few alarms, and each one has a couple of user created tags. In this case the LEQ instruction triggers an "Air_Below_70_Alarm". The only place this tag exists, after using "find All", is the OTE after the LEQ instruction, and and XIC instruction, which along with another alarm condition, triggers another user created tag (C42_Control_Air_Pressure_Alarm), that sets off the alarm sequence.

Thank you for the responses so far. Please let me know if I can provide any more information that would help resolving the issue of the bit not staying true.

try doing a Cross Reference of the address in question ... (NOT a Find All) ...

see if anything pops up with a "Y" (for "yes") in the Destructive column ... if it does, then pay special attention to that item ...

Thank you Ron. I knew it would be something easy. It referenced some "structured Text" which to be honest, I have never had to mess with. Looks like it's time to read up on it. It looks like conditional logic that is written out instead of in ladder logic form? Anyhow, was able to create completely different tags and get everything to work correctly. Thanks again for the response. I'm off to go google myself some more knowledge.

Ron's suggestion of the Cross Reference was going to be my suggestion also, but....if an HMI is writing directly to that tag the cross reference won't find it. If the Cross Reference does not unearth the problem then try putting another OTE with an internal bool tag in parallel around the blinking output to see if it has the same problem.

One other thing.....double-check the tag name of your output. I had a guy the other day that was trying to turn on Local:5:I.Data.2. Slot 5 is indeed an output module but he was trying to turn on the input echo bit. It resulted in a flashing output instruction but no physical output.

OG

EDIT: Well I guess I took too long typing!

here's a quick link to an overview in Allen-Bradley's library ...

http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm007_-en-p.pdf

anticipating your next question:

is there any button that I can click to turn this stuff into regular old-fashioned plain vanilla Ladder Logic programming? ...

Click to expand...

only in your dreams ...

EDIT: Well I guess I took too long typing!

Click to expand...

rest assured that the extra information will help someone else in the future ...

the error of using an "input" address from an "output" module pops up at least once or twice in every class ...

Haha, thanks for the link Ron. I didn't write this program for our boiler, I'm just responsible for maintaining it. I'm assuming it's there for a reason, and I would rather learn how to understand why it is the way it is, rather than try to dumb it down to my current knowledge level.

Thanks again for everyone's input. The knowledge on this site is invaluable.

Yeah, it's getting overwritten somewhere. You could save it to a .L5K and post it. I promise that I will not use your boiler code in our robots. Honest!

Or better yet, save it to an .L5K file and use Notepad++ to find all occurrences of that bit yourself. And be sure to drop the bit from the right end of the tag so NP++ can find the occurrences of the root tag (e.g. "FindAllUses.00" would be shortened to "FindAllUses" in your search box to make sure that you get everything).

As for your latch, I got what you were trying to do.

As for annoying operators, I wouldn't worry too much about it, they have a way of dealing with aggravating equipment.