Debounce Timers On Alarms

Working with a huge PLC 5 program that does not have much memory left in the processor and it has about 600 alarms in all and about 270 of them are for motor current monitoring but they are a nuisance because the trip all the time when there is nothing wrong.

The current monitoring settings are tight and they have to be but there is no debounce timer on any of the alarms so even if it high or low for just 1 scan then normal again the alarm goes off.

I want to put some debounce to each of these alarms but I am trying to avoid making 270 debounce timers because for one it will chew up all the available memory and we won't even make it half way.

I am looking for ideas on another way to do this without making 270 timers? I am not coming up with anything so I thought I would let the great minds here take a shot at it.

Where are the alarm signals generated from? By that I mean are there 270 inputs from starters/drives, or are the generated from within the program? I'm not 100% sure how to do it in PLC5, but you should be able to poll the location that the alarm signals are stored, use any high bit in that location to start a single timer. So for instance if your alarms are all in words in the B3.1-20, then any high bit in that range would trigger the timer.


Will.

Each alarm is a digital or analog input and some compares are done on the analogs to see how much current and if it's too low or too high the logic is true which turns on a OTE with a B:x/x address and when that B:x/x address has a 1 in the data table the Panel View 1400 program displays the corresponding alarm.

A single timer would solve the alarm horn problem and it sort of works that way now with the horn but the alarm still shows up on the HMI and the operators react and many of these alarms when tripped stop the line in which we want that to happen but it still needs debounce.

What make and model is the HMI?

Can you use a single timer?
So any of your alarm triggers will trigger the timer, then your HMI should only trigger when alarm + timer is present.

Drawback is that when timer has elapsed, it will no longer delay any alarms. But perhaps you could group the alarms and have several timers.

Then I would put the timer.dn bit in ahead of the OTE for the B:x/x that is read by the HMI. That way the HMI won't display the fault until the timer is done.


Will.

Tim,

You could try this.
Save a copy of the program under a dummy name (you will delete it later)
Open the program and delete all unused tags and memory.
Then go back and add memory words as needed.

Don't know if this will help, but it will tell you how much was deleted.

regards,
james

Im no PLC5 expert but couldnt he just use the real time clock to make sure the alarm has been on say for 5 seconds. alarm goes true, save seconds. then make sure it is true for 5 more seconds straight before setting the actual alarm/sd bit? im not sure how much memory this would actually save you though, as its a bunch of datapoints too now that i think of it. oh well just trying to think outside the box

James Mcquade said:

Tim,

You could try this.
Save a copy of the program under a dummy name (you will delete it later)
Open the program and delete all unused tags and memory.
Then go back and add memory words as needed.

Don't know if this will help, but it will tell you how much was deleted.

regards,
james

Click to expand...

+1 with caution. If the program uses indirect addressing, it's possible to botch things up by deleting addresses which are indexed in the program. This tool, last I used it could not identify if it was indirectly referenced. So you may get a false-positive and cause problems. I've done this on many PLC5 systems to free up memory and usually works well enough. However you have to be extremely aware of what you're about to delete.

EDIT: See this oldie but goodie, pay attention to post #7

Paully's5.0,

Good point, but when he compiled the program( just to check the memory and not to download into the plc) wouldn't it add the addresses back in? compiling the program would check all addresses.

james

Maybe you could bend the FBC instruction to your will. It seems made for things like this.

Two timers:
First timer: Each alarm occurrence starts the timer, but each additional occurrence within that time resets the timer.
Second timer max limit on first timer.

belay my last, I need to think on this for a min.

break it into pieces

step one: pack the 270 alarm bits into an array of 20 16 bit words. Yes, you only needed 17. Scratch that, pack alarm bits int an array of 50 16 bit words.

If array value changes, copy array value into array value last and set run tmr bit.

each change resets tmr. //reason is so that alarm doesn't go done when one input isn't on long enough and subsequent inputs are only on for a short time.

second tmr for the rare case where inputs cycled on and off at just the right times when there was an earthquake on the oil platform.