Re: [Pvmanager-devel] alarm limits will not always work

[Dalesio, L. <da...@bn...>]

Got it - yeah - that was why that one option existed.
Bob

-----Original Message-----
From: Ralph Lange [mailto:Ral...@be...]
Sent: Fri 9/10/2010 10:09 AM
To: epi...@li...
Cc: pvm...@li...
Subject: Re: alarm limits will not always work
 
  On 10.09.2010 08:25, Dalesio, Leo wrote:
>
> It doesn't have to in any cases I can think of.
> The configuration of alarm conditions is the job of the engineer that 
> configures the alarms.
> The alarm clients only need to decide -
> --- what and how to display
> --- who to notify in that condition
> --- is there any action to take on that alarm condition and severity.
>
> The client is not checking for alarm. The client is handling alarm 
> conditions.
>
Hi Bob,

You didn't get Marty's point.
(I didn't get it either, until microseconds before I hit the send button.)

What he tries to say is:
The dbr_gr_xxx limits structure does not have the complete information, 
as it only contains the alarm levels, but not the severities that are 
connected to them. These are configured separately in the record, and a 
client must access separate fields to get the whole picture.

E.g.:
If a client wants to put alarm markers on a scale widget for an analog 
value, getting the dbr_gr_xxx tells it *where* to put the marker, but 
not the *color* that the marker should have.

This is why - in our suggestion to handle alarm status with a immutable 
string enum - there should be an array of severities related to the 
strings, that shows which alarm condition causes which severity value.
The severities should probably be separate from the immutable enum, 
since the relation of alarm condition and severity is configurable per 
record instance, and coding the severity into the immutable enum would 
create a large number of slightly different enums, destroying the 
efficiency advantage of sharing the immutable enums between connections 
(sending the strings once, using the enum ID in the updates).

Ralph