[Olympus] SlowControl

Wed Apr 14 04:30:29 EDT 2010

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