1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: Phoebus alarm does not honor filter |
From: | "Zhang, Tong via Tech-talk" <tech-talk at aps.anl.gov> |
To: | "Ashwarya, Tanvi" <ashwarya at frib.msu.edu>, Kay Kasemir <kasemirk at ornl.gov>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Thu, 23 Jun 2022 15:07:05 +0000 |
Hi Tanvi, Have you tested against the codebase that with this PR (https://github.com/ControlSystemStudio/phoebus/pull/2303)
gets merged or not? Thanks, Tong From: Ashwarya, Tanvi <ashwarya at frib.msu.edu>
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>
[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 |