RE: Phoebus alarm does not honor filter

["Ashwarya, Tanvi via Tech-talk" <tech-talk@aps.anl.gov>]

Hello,

 

I ran a few tests and found the problem only occurs if alarm delay for test_alarm PV is set to a non-zero value. It does not matter if the test_alarm PV is configured to be latched or unlatched.

 

When alarm delay is non-zero, PV (in an alarm state) on getting re-enabled (using filter) goes into OK state and hence don’t show up on the alarm table. Until an alarm event (such as alarm state change or acknowledge action) happens on the PV, PV is seen to be stuck in OK state in alarm tree and don’t show up on alarm table.

 

Tanvi Ashwarya Tel. 517-908-7776 Email: ashwarya@frib.msu.edu

 

 

From: Kay Kasemir <kasemirk@ornl.gov>
Sent: Wednesday, June 22, 2022 2:55 PM
To: Zhang, Tong <ZhangT@frib.msu.edu>; tech-talk@aps.anl.gov
Cc: Ashwarya, Tanvi <ashwarya@frib.msu.edu>
Subject: Re: Phoebus alarm does not honor filter

 

[EXTERNAL] This email originated from outside of FRIB

> In the example you pointed out, where is the alarm configuration for PV ‘test_alarm’? I cannot see this information.

 

I added the test_alarm PV with enabling filter "test_enable>0" to the alarm tree.

 

Can you duplicate the issue with the 'test_alarm' and 'test_enable' PVs from the demo.db?

Does latched/unlatched make a difference?

Does the 2 second delay make a difference?

 

Thanks,

Kay