Skip to content

valueAlarm rule should allow alarm messages to vary for different triggers #34

@Monarda

Description

@Monarda

There are multiple ways to do this.

  • Expand the NTScalar Normative Type to include strings such as valueAlarm.highAlarmMsg. These would then be settable through the normal methods, including put()s. The valueAlarm handler would simply need to check that the additional fields were present and act accordingly. The main disadvantage would be that these would not be true NTScalars (complying with the spec). The big advantage is that the alarm messages could be inspected externally and solid validation applied.
  • Add methods to the handler methods (put(), post(), open()) to intercept settings intended for the handlers and not for the Value. The handler method would be responsible for popping it off the dictionary so that it didn't blow up in the p4p Value. As an example, valueAlarm.highAlarmMsg would not have a field in the Type. Instead the handler methods would detect it, act on it, and then remove it. This would mean that NTScalar fields would be unmodified, but that a put() of the alarm message would probably not be possible (need to check), and it would not be possible to externally check the alarm messages.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions