Severity and value of non-defined limits

[b-spruck]

I have some problem with non-set limits for PVs which have only an upper (or lower) alarm limit:

• first it seems any limit (lolo, low, high, hihi) is initialized with 0
• second, it seems all limits are activated and card-coded severities are applied.

This result in the following bad behavior: I have some error fraction PV, which has a high limit of 0.1 but as the low limit is hard coded to zero even so NOT set, it will always be in error.

the epics softIOC will report non-set limits as "nan". it furthermore allows to set a different severity (thus disabling alarm), if no alarm severity is set, it will also return nan. I think that would be teh proper behaviour?

[xiaoqiangwang]

This is for common cases convenient, without the need of LLSV, LSV, HSV and HHSV fields.

Back to your problem, you can explicitly specify the low field to math.nan.

[b-spruck]

So, then why initialize them to 0.0 at all? https://github.com/b-spruck/pcaspy/blob/ca1bbef0718e36b2f5f363447228499fdbfaaf7e/pcaspy/driver.py#L374

[xiaoqiangwang]

0.0 or 0 is the default value for numeric fields. It is also true for IOC database. You can check the LOLO, HIHI fields of the record.

Look at the ao record for example,

It reports the actually alarm field values with non-zero severity configured. Otherwise NaN is returned. This is what is reported by caget with -d DBR_CTRL_DOUBLE or -d DBR_GR_DOUBLE options.

static long get_alarm_double(DBADDR *paddr, struct dbr_alDouble *pad)
{
    aoRecord    *prec=(aoRecord *)paddr->precord;

    if(dbGetFieldIndex(paddr) == indexof(VAL)){
        pad->upper_alarm_limit = prec->hhsv ? prec->hihi : epicsNAN;
        pad->upper_warning_limit = prec->hsv ? prec->high : epicsNAN;
        pad->lower_warning_limit = prec->lsv ? prec->low : epicsNAN;
        pad->lower_alarm_limit = prec->llsv ? prec->lolo : epicsNAN;
    } else recGblGetAlarmDouble(paddr,pad);
    return(0);
}

And later on in checkAlarms function, it only set alarms if severity is non-zero.

So the omission of configurable severity fields for numeric types in PCASpy does mean, if the alarm range is valid, the alarm will be checked on both boundaries.

I never discovered this because if I need to set an alarm range, I always set both boundaries.

[b-spruck]

I checked your suggested solution:

• luckily NaN is supported as input in the json file is use for configuring. -> worked
• Having nan set has the appropriate effect, the comparisons are done in a way that they act correctly if one value is NaN
• • this includes the checks for alarm-valid ... actually i wonder why you disable the alarm if LOW > HIGH, does it make sense?
• defaulting the limits to NaN at init also has the desired effect (but as stated by you, that is incompatible behaviour)

[xiaoqiangwang]

actually i wonder why you disable the alarm if LOW > HIGH, does it make sense?

I treated [low, high] and [lolo, hihi] two sets of ranges instead of individual limit points. That is why there is a check of low/lolo must be smaller than high/hihi.