RE: CA monitoring weirdness for status/severity

[Mark Rivers <rivers@cars.uchicago.edu>]

Hi Colin,

I can reproduce your observations.  

I loaded the test record you listed into an "example" IOC.

This is the record after booting the IOC:

epics> dbpr chah:ao 10
ACKS: NO_ALARM      ACKT: YES           ADEL: 0             ALST: 0
AOFF: 0             ASG:                ASLO: 0             ASP: (nil)
BKPT: 00            DESC:               DISA: 0             DISP: 0
DISS: NO_ALARM      DISV: 1             DOL:CONSTANT        DPVT: (nil)
DRVH: 0             DRVL: 0             DSET: 0x7f34c51bf9a0
DTYP: Soft Channel  EGU:                EGUF: 0             EGUL: 0
EOFF: 0             ESLO: 1             EVNT:               FLNK:CONSTANT 0
HHSV: NO_ALARM      HIGH: 10            HIHI: 0             HOPR: 0
HSV: NO_ALARM       HYST: 0             INIT: 1
IVOA: Continue normally                 IVOV: 0             LALM: 0
LBRK: 0             LCNT: 0             LINR: NO CONVERSION LLSV: NO_ALARM
LOLO: 0             LOPR: 0             LOW: 0              LSET: 0x23c3040
LSV: NO_ALARM       MDEL: 0
MLIS: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
MLOK: 70 40 3c 02 00 00 00 00           MLST: 0             NAME: chah:ao
NSEV: NO_ALARM      NSTA: NO_ALARM      OIF: Full           OMOD: 0
OMSL: supervisory   ORAW: 0             ORBV: 0             OROC: 0
OUT:CONSTANT        OVAL: 0             PACT: 0             PBRK: (nil)
PHAS: 0             PINI: NO            PPN: (nil)          PPNR: (nil)
PREC: 0             PRIO: LOW           PROC: 0             PUTF: 0
PVAL: 0             RBV: 0              RDES: 0x236a220     ROFF: 0
RPRO: 0             RSET: 0x7f34c51be5a0                    RVAL: 0
SCAN: Passive       SDIS:CONSTANT       SEVR: INVALID       SIML:CONSTANT
SIMM: NO            SIMS: NO_ALARM      SIOL:CONSTANT       SPVT: (nil)
STAT: UDF           TIME: <undefined>   TPRO: 0             TSE: 0
TSEL:CONSTANT       UDF: 1              UDFS: INVALID       VAL: 0

I then monitor the HIGH field as you did an get the same result:

corvette:mca/iocBoot/iocAmptek>camonitor chah:ao.HIGH
chah:ao.HIGH                   <undefined> 10 UDF INVALID

I then put 11 to the HIGH field:
corvette:~>caput chah:ao.HIGH 11
Old : chah:ao.HIGH                   10
New : chah:ao.HIGH                   11

The camonitor program sees the new value:
chah:ao.HIGH                   <undefined> 11 UDF INVALID

I then do dbpr again at the IOC prompt:
epics> dbpr chah:ao 10
ACKS: NO_ALARM      ACKT: YES           ADEL: 0             ALST: 0
AOFF: 0             ASG:                ASLO: 0             ASP: (nil)
BKPT: 00            DESC:               DISA: 0             DISP: 0
DISS: NO_ALARM      DISV: 1             DOL:CONSTANT        DPVT: (nil)
DRVH: 0             DRVL: 0             DSET: 0x7f34c51bf9a0
DTYP: Soft Channel  EGU:                EGUF: 0             EGUL: 0
EOFF: 0             ESLO: 1             EVNT:               FLNK:CONSTANT 0
HHSV: NO_ALARM      HIGH: 11            HIHI: 0             HOPR: 0
HSV: NO_ALARM       HYST: 0             INIT: 0
IVOA: Continue normally                 IVOV: 0             LALM: 0
LBRK: 0             LCNT: 0             LINR: NO CONVERSION LLSV: NO_ALARM
LOLO: 0             LOPR: 0             LOW: 0              LSET: 0x23c3040
LSV: NO_ALARM       MDEL: 0
MLIS: 20 8e 03 b0 34 7f 00 00 20 8e 03 b0 34 7f 00 00 01 00 00 00
MLOK: 70 40 3c 02 00 00 00 00           MLST: 0             NAME: chah:ao
NSEV: NO_ALARM      NSTA: NO_ALARM      OIF: Full           OMOD: 0
OMSL: supervisory   ORAW: 0             ORBV: 0             OROC: 0
OUT:CONSTANT        OVAL: 0             PACT: 0             PBRK: (nil)
PHAS: 0             PINI: NO            PPN: (nil)          PPNR: (nil)
PREC: 0             PRIO: LOW           PROC: 0             PUTF: 0
PVAL: 0             RBV: 0              RDES: 0x236a220     ROFF: 0
RPRO: 0             RSET: 0x7f34c51be5a0                    RVAL: 0
SCAN: Passive       SDIS:CONSTANT       SEVR: NO_ALARM      SIML:CONSTANT
SIMM: NO            SIMS: NO_ALARM      SIOL:CONSTANT       SPVT: (nil)
STAT: NO_ALARM      TIME: 2017-08-07 08:12:32.703145990     TPRO: 0
TSE: 0              TSEL:CONSTANT       UDF: 0              UDFS: INVALID
VAL: 0

Note that UDF is now 0 and there is a valid timestamp.

This is exactly the expected behavior, because if you look at the record reference manual here:
https://wiki-ext.aps.anl.gov/epics/index.php/RRM_3-14_Analog_Output

You will see that the HIGH field has the PP attribute.  This means that writing to the HIGH field causes the record to  process.

However, the HIGH field does not have Rec Proc Monitor, so writing to the HIGH field does not cause monitor events to be posted.  So your original camonitor program does not get an event.  However, if you run camonitor again it connects to the channel and does get the new timestamp and status.

corvette:~>camonitor chah:ao.HIGH
chah:ao.HIGH                   2017-08-07 08:12:32.703146 11

Mark





-----Original Message-----
From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Hogben, Colin H
Sent: Monday, August 07, 2017 7:06 AM
To: Johnson, Andrew N.
Cc: tech-talk@aps.anl.gov
Subject: Re: CA monitoring weirdness for status/severity

Hi Andrew,
Thanks for your response.

 >> My first surprise is that the HIGH field is reported as undefined, 
when it clearly has the value I configured.
>
> There are 3 aspects to the camonitor output, and I think you're getting them confused.

I'm coming at this from the CA protocol perspective, and I'm aware that 
a CA_PROTO_EVENT_ADD response for TIME_DOUBLE contains status, severity 
and value (and also timestamp).

> The <undefined> part means the record's time stamp is as yet unset, because it hasn't been processed yet. Similarly the UDF INVALID part means the record is still in a UDF alarm state because the VAL field hasn't been set. Note that the time stamp and alarm status and severity are related to the record as a whole, not to the particular field you're monitoring.

 From the CA point of view, the .HIGH and .VAL are separate PVs; the 
protocol has no knowledge of what "record" or other concept may lie 
behind them.  Even if the CA server is using some common status & 
severity for multiple PVs, I'd still expect it to report the same status 
& severity to all clients of any given PV.

>>   chah:ao.HIGH                   <undefined> 11 UDF INVALID
>
> The value changes as you expect, but the record still hasn't processed or been given a value to define the VAL field, so it's still undefined and in UDF alarm.
>
>> However, if I start a new camonitor, I get
>>
>>   gen-pub-11:~ $ camonitor chah:ao.HIGH
>>   chah:ao.HIGH                   2017-08-07 10:30:55.033976 11
>
> Are you sure you didn't also do a put to the VAL field in between?

Yes, quite sure.  Did you try it?  BTW I forgot to say that this is with 
version 3.14.12.5 of base.

> The change to the metadata implies that someone did since they are now set so the record has been processed.

It looks to me as though writing to .HIGH causes the record to be processed.

I've just discovered that if I do a second write to .HIGH, the original 
camonitor sees status=0 severity=0 and a valid timestamp when it 
receives the new EVENT_ADD.  As though they're lagging behind by one update.

> If you're going to be writing your own CA client code, you may not want to actually monitor the metadata for channels which aren't a record's VAL field, and make sure you're monitoring the right CA Event type as well.

Hmm, if status & severity aren't reliable other than for .VAL, it looks 
like I may have to apply some heuristics based on the PV name (eugh!).

-- 
Colin Hogben
Professional Software/Control Engineer
CODAS & IT Department
United Kingdom Atomic Energy Authority
Culham Science Centre
Abingdon
Oxfordshire
OX14 3DB
Tel : 01235 464948
Web: www.gov.uk/ukaea