Reset alarms invoke method

Revnus said:

... I want to use a button to reset all alarms coming from process CPU ...

Click to expand...

     LvlHi                 LvlAlarm
--+---] [-------------+------( )---
  |                   |
  |  LvlAlrm  LvlAck  |
  +---] [-------] [---+

James Mcquade said:

is the logic that latched the alarm bits off so they can be reset?
1. unlatch individual bits.
2. if they are grouped together, move 0 to word, copy zero's to word, OR if you can, do a file fill on the entire alarm bit words.
others with more knowledge on this may give an answer.
i hope this helps.
james

Click to expand...

drbitboy said:

how are the alarms coded in the CPU? Can you post a screenshot of the code? E.g. are they something like this?

Code:

     LvlHi                 LvlAlarm
--+---] [-------------+------( )---
  |                   |
  |  LvlAlrm  LvlAck  |
  +---] [-------] [---+

Click to expand...

cardosocea said:

Stupid question, but why do you need such a button? PlantPAX comes with everything pre-loaded for you. That's the whole point of a DCS, everything you'd reasonably need is prepared for you to a point.

Granted, PlantPAX is not a DCS at all, it's a framework to build something akin to a DCS, but if you build it as intended this shouldn't be an issue.

As for commands, Each alarm in alarm manager has an input associated with it. Say you have FT1234 as a PAI object. The tag FT1234.@Alarms or .@alarmset will provide you with a way to manipulate that alarm. This is how PlantPAX5 faceplates do it.

Click to expand...

Revnus said:

Since there is this way to acknowledge all, I thought that could be possible to make a single command to also reset them.

Click to expand...

• If the prerequisite condition (e.g. high temperature) for an alarm exists, then the alarm state is active
  • Even if that alarm is acknowledged before the prerequisite condition is removed, the alarm state remains active, because the prerequisite condition still exists.
• If that prerequisite condition, which previously existed, then ceases to exist (e.g. the operator sees the alarm, investigates and finds a cooling fan not running; the fan is fixed, put back into service and turns on; the temperature drops below the alarm limit), then the alarm state remains active
  • The point of remaining active is that the operator might otherwise miss an alarm's prerequisite condition of short duration, and it is preferred that they eventually be aware of it even if they do not see it while the condition exists.
• If the alarm is acknowledged after the prerequisite condition no longer exists, then the alarm state changes to inactive.

drbitboy said:

What is the difference between acknowledging and resetting an alarm?

Perhaps we should take a step back and ensure we start with a common definition of an alarm. Here is mine:

• If the prerequisite condition (e.g. high temperature) for an alarm exists, then the alarm state is active
  • Even if that alarm is acknowledged before the prerequisite condition is removed, the alarm state remains active, because the prerequisite condition still exists.
• If that prerequisite condition, which previously existed, then ceases to exist (e.g. the operator sees the alarm, investigates and finds a cooling fan not running; the fan is fixed, put back into service and turns on; the temperature drops below the alarm limit), then the alarm state remains active
  • The point of remaining active is that the operator might otherwise miss an alarm's prerequisite condition of short duration, and it is preferred that they eventually be aware of it even if they do not see it while the condition exists.
• If the alarm is acknowledged after the prerequisite condition no longer exists, then the alarm state changes to inactive.

That is what I think of as fairly typical definitions for an alarm's state and behavior.

I don't see a place for the term "reset" in that definition, other than as perhaps an alternate term for "acknowledge."

Is there another way to define "alarm?"

Click to expand...