Project

General

Profile

Feature #24980

Expand alarm reporting to indicate reading errors.

Added by Richard Neswold about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
ACSys/FE Framework
Target version:
-
Start date:
09/17/2020
Due date:
% Done:

0%

Estimated time:
Duration:

Description

When doing the alarm scan, if reading the device results in an error, an alarm is posted but doesn't indicate it was due to an error. This issue proposes that extra information be provided.

Bits 11 and 12 in the alarm block header currently indicate whether the alarm is good or in alarm high or low. Instead, we propose that the two bit form an enumeration field where:

Value Meaning
0 No alarm
1 In alarm: Low
2 In alarm: High
3 In alarm: Reading error

The ACNET status returned by the bad reading should also be placed in the ERP parameter field.


Related issues

Related to MOOC Framework - Feature #24981: Expand alarm reporting to indicate reading errors.New09/17/2020

History

#1 Updated by Richard Neswold about 1 month ago

  • Related to Feature #24981: Expand alarm reporting to indicate reading errors. added

#2 Updated by Dennis Nicklaus about 1 month ago

I briefly looked at what this would take and: Hah! The joke is on us. I think the alarm low/high flags are reversed for erlang analog alarms as to what they should be anyway. If their sense was correct, the code would already result in both the low and high flags being set during a readback error on processing an analog alarm.

Empirical proof that I'm wrong is happily accepted!
See:
https://cdcvs.fnal.gov/redmine/projects/acsys-fe/repository/revisions/master/entry/alarm_process.erl#L385



Also available in: Atom PDF