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.
From: Kay Kasemir <kasemirk at ornl.gov>
Sent: Wednesday, June 22, 2022 2:55 PM
To: Zhang, Tong <ZhangT at frib.msu.edu>; tech-talk at aps.anl.gov
Cc: Ashwarya, Tanvi <ashwarya at 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?