Emerson Exchange 365

• Not Answered

Allow instance value to be configured

I would like to make an alarm message generated by a module a bit more specific than the generic message they currently have. In the instance most fields are locked down apart from the Priority, Enabled, Inverted and Alarm Suppression Timeout fields. However, in the class standard module the "Allow instance value to be configured" box is checked in alarm properties. Why does this checkbox not give the all the options and how can I make all alarm parameters at instance level available for configuration?

Thanks,

David    

David Billington

• 24 Jun 2016 2:12 PM
• Cancel

3 Replies

• Matt Stoner

  

  • 24 Jun 2016 2:29 PM

  David,

  I'm not sure what DeltaV version you are using but in v12 an Alarm description was added that allows you to configure more specifically what the alarm is for (Instance configurable and can be bulk edited) and is shown on the alarm list. If this field is blank, the module description is used which is what pre-v12 systems do.

  Here is an example:

  

  Regards,

  Matt

  • Cancel
• David Billington

  

  • 27 Jun 2016 8:05 AM

  In reply to Matt Stoner:

  Hi Matt, we have v11.3.1 and I can see the Alarm Description field doesn't exist as you've shown above.
  
  If I wanted to select a different Alarm Type from the Alarm Preferences list it won't allow this at instance level because the Alarm type field is greyed out under the general tab and of course under Advanced tab, Alarm message and Message parameter 1 & 2 are also greyed out.
  
  Is there a way around this without breaking the link to the class standard?
  
  Thanks, David

  • Cancel
• Matt Stoner

  

  • 27 Jun 2016 3:51 PM

  In reply to David Billington:

  David,

  Alarm message customization could be done by pointing the alarm message parameter(s) to string parameter(s) so they could be configured and/or auto built based on running configuration.

  For example: you could have the first parameter be pointed to a string that was configurable at the instances and the second parameter could be generated from the PV and limits. You would have to be careful of this as this would be logic running in the controller so you would have to make sure that the values got updated properly to ensure the correct alarm message is getting generated when the alarm occurs.

  If you omit one of the values (PV or Limit) that are passed by default, it would be an easier change as you wouldn't have to autogenerate the message. The string parameter at the instance could be defaulted to "High Alarm Value Exceeded, Limit " and the alarm could have Message 1 pointed to this string and the Message 2 could be pointed to the limit. Then you could change at an Instance the parameter to say "High Flow Alarm Value Exceeded, Limit ". You would need to have X string parameters for X alarms using this method.

  Pretty sure that this is exactly why the Alarm Description was introduced so if you have any plans to upgrade to 12 or 13 in the near future, it would be alot better solution than the example above.

  Regards,

  • Cancel