The alarm handler has several acknowledgment modes that can be
applied to individual and/or groups of alarms. The default is for
all alarms to "latch" ON which requires the user to clear all
alarm conditions manually. What you probably want is to use the
"No Ack Transient" mode, where the alarm is only indicated while
the device is actively in a "fault" condition. Once the fault
condition goes away, the alarm automatically clears itself. The
alarm handlers have various logs and other features as well. I
would be willing to give a training session on alarm handler
setup/use if desired.
Shannon
Adam DeGrush wrote:
>
> Hi Doug,
>
> Douglas Hasell wrote:
>
> > Hi,
> >
> > Sorry Adam I forgot to respond to this yesterday.
> >
> > Basically, I agree. Intermittent trips should be reset and if the
> > boxes can't hold voltage it should be turned off and fixed at the earliest
> > opportunity. However, tripping may indicate bad beam tune which should be
> > fixed first.
> >
> > I think automatic resetting may be a good idea with some monitoring
> > of how frequently it is done to a given box and then if it is too frequent
> > the box can be turned off or the problems solved some other way. Since the
> > ramping can take up to 40 seconds tripping and resetting more than five
> > times in five minutes for the same box is probably excessive and it should
> > be turned off.
> >
>
> I agree, that's why I think you should have the ability to turn it on/off.
>
> >
> > Alarm sounds good but also need some way to switch the alarm off
> > for some channels after the initial alarm.
> >
>
> I'm not sure what you mean. Basically, an alarm will sound and the main alarm
> handler window will flash red when there is a trip. Once you acknowledge it by
> clicking on the little red boxes with the "E" (for error) inside it next to the
> appropriate group, the beeping will stop but the main box will still be red.
> Once you've reset the voltages, the color will change from red to normal grey.
> This may not make sense until people try it. It's running on dblast09 or if
> not the instructions to start it are in the last shift summary. People are
> encourage to click around and not worry since they can't mess anything up by
> doing so.
>
> Also other detector groups that use epics can look at it and start to think
> about what they want to add to it.
>
> adam
>
> >
> > --On Thursday, May 29, 2003 11:48 AM -0400 Adam Jon DeGrush
> > <degrush@MIT.EDU> wrote:
> >
> > >
> > > Hi,
> > >
> > > I have only a couple of comments. I think that the wire chamber tripping
> > > can be divided into two cases.
> > >
> > > 1.) The the tripping is intermittant and is fixed for the most part by
> > > reseting the voltages.
> > >
> > > 2.) The box never is able to hold voltage.
> > >
> > > If it is determined to be solely a wire chamber problem and not a beam
> > > tune, then I think for condition 1. it makes sense to reset the voltages.
> > > I can add in an auto reset feature that does this and can be switched on
> > > an off at will. If it is condition 2. then it makes sense to disable the
> > > voltage on that box because with the daq inhibit working, you will never
> > > be taking any data anyway.
> > >
> > > Doug, do you think an auto reset would be useful? I can see pros and cons
> > > to automating this.
> > >
> > >
> > > Also I am writing and EPICS Alarm handler similiar to the one CCR uses
> > > that will beep when there is an alarm (for example, a crate trips) along
> > > with other features. Although it is in its infancy, it has the WC gas
> > > system and the crate trip status. I will test it tonight and, Allah
> > > willing, leave it running so that users will not have to keep checking on
> > > the trip status while I expand it to include other components.
> > >
> > > Cheers,
> > > Adam
> > >
> > >
> > >
> > > On Thu, 29 May 2003, Douglas Hasell wrote:
> > >
> > >> Hi,
> > >>
> > >> Just a comment about the wire chamber tripping last night.
> > >>
> > >> During the first part of the shift there was an attempt to run
> > >> without the BLAST magnetic field which was unsuccessful. The rates in
> > >> the BQM were not reported but this would be useful to know. In any case I
> > >> suspect the wire chambers charged up during this phase.
> > >>
> > >> Then, when the toroid was turned on some boxes continued to trip.
> > >> Again, knowing what BQM rates were would be useful. I think the correct
> > >> thing to do in this case is to turn the WC HV off and have no beam for
> > >> about one hour and then try again. The shift turned off four boxes which
> > >> were tripping regularly and then continued to run.
> > >>
> > >> Turning off the boxes and continuing data taking should be
> > >> avoided if at all possible. Each box usually connects to 5
> > >> cells. The inner chamber has 18 or 19 cells so 5 corresponds to over
> > >> 25% of the angular range covered by the inner chambers. The middle and
> > >> outer chamber have 26-27 and 34-35 cells so are a bit less important.
> > >> With these cells missing there is effectively no tracking through that
> > >> region (there are some fixes which can track with missing super-layers
> > >> but it is a reduction in efficiency if nothing else). So not only do we
> > >> lose the data from these tracking regions but if we wish to use these
> > >> runs in any physics analysis we have to run the Monte Carlo with these
> > >> boxes turned off for the same luminosity and spin states in order to
> > >> compare the data.
> > >>
> > >> The inconvenience of resetting the HV during a run has to be
> > >> weighed against shutting things down for an hour or the hassle of running
> > >> the MC with these same boxes off in order to use the data.
> > >>
> > >> Of course ultimately boxes tripping is a wire chamber problem
> > >> which has to be solved. But for the past few weeks we have run
> > >> the wire chambers with relatively few trips and without needing to turn
> > >> off boxes so I think the BQM rates were probably high and/or the
> > >> chambers had become charged during the period with no toroid.
> > >>
> > >> Cheers,
> > >> Douglas
> > >>
> > >> 26-415 M.I.T. Tel: +1 617 258 7199
> > >> 77 Massachusetts Avenue Fax: +1 617 258 5440
> > >> Cambridge, MA 02139, USA E-mail: hasell@mit.edu
> > >>
> > >
> >
> > Cheers,
> > Douglas
> >
> > 26-415 M.I.T. Tel: +1 617 258 7199
> > 77 Massachusetts Avenue Fax: +1 617 258 5440
> > Cambridge, MA 02139, USA E-mail: hasell@mit.edu
-- Shannon Krause Accelerator Operations Group Leader MIT Bates Linear Accelerator Center 21 Manning Rd. - P.O. Box 846 Middleton, MA 01949, USA617-253-9206 krause@mit.edu
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST