> To re-enable alarms, you would have needed to have remembered the prior value to restore it (or just YOU’LL GET MAJOR AND LIKE IT)
Binary records (bi, bo) have a ZSV and OSV to associate optional alarm seventies with the two possible states.
You may have a record with
and there are no alarms at all because it’s fine for the device to be eiter off or on.
Or one with
field(ZNAM, “Cozy”)
field(ONAM, “Overheated”)
field(OSV, “MINOR”)
where the “1” state is somewhat bad, or
field(ZNAM, “Dead”)
field(ONAM, “Alive”)
field(ZSV, “MAJOR”)
where you consider the “0” state to be very bad.
With analog records (calc, calcout, ai, ao, …) there are 4 alarm thresholds, LOLO, LOW, HIGH, HIHI.
They are meant to go with alarm severities MAJOR, MINOR, MINOR, MAJOR.
Way back when that was designed, I guess there was the basic question: If LOW has the default value of 0, does that mean we consider any value <= 0 to be LOW (and MINOR), or does LOW==0 mean you didn’t configure
any LOW alarm threshold, you want that to be ignored?
In hindsight, a default of
LOLO=LOW=HIGH=HIHI=NaN (not a number) might have been a better idea, but support for NaN was added a little later, so we get defaults of zero for all alarm thresholds, and thus need another field for each threshold to indicate if it should be used. Well, you
might actually see the thresholds reported as NaN if the corresponding severity is NO_ALARM, but in any case we for now live with having both the 4 thresholds and the 4 associated
severity fields in analog records.
So you set LLSV=MAJOR, LSV=MINOR, HSV=MINOR, HHSV=MAJOR to enable them all, or just set some of them to enable only selected thresholds.
Yes, you could set HSV=MAJOR, HHSV=MINOR, and it might be fun for a while to re-order the thresholds that way, but don’t do that because eventually somebody will get mad at you.
-Kay
