Re: Alarm behaviour

[Timo Korhonen via Core-talk <core-talk at aps.anl.gov>]

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.