Ken Roach
Lifetime Supporting Member + Moderator
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 ?
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 ?
Last edited: