RE: IOC, QServ, and AMSG / alarm.message

[Ivan Finch - STFC UKRI via Tech-talk <tech-talk at aps.anl.gov>]

>> In addition, I have tried to put AMSG and NAMSG on a normal PV without input, output or forward link. alarm message is not being set from AMSG.
>
> As with SEVR and STAT fields, I don't think that AMSG/NAMSG should be set directly.
>
> As I think about it, it would make sense to have a soft device support which sets SEVR/STAT/AMSG to values read from a link.

I think I may not fully understand the intent of the AMSG/NAMSG record fields. 

A bit of context may make it clearer where we're coming from. We're transitioning from our old control system to a new PVAccess based EPICS control system. But as we're in transition we're running the two control systems in parallel and using our own custom Python software based on pvapy to bridge between them. We're currently still running our old alarm system which displays an alarm message, e.g. "SYNC - R6A Plant - DC Bias Water Pressure Low".

We can route alarms from EPICS PVs into the old control system's alarm display. At the start of our transition most of these EPICS alarms were generated by pvapy or p4p and we could set the Normative Type alarm.message field as desired. This message field is what we would show in the old control system alarm display. We've now begun deploying conventional EPICS IOCs using QServ to make the PVs available as PVAccess PVs. Unfortunately, the default alarm.message field is less informative! Our control room is currently seeing alarm messages like "INJ - VAC - STATE" (we prepend the "INJ - VAC - " in the bridging software).

Ideally, we'd like to simply set the alarm.message through the Record of the PV. We can already determine an alarm's severity and status from the obvious fields to determine if it's LOLO, HI, INVALID, COMM, etc. So, setting the AMSG to a constant string would suffice for most of our use cases. 

Hence our initial attempts to do something like my colleague Aqeel outlines:

record(calc, "EXAMPLE:COUNTER") {
    field(AMSG, "Bad Counter")
    field(VAL, "0")
    field(INPA, "5")
    field(CALC, "VAL = A? 0: VAL+1")
    field(HIGH, "5")
    field(HSV, "MAJOR")
    field(SCAN, "1 second")
}

It appears that this is not the intended behaviour of the AMSG field? As you note, it wouldn't generally make sense for SEVR or STAT to be settable, producing a PV that was locked to a particular alarm state. Hopefully, the discussion above shows that in some cases a constant (or near constant) AMSG may make sense.

Any advice on a way to control the alarm.message would be very helpful.

Thank you for any help you can give,

Ivan