[Olympus] SlowControl

Fri Apr 16 05:52:37 EDT 2010

Dear Alexander,

Only one thing to add. HV readout must be faster. At least once per 10 
seconds. This has to me done to locate trip time and mark the events bad 
if needed. Storing HV data may be done even more rare if everything stays 
at it's level.

Anton

> Dear Anton,
> 
> your concept for the HV data bases looks fine. For the SetOn and SetCurrent
> tables it would be good, if the storing is not time driven but event driven,
> i.e. only on changes these tables are stored.
> The real voltages and currents should be monitored with a fixed frequency,
> maybe once every 5 minutes. This would last in approximately 30 MB/year per
> table (if I'm not totally mistaken), which is fairly easy to handle I guess.
> Is it possible to have a button to force the readout of the HV voltages and
> currents, so that you don't need to wait some minutes if you want to see
> something?
> A StatusHV table is a good idea. The corresponding readout might be relatively
> fast, i.e. at least once per minute, so that one can see quickly if a HV
> channel is tripped. The storing of the readout values should be done only on
> changes not to inflate the data base.
> 
> What do you think about it? I guess you have a concept for all this already.
> 
> @ John: I wonder if you mix up two things here. There is the slowcontrol and
> the online monitoring. The slowcontrol will control the HVs, temperatures,
> flows, machine parameters etc. and the online monitoring will evaluate the
> incoming data from the detectors, i.e. showing TDC and ADC spectra, count
> rates, hit distributions etc.
> To have an offline matching of sc data and the data of the detectors, we might
> have a table in the sc with the time of begin and end of run with the run
> number, or the unix time is stored in every event in the data stream.
> 
> Best regards,
> 
> Alexander
> 
> 
> 
> Anton Izotov wrote:
> > Hi,
> > 
> > First part of this message is for John. HV part is for whole collaboration.
> > 
> > I propose to separate HV data base and the rest of SC. Let's say 3 data
> > bases on the server: StatusBar, SlowControl, HV. About Status Bar we may
> > talk later.
> > 
> > As far as I understood your message, for TOF we need two tables 68+1 (+1
> > means unix time) columns each in SlowControl db: tofADC, tofTiming.
> > Two low level clients to read out and to fill corresponding table, and two
> > 68 channel timegraps (paged say 8 lines on page) to display actual values.
> > As soon as all detector status is going to be shown on StatusBar those time
> > graphs not needed permanently on screen in control room. Insteaad of that
> > they may start with say 2 hours history. So you can see when the problem
> > started in case of problem.
> > 
> > Concerning HV. 
> > THIS IS NOT ONLY FOR JOHN!!!!!!!!!!!!!!!!!! 
> > 
> > I would like to discuss it more detailed. First of all it has to be
> > separated from the rest of SC nevertheless it is a part of SC.
> > 
> >>From the db  point of view it is separate HV db. And now I would like to 
> > discuss it's structure. 
> > I propose 5 tables for each detector. Taking TOF as example:
> > 1. tofSetON contains 68+1 columns with the actual set voltage for ON.
> > 2. tofSetCurrent 68+1 acceptable leackage currents.
> > 3. tofSetStandby 68+1 (probably not needed for PMT's) stand by voltages. 4.
> > tofVoltage 68+1 current voltages.
> > 5. tofCurrent 68+1 actual leackage currents.
> > 
> > However if we do not want to store all values sets during the run, 3 first
> > tables turns to 1 with 68 rows corresponding channels and 4 columns:
> > stand by voltages, ON voltages, leackage currents.
> > 
> > Additionally I would add one StatusHV table for all detectors with 4
> > columns: unix time, detector, channnel, status.
> > Where status is:
> > 0 - channel OFF,
> > 1 - channel StandBy,
> > 2 - channel ON,
> > 3 - channel trip.
> > 
> > This table has to be updated only at the time when status of channel is
> > changed.
> > 
> > Anton
> > 
> > > For the TOF scintillators, individual PMT ADCs need to be monitored
> > > to make certain that gains are matched. There will be 17 scintillators
> > > on each opposing sector = 34 scintillators, each with a PMT at both
> > > ends = 68 PMTs = 68 ADC channels. It is also necessary to monitor the
> > > timing ... so 68 TDC channels. The ADCs should be gated and the TDCs
> > > started by a common gate/start. We will also need to monitor the 68
> > > values of HV in a slow control display which will allow for both seeing
> > > the HVs as well as adjusting them if necessary.
> > >
> > >
> > > -- 
> > > John R Calarco
> > > Dept of Physics
> > > Univ of New Hampshire
> > > Office: 603-862-2088
> > > FAX: 603-862-2998
> > > Email: Calarco at unh.edu
> > >
> > > > Dear friends,
> > > >
> > > > looks it's time to collect some info for future. Not far future, BTW.
> > > > We all need a SlowControl (SC) data. And we want it as ... as possible.
> > > > Taking into account that our project seems to pretend to be very precise
> > > > one we are much dependent on SC data. It is reality.
> > > >
> > > > I would like to know your oppinion. What would you like to store
> > > > (see on your monitors, monitor, control) about your own beloved
> > > > detector?
> > > > I mean ADC channels number needed as well.
> > > >
> > > > Responsibles! I'm calling to you.
> > > >
> > > > The sooner you answer the sooner it works.
> > > >
> > > > My best...
> > > >
> > > > Anton
> >>> _______________________________________________
> > > > Olympus mailing list
> > > > Olympus at mit.edu
> > > > http://mailman.mit.edu/mailman/listinfo/olympus
> > > >
> > >
> > _______________________________________________
> > Olympus mailing list
> > Olympus at mit.edu
> > http://mailman.mit.edu/mailman/listinfo/olympus
> 
> -- 
> Dr. Alexander Winnebeck
> Helmholtz-Institut fuer Strahlen- und Kernphysik der Universitaet Bonn
> Nussallee 14-16             Tel.: 0049 228 73 2457		53115 Bonn
> Fax.: 0049 228 73 2505
> Germany
> 
> 
> 