• Not Answered

FAIL Alarm on DC Block - How to prevent on Interlocks External to the Motor (ie Other Motors)

Hello

I am continually staring at an abundance of Fail Alarms for motors and sadly very few of them have actually Failed but rather have been shutdown on an Interlock Condition and these cause a Flood of Alarms.

What I am interested in doing is adding an integer to our interlock composite so that I can identify interlocks that are External to the motor (from other motor conditions) vs interlocks that are directly associated with the motor (High Temps, High Amps, Speed Switch, Alignment Switches, etc). I would then like to intercept an External Interlock and stop it from Failing the motor (If the Motor Fails to Stop then I would consider that a motor failure but a successful shutdown do to an interlock, in my opinion, does not need to be considered a failure) and instead Stop the motor.

I have tried a simple Pulse interception (Blocking the Interlock & Permissive Inputs for a scan while I send a Stop command to the motor) but this does not seem to work as a Stopping Motor that gets an Interlock Shutdown will still flag a Fail Alarm.  I was hoping this would function as the operator would not be alarmed but would see the motor Stopped and No Permit for that motor - Aditionally the operator can look at the Interlock Details and see what stopped the motor.  Of course the Motor that did experience a direct Failure would still alarm and this is where the operator should be focussed.  
UPDATE- this did not work as CAS mode becomes disfunctional.  I will try feeding the Fail Alarm status to a conditional DI alarm and see if that works.

Anyone have any details on what actually constitutes a FAIL Alarm on a DC Block (I am assuming by my issue it is anything other then a Passive PV and an Interlock Shutdown) )and it there is any way to avoid it in this case other then to delay the Interlock Shutdown until the motor is fully stopped?

I realize this will open a can of worms regarding alarm philosophy but really in systems with cacading conveyors and the like - why do we need a bunch of motor failures when really only the first one tripped out?

I would also prefer to have conditional alarm strategies in the module or as close to the module as possible and sadly our DC Block does not offer Conditional Alarming (on the V13 system - not sure about newer varsions).

2 Replies

  • Failure on a DC would be anytime the FAIL parameter is non-zero which would be Confirm Timeout, Confirm Lost, Tripped or Shutdown/Interlock.

    Since you are on v13, you might want to look at the new function blocks DCC and EDC in this release. This would be some effort to change your configurations to this but you would get some other benefits from solving the alarm flood issues like Controller Loading Reduction, Interlocks to Active States, Fail Position Selection and more. The EDC doesn't cause Failure on Interlock like the DC, if you want an alarm you would do that at the source so there isn't floods.
  • In reply to Matt Stoner:

    Matt

    I was able to make a small composite that contains the logic required to do a conditional DI. This would include DISC_LIMIT, DISC_ENB, DISC_ENB_DELAY, DISC_DELAY_ON, and DISC_DELAY_OFF. This composite monitors the DC1 FAIL_ACTIVE status, executes right after the DC1 block, and applies the conditional alarming to an internal FAIL_ACTIVE status that I have made as the new reference for FAIL_ALM.
    I can now have my interlock composite, based on the individually configured internal/external interlock status, update the DISC_ENB parameter in the conditional composite and keep the alarm status from occurring when the interlock is external to the motor/valve.
    It would have been a better solution if this was done in-house via Emerson when the other condition alarms were implemented on the system but this appears to provide conditional alarming for the DC block at the moment.
    Since this is not required on every motor/valve in the system it is a simple fix on the motor/valves that do cascading trips.
    This composite, duplicated with a minor tweak, can also provide conditional alarming for Discrete modules that do not link to I/O much like the ALM block allows conditional alarming for Analogs without I/O.

    Regards
    Paul