Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Thu, 20 Oct 2005 22:59:28 +0200

On Thursday 20 October 2005 20:06, Kay-Uwe Kasemir wrote:
> On Oct 20, 2005, at 11:52 , Ralph Lange wrote:
> > The current plan (afaik) is to allow even more user-defined
> > "triggers". Or "filters". Or "events". (Everyone of us has
> > different interpretations of those terms...)
> >
> > Your last mentioned subscription won't be enough, as e.g. the Alarm
> > Hander is also interested in the value, but only wants updates when
> > the severity changes.
> >
> > The trigger/events and channels/fields/views aspects of a
> > connection are orthogonal.
>
> Hi Ralph:
>
> Thanks, the example ("use case") of an alarm tool
> wanting to subscribe to value & status, but only
> needing updates on status change answers my question.
>
> Yes, we wanted more triggers and filters.
> And we're starting over at the level of use case collection
> to determine which ones are actually needed.

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.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System