Alarm Prevention on Powerup

[Ken Roach]

Hello, PLCTalk community !

I am working on a system that includes ControlLogix (v19) and PanelView Plus (FTView 5.10).

I have a very extensive alarming system (576 separate entries in the Alarm list), with a dozen DINT tags being read as bit triggers.

I am running into a specific problem when the controller cabinet, including both the PLC and the PanelView Plus, gets power cycled.

When the system comes back up, the input values that drive about a dozen of the Alarm triggers are still true, so the Alarm trigger bits are true. FactoryTalk View starts up, starts the Alarm subsystem, reads that the trigger bits are true.. and shows an entry in the Alarm Banner, in the Alarm List, and in the Alarm History.

The problem is that these are alarm conditions that existed before the power cycle, and when we look at the alarm history (or forensically at the Alarm Log file) we cannot tell the difference between an actual alarm event and a PanelView power cycle.

What I want is for the PanelView Plus to only show an Alarm when it has read that the value goes from False to True, while the alarm system is running.

While it may take a significant technical and bureaucratic effort to re-write the alarming code (the system is certified and locked down against changes), my approach is that I can use a watchdog timeout from the FTView ME application to suppress the alarm bits until they are re-triggered by a field event. I am concerned that this will distort the FTView Alarm History log, though, because it will then show "trigger value = 0" entries whenever it power cycles.

Has anyone else in the Forum addressed this issue in your own applications ? How did you do it ?

[Kidblue]

Hi,

May not work as you want it in this application Ken, but we always build in as standard a 'power-up' inhibit flag. Latch a bit using the first scan bit and start a timer to unlatch. We then inhibit certain Alarm categories if required on power-up...

But i'm guessing this is too simple for your application!

Rob

[Gil47]

I am not sure if this can be done on a panelview +, but could you make it that the alarms do not start from the startup tab, but are started from a macro, that way you could delay the alarm startup by say 10 seconds to make sure the tag database has had time to do a full update, and also monitor some form af watchdog, to and on the Plc, to make sure the Plc is in Run mode, for say 5 second, to ensure it is updating the tag database.

[Paullys50]

Maybe also consider a combination hardware/software approach. Will add cost, but maybe less painful then going through a large change-control effort with your alarms.

My suggestion is to add a backup UPS to the system which keeps power to the PLC and PanelView Plus for a minimum amount of time after a power loss, (the goal is to just capture and react to the power loss event). This way you can create an input indicating system power state and create an alarm based on it. So if a power loss occurs the PanelView Plus can log the event. As an action, you can place your code into a "safe state", and suppress all alarms. If power is restored before the UPS supply runs out, you can use the input state change to trigger the PV+ to log the event of power restoration, your system is ready to be restarted by operations and all alarm monitoring systems are re-activated as if you were starting up normally.

If the UPS power is drained due to the duration of the power loss, you can use the first-scan bit to trigger an alarm on the PV+ that the PLC restarted (granted you will get this alarm in both power outage situations and full download situations). But this method gives you time to clear down faults so they are not re-triggered at power-up.

This method should allow you to time-stamp the power loss experiences of your system, and you don't need to rely on macros/timing type of logic and you don't need to change any alarm code, just add a couple to account for power-loss so your change control bureaucracy should be minimal. Granted, hardware changes could have change control as well, but I would think that is an easier path than suggesting changing your alarm logic.

I prefer to use a local input card on the Logix Chassis for the power input to reside, no need to keep a switch and remoteIO rack powered up.

[Oakley]

I don't use FT but rather a competitive product.
But here is the philosophy ...

I keep a separate log of active alarms, and another for disabled alarms.

Upon startup, I run a script that will auto-acknowledge previously existing and disabled alarms. That way, any unacknowledged alarms are new.

[Ken Roach]

Thanks for the input, guys.

I was hoping there might be some sort of 'trigger on state change' function that I was missing in FTView ME.

When the new PanelView 5000 comes out they'll use FactoryTalk Alarms & Events, which is much more event-driven rather than status-driven.

Your comments have given me some additional ways of thinking about my alarming logic. Thanks !