Emerson Exchange 365

DeltaV - Module Errors

I am having trouble finding the source of a MODBAD Alarm.

The operators tell me that a certain motor, when it is started, usually give a MODBAD alarm.  I haven't been there to witness it, but the Event Chronicler shows a MODBAD event, and gives the detail:  Module Error 264.

My suspicion is that the motor is drawing high starting current, and the CT is delivering over the 20mA to the AI CHARM.

If that is the case, what can I do in this situation?  The supervisor is concerned the operators will become numb to this alarm, perhaps leading to apathy for other alarms.

I know motors can draw 5 to 13 times their FLA on startup.   Is there a way to mask an input transient in a CHARM?

Thanks in advance.....

Ralph Kitts  

Ralph Kitts

• 10 Jun 2022 3:27 PM
• Cancel

4 Replies

• Lun.Raznik

  

  • 10 Jun 2022 3:56 PM

  Can you please check how MODBAD_ALM was configured? This is how it looks like for one of the templates.

  

  If you have the same configuration as above, kindly share contents of the CND block. If it is tied to BAD_ACTIVE, can you please share values of MERROR when the issue occurs?

  Below is an example of a module with bad input.

  

  • Cancel
• Matt Stoner

  

  • 10 Jun 2022 6:06 PM

  264 is IO Input Error and Function Block Bad Active (most likely the same input error).
  
  Have you checked what the current is when starting the motor? The charm has OVERRANGE_PCT and UNDERRANGE_PCT configuration that can be updated but you need to find out what actual current you are seeing first to know what to configure the values. The default configuration is 103 and -3 and the charm can read scale of 0 to 24 mA with a 30 mA current limit. I'm sure you are not at 30 mA limit or your Charm would become an expensive fuse...

  • Cancel
• Ralph Kitts

  

  • 10 Jun 2022 7:28 PM

  In reply to Matt Stoner:

  I have checked the values in Event Chronicle when the MODBAD occurs, and for a motor that normally runs at 33A, I've seen a spike a high as 273A! The CT has a switch labeled 200A (and two lower values.....currently set to 200), so maybe we're not spiking the CHARM past it's failure point. I will find out what it's upper-most value would output, then perhaps setting the OVERRANGE_PCT will be an option.

  Ralph Kitts  

  • Cancel
• Andre Dicaire

  

  • 10 Jun 2022 8:15 PM

  In reply to Ralph Kitts:

  Ralph, it looks like you have a custom alarm called MODALM. You haven't explained what triggers this alarm. Is it based on module/BAD_ACTIVE? This is set based on the MERROR_MASK and MSTATUS_MASK, so it depends on your configuration. Or is this based on a CND block expression? It would be useful to know how this alarm is configured.
  
  If you want to condition this alarm, and it is based on the BAD_ACTIVE, you will have to modify the configuration. Adding a CND block to read the BAD_ACTIVE would allow you to condition the alarm trip, by adding logic or enabling the delay timer.
  
  The INPUT ERROR is the result of a BAD status on an input function block in the module. An analog input will go BAD if the incoming signal exceeds the max signal which for CHARMS I believe is 22.5 mA. Normally, transmitters are saturated below this (usually configurable) Enabling NAMUR limits would allow the channel status to be marked BAD but only if the signal reached the limit and held for 6 seconds. If NAMUR is not enabled , then this is not your issue. If the spike goes beyond 22.5 this sets the status BAD immediately, and if NAMU is enabled, it stays BAD until it crosses below the NAMUR limit.
  
  The CHARM has an anti-aliasing filter to knock out 50/60Hz noise. If the transient spike last more than 50 ms, and it reaches the the corresponding signal voltage on the input, you could be setting the channel bad status. There is no way to filter that at the CHARM. If the CT is connected to a a transmitter, there may be some settings there to manage the 4-20 mA signal at the source. Assuming that is the issue.
  
  By using the CND block and its delay timer, you can modify this alarm to filter out a transient condition, once you know the duration. The BAD status would have to last x seconds before the Alarm tripped. You get to figure out what X should be. This would delay all Module Error transient conditions. Also, you need to include MStatus as it to may drive the BAD_ACTIVE and your CND/OUT would be replacing this as the Alarm trip.

  Andre Dicaire

  • Cancel