[Olympus] SlowControl

[Anton Izotov]

On Fri, 16 Apr 2010, Brinker, Frank wrote:

Hi,

HERA data was accessible via nextmex server. Probably DORIS data is there 
as well. At least I hope it's there. It has to be clearyfied. If it is so 
I from y side will try to find old HERMES soft to access this server.
If I remember correctly, update was every 10 seconds.

Anton

> Dear collegues,
> I guess you would also like to store some data from DORIS - they are
> achived anyway but it's probably easier to handle them, if they are
> already stored together with the event data.
> 
> I think what's useful are:
> - current of each bunch ( 10 values )
> - total current
> - lifetime
> - information of position monitors ( 8 times 2 values )
> - scraper positions ( 4 or 6 )
> - corrector currents ?
> - cavity voltage ? ( -> bunch length )
> 
> I assume a rate of once every 10 seconds is sufficient.
> 
> Best regards
> Frank
> 
> 
> >-----Original Message-----
> >From: olympus-bounces at mit.edu [mailto:olympus-bounces at mit.edu] 
> >On Behalf Of Anton Izotov
> >Sent: Friday, April 16, 2010 12:09 PM
> >To: Jan Bernauer
> >Cc: olympus at mit.edu; John R Calarco
> >Subject: Re: [Olympus] SlowControl
> >
> >
> >Dear Jan,
> >
> >IMHO. Except HV and even with HV SC data stream is very 
> >small in comparison with main data. So I would propose to 
> >write everything 
> >to DAQ user events as well as to SC db. Just to be on a safe 
> >site. However, data analysis will go slower if one has to dig  
> >SC data out from 
> >huge amount of DAQ data. It is much easier to take it from one place.
> >
> >So we can store everythin in CS db and in DAQ. But use DAQ stored data 
> >only if it somehow lost in SC db.
> >
> >Anton
> >
> >
> >> 
> >> Dear colleagues,
> >> 
> >>  in Mainz, the slow control saves everything (event driven) 
> >in its own 
> >> database, but at the start of a run, the complete status quo 
> >is dumped 
> >> into the data acquisition file. That is about 1 to 3 MB of 
> >data, so no 
> >> problem. It is so much easier to analyse your data if you have 
> >> everything consistent in a single location, and you don't have to 
> >> match and mix.
> >> 
> >> We even mix important slow control information into the 
> >readout event 
> >> stream, like target parameters (pressure, temperature), 
> >event scalers 
> >> etc. Of course not for every event, but on every change of these 
> >> values. That proved *very* useful.
> >> 
> >> Redundancy in the data saved my analysis several times. I suggest we 
> >> store the start and stop of each run in the slow control 
> >log, and for 
> >> every event as much timing info as possible (run time, live 
> >time, dead 
> >> time from scalers, unix time). Do we have a plan for the luminosity 
> >> and dead time estimation?
> >> 
> >> Best regards,
> >> Jan
> >> 
> >> Alexander Winnebeck wrote:
> >> 
> >> > @ 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.
> >> > 
> >> 
> >> 
> >> -- 
> >> Jan C. Bernauer                       email: 
> >bernauer at kph.uni-mainz.de
> >> Institut f?r Kernphysik               tel  : 06131 - 39 25826
> >> Johannes-Gutenberg-Universit?t Mainz  fax  : 06131 - 39 22964 
> >> Johann-Joachim-Becher-Weg 45 55099 Mainz
> >> 
> >_______________________________________________
> >Olympus mailing list
> >Olympus at mit.edu
> >http://mailman.mit.edu/mailman/listinfo/olympus
> >
>