Hi Andrew and all,
Indeed, HYST for this record is set to 5 (coincidentally) , which would explain the issue. I did not suspect or check that because pvget reported it as zero.
Thanks, mystery solved!
I have understood ACKT and ACKS slightly differently though; the documentation says:
“The ACKS field contains the highest unacknowledged alarm severity.
The ACKT field specifies whether it is necessary to acknowledge transient alarms.”
Which matches with what I saw, in particular as ACKT had the value YES.
Now I understand also why I could not find any code using this facility.
The remaining question is why are the alarm-related fields (severity settings and HYST) are reported as zeros.
Timo
From: Andrew Johnson <anj at anl.gov>
Date: Friday, 16 June 2023 at 19:19
To: Timo Korhonen <Timo.Korhonen at ess.eu>, EPICS Core Talk <core-talk at aps.anl.gov>
Subject: Re: Alarm behaviour
Hi Timo,
On 6/16/23 10:26 AM, Timo Korhonen via Core-talk wrote:
Yesterday I was presented with a case that puzzles me. I thought I understand the behavior of alarms but it seems that I do not.
One (ai, “Soft Channel”) record in our system seems to be stuck in alarm state. See below for what CA and PVA report.
The record reports a MINOR alarm severity, even if the HIGH is set at 30 and the value is below (at 27.96).
The record gets its input from another record, so I thought that maybe the alarm is propagated from there, but the input link is set to NMS.
And, the origin record is not in an alarm state so that would be odd anyway.
I was able to replicate your symptoms in a stand-alone ai record by setting its HYST field to 5, then setting VAL to 31.23 and then 27.96. You don't mention whether HYST is set in your record, please check:
epics> dbpr anj:ai 3
ACKS: MAJOR ACKT: YES ADEL: 0 AFTC: 0
AFVL: 0 ALST: 27.96 AMSG: AOFF: 0
ASG : ASLO: 1 BKPT: 00 DESC:
DISA: 0 DISP: 0 DISS: NO_ALARM DISV: 1
DTYP: Soft Channel EGU : EGUF: 0 EGUL: 0
EOFF: 0 ESLO: 1 EVNT: FLNK: CONSTANT
HHSV: MAJOR HIGH: 30 HIHI: 50 HOPR: 0
HSV : MINOR HYST: 5 INIT: 0 INP : CONSTANT
LALM: 30 LBRK: 0 LCNT: 0 LINR: NO CONVERSION
LLSV: NO_ALARM LOLO: 0 LOPR: 0 LOW : 0
LSV : NO_ALARM MDEL: 0 MLST: 27.96 NAME: anj:ai
NAMSG: NSEV: NO_ALARM NSTA: NO_ALARM ORAW: 0
PACT: 0 PHAS: 0 PINI: NO PREC: 0
PRIO: LOW PROC: 0 PUTF: 0 ROFF: 0
RPRO: 0 RVAL: 0 SCAN: Passive SDIS: CONSTANT
SDLY: -1 SEVR: MINOR SIML: CONSTANT SIMM: NO
SIMS: NO_ALARM SIOL: CONSTANT SMOO: 0 SSCN: 65535
STAT: HIGH SVAL: 0 TIME: 2023-06-16 11:42:09.007677000
TPRO: 0 TSE : 0 TSEL: CONSTANT UDF : 0
UDFS: INVALID UTAG: 0 VAL : 27.96
The non-zero HYST causes the alarm state to be latched until VAL retreats from the alarm limit by more than HYST. My LALM field is 30, so to come out of the HIGH alarm state VAL has to go to below LALM-HYST=25.
If you don't want the hysteresis filtering behavior but would like some alarm filtering, the AFTC (alarm filter time constant) can be used to introduce time-based filtering.
(One interesting observation is that pvget -v lists severities as null, although they are set (for sure.) HSV is set to MINOR (1).
EPICS version in this case is 7.0.6.1, but I see this with 7.0.7 as well. I do not think that this is related to the alarm behavior though.)
I did notice that the pvget output from the above record shows the valueAlarm.hysteresis field as zero, and actually the type of that member doesn't look right either, an ai.HYST field is a double, not
a byte. I also have the same issue with the highWarningSeverity and highAlarmSeverity as you, mine both show as zero. Is this indicating bugs in pva2pva?
What is the purpose of the ACKS and ACKT fields (if the explanation would be too long to write here, I can try to figure out from the source code…)
I have read what the record documentation says, but it does not help me to understand how these are intended to be used.
(Just for curiosity, ACKS=INVALID and ACKT=YES for that record.)
ACKS and ACKT are dbCommon fields used to record the highest alarm severities that have been acknowledged by a client that supports global alarm acknowledgement (ACKT is for transient alarms, ACKS for current
alarms). The only alarm client I know of which supports global alarm acknowledgement is ALH, and I don't believe the pvAccess protocol supports alarm acknowledgement at all.
HTH,
- Andrew
--
Complexity is free, it's Simplicity that takes work.