Open b-spruck opened 9 months ago
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.
So, then why initialize them to 0.0 at all? https://github.com/b-spruck/pcaspy/blob/ca1bbef0718e36b2f5f363447228499fdbfaaf7e/pcaspy/driver.py#L374
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.
I checked your suggested solution:
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.
I have some problem with non-set limits for PVs which have only an upper (or lower) alarm limit:
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?