Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Fri, 21 Oct 2005 10:03:40 -0400

On Oct 20, 2005, at 16:59 , Benjamin Franksen wrote:

One long-standing wish that's not included in your list is a

"graphics"

event (or trigger, whatever), so that e.g. a display manager has a
generic way to know when it has to re-draw (parts of) the widget if
display limits for an analog value or choice strings for a menu have
changed. A similar case is a change of alarm or drive limits.

OTOH, maybe these things can be done by just subscribing value changes
in certain (standard) properties of the value to be displayed.

Agreed, a 'graphics' update is not needed
if you can subscribe to display-related properties 'on change'.

Also no longer sure if 'alarm' is special.
An alarm handler which only cares about the severity
can subscribe to the severity property 'on change'.
If it also cares about the value, it can subscribe to
value & severity 'on change' of severity.

The current alh design is one way of separating the
determination and latching of alarms from the
masking, display, logging and acknowledgment.
The 'significant event server' is different, one could also
have only the determination on the IOC,
with an 'alarm handling' daemon doing the masking, logging,
and latching even while nobody is running a GUI,
and multiple GUIs that talk to that daemon, not the IOCs.

One requirement for that alarm handling daemon could be
to log the last value before an alarm (*),
then the alarm value,
then the next value after the alarm.
(*) means it has to get all the values,
no need for update only on alarm change.

-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System