DeltaV modbad Alarm

Sometimes discrete on/off valve show modbad alarm anyone experience this before? please advise. The discrete on off valve use PCSD Discrete Valve modules with force SP & Interlock V5.2-control module (GR_V11_IL52) I am using deltaV 11.3 with asi card and P&F module for DO and DI connection to the On/off valve.

7 Replies

  • The MODBAD alarm word is associated with the MODULE_ALM alarm.  MODULE_ALM can monitor a variety of different errors and statuses.  When a monitored condition goes bad, the BAD_ACTIVE parameter becomes true and MODULE_ALM is activated.  Check the MERROR_MASK and MSTATUS_MASK module parameter properties.  This will tell you which errors will trigger a BAD_ACTIVE and help you diagnose.  The MERROR parameter will tell you which error condition is active, MSTATUS for active status error.  If the default alarm message is still "Module Error: %P1 or Module Status %P2", then the alarm message will display this same information.

  • In reply to Ben Bishop:

    I have found the MERROR_MASK and MSTATUS_MASK and both online value is None-Zero when this modbad alarm arise,

    In the MERROR_MASK properties there are 5 values that is being selected IO input error, IO output error, input transient error, output transient error and FB bad active, while for MSTATUS _MASK there are 2 values being selected out of service and unresolved references.

    In the PHV for the same valve other than modbad alarm  I also get IO input error and IO output error, but what confusing me was I have re check valve open and close and its working properly both command and indication are delivered to and from the valve and deltaV (no issue) moreover after this modbad arise and if I acknowledge the alarm it will disappear but next time it would appear again-and usually several valves goes modbad at the same time, one of my colleague told me that may be I had noise or unproper grounding issue, please advise further.. thank you

  • What does the BLOCK_ERR parameter contain? This parameter will reflect the associated problem causing your module error.
     
    From: Andi nurcahyo [mailto:bounce-Andi_nurcahyo@community.emerson.com]
    Sent: Thursday, December 13, 2012 5:27 AM
    To: DeltaV@community.emerson.com
    Subject: RE: [EE365 DeltaV Track] DeltaV modbad Alarm
     

    I have found the MERROR_MASK and MSTATUS_MASK and both online value is None-Zero when this modbad alarm arise,

    In the MERROR_MASK properties there are 5 values that is being selected IO input error, IO output error, input transient error, output transient error and FB bad active, while for MSTATUS _MASK there are 2 values being selected out of service and unresolved references.

    In the PHV for the same valve other than modbad alarm  I also get IO input error and IO output error, but what confusing me was I have re check valve open and close and its working properly both command and indication are delivered to and from the valve and deltaV (no issue) moreover after this modbad arise and if I acknowledge the alarm it will disappear but next time it would appear again-and usually several valves goes modbad at the same time, one of my colleague told me that may be I had noise or unproper grounding issue, please advise further.. thank you

  • In reply to AdrianOffield:

    In the block error 2 values selected >> readback failed and input failure/bad PV

  • was there ever a solution to this? I have groups of modules all firing off MODBAD alarms for only a second or less, sometimes 50 times in 24hr period
    all with Module error:64 but can't find any links to this error code and the alarm is not live for long enough.
  • In reply to Lee W.:

    Lee -
    For a reference, I'd point you to the "Module-Level Parameters" section in Books Online. In your case, Module Error (the module's MERROR parameter) is indicating an Output Transfer Failure (this is bit 6 in the MERROR word, and 2**6 = 64). I'd suggest taking a look at external reference write parameters in your configuration and see if you might have a fleeting comms problem, casting mismatch, or some other failure in those external references.
  • In reply to Ray Emerson:

    Thx Ray, this makes sense, it all relates to a communication error we have with one of our controllers, loose wiring, Emerson are replacing said controller in our summer shutdown.