Hi. I have an alarm handler question...
We sometimes use the FORCEPV temporarily to disable alarms. For example,
we have a vacuum error which is disabled when the telescope is slewing
(so its mask is set to --D-- during the slew and then back to its
default of ----- on completion of the slew).
Last night, the vacuum alarms were being generated spuriously, so the
operator tried to disable them. However, each time a slew completed, the
mask was set back to the default of -----, not the operator override of
--D--.
Also, although this is specific to our operational environment, the field
which indicates slew/track is actually posted every 20 seconds
regardless of whether its state changed. This means that the mask is set
back to its default every 20 seconds regardless of whether the
slew/track state actually changed (because the FORCEPV logic checks
whether the current value matches the force or reset values; it doesn't
check for a transition).
So, I am asking whether it would be reasonable to do the following:
a) allow the FORCEPV reset mask to honor any operator overrides,
b) allow the FORCEPV logic to check for transitions to the force or
reset values
Of course, I apologise unreservedly if we are inadvertently using an old
version and these issues have already been resolved. Happy new year to
all.
William
- Replies:
- Re: alarm handler question Sue Witherspoon
- Navigate by Date:
- Prev:
Re: Delay of Maximize Severity in OUT Links Marty Kraimer
- Next:
Re: alarm handler question Sue Witherspoon
- 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
- Navigate by Thread:
- Prev:
Re: Delay of Maximize Severity in OUT Links Marty Kraimer
- Next:
Re: alarm handler question Sue Witherspoon
- 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
|