ah yes. ... (down to 1/4, not much of a surprise at all)
TBLEpicsRecon.h:146: float par0, par1, par2, pedestal;
TBLEpicsRecon.cc:46: pedestal = 4800;
TBLEpicsRecon.cc:54: pedestal = 2400;
TBLEpicsRecon.cc:77:
>>inputreg>>tslreg>>slots>>nbgsca>>bgsca>>spinflipon>>pedestal>>par0>>par1>>par2;
TBLEpicsRecon.cc:85:
>>inputreg>>tslreg>>slots>>nbgsca>>bgsca>>spinflipon>>pedestal>>par0>>par1>>par2;
TBLEpicsRecon.cc:440: scal_charge = raw.scalers[nbgsca+slots*9].value -
pedestal;
TBLEpicsRecon.cc:443: bgscal_charge = raw.scalers[bgsca+slots*9].value
- pedestal*livetime;
you can get away with just changing it to 0 in epics.cal (with the
appropriate run number), since the calibration is read from this file.
that way you don't have to hardcode in another if..then block . (same
for other parameters)
--Chris
Douglas Hasell wrote:
> Thanks Chris but obviously since the previous calibration had a
> pedestal there should also be some lines to the effect of
>
> scal_charge = dcct - pedestal
>
>
> 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
> On Apr 13, 2005, at 6:49 PM, Chris Crawford wrote:
>
>> Doug, ready for 1/3 of a pleasant surprise?
>>
>> There are 1/(1/3) places:
>>
>> ep_skim.h:128:float par0 = 2.90027; -> not used! delete it to save
>> confusion
>>
>> TBLEpicsRecon.h:146: float par0, par1, par2, pedestal;
>> TBLEpicsRecon.cc:47: par0 = 2.63549; par1 = 1.50749e-4; par2 =
>> 1.8612e-10;
>> TBLEpicsRecon.cc:55: par0 = 2.90027, par1 = 3.01409e-4, par2 =
>> 6.18094e-10;
>> TBLEpicsRecon.cc:77:
>> >>inputreg>>tslreg>>slots>>nbgsca>>bgsca>>spinflipon>>pedestal>>par0>>p
>> ar1>>par2;
>> TBLEpicsRecon.cc:85:
>> >>inputreg>>tslreg>>slots>>nbgsca>>bgsca>>spinflipon>>pedestal>>par0>>p
>> ar1>>par2;
>> TBLEpicsRecon.cc:446: fScaler->fScaler_Beam = par0 +
>> scal_charge*(par1 + par2*scal_charge);
>> TBLEpicsRecon.cc:447: fScaler->fBG_Beam = par0 +
>> bgscal_charge*(par1 + par2*bgscal_charge);
>>
>> and then edit "Blast_Param/epics.cal"
>> note: this file is not archived (it has its own history), so don't
>> worry about reading a file with fewer parameters. good design
>> choice, Chi!
>>
>> i don't care about when you start crunching with the update, but
>> please check in a new version of BlastLib2 (v3_4_7) when you do.
>> (see elog sticky note)
>>
>> --Chris
>>
>>
>> Douglas Hasell wrote:
>>
>>> Did not ask Dan about this. We can check when we get beam.
>>>
>>> Who knows where all the places for this calibration exist in the
>>> code. I will be pleasantly surprised it there is just one place
>>> that needs to be changed. Also we need to decide when we change
>>> the code.
>>>
>>>
>>> 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
>>> On Apr 13, 2005, at 6:07 PM, Chris Crawford wrote:
>>>
>>>> Hi Doug,
>>>> Was the calibration of the epics LDCCT variable OK? I was under
>>>> the impression that Dan had been calibrating it periodically in
>>>> hardware, so it should still be accurate.
>>>> --thanks, Chris
>>>>
>>>> Electronic Log Book wrote:
>>>>
>>>>> Operator: hasell
>>>>>
>>>>> Easy shift - hall open.
>>>>>
>>>>> Karen, Dan, and I recalibrated the DCCT scaler against a
>>>>> calibrated charge source. See run 15198. Also performed the
>>>>> fit. Results are in ELOG. Interesting thing to note is that the
>>>>> voltage to frequency converter is only good to just over 250 mA
>>>>> so unless we want to make a big change we should stay below 250
>>>>> mA for data acquisition.
>>>>>
>>>>> Michael and Karen replaced the laser on the flasher system. So
>>>>> that is working again for runs 15206 and following.
>>>>>
>>>>> Aki has recalibrated the unpol system so it is now available for
>>>>> both H and D.
>>>>>
>>>>> Nozzle was regenerated and Genya started ABS again.
>>>>>
>>>>> Bill and Taylan measured the circular polarisation of the laser
>>>>> just before it entered the ring and found that it is getting
>>>>> worse with time. Mostlikely the reason is dirty optics. Still
>>>>> the effect is small enough that we won't do anything about it.
>>>>>
>>>>> Other that we took cosmic data.
>>>>>
>>>>> Started locking up the south hall at 16:30.
>>>>>
>>>>> Runs 15200-15201 15203-15209 are cosmic
>>>>>
>>>>>
>>>>
>>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:32 EST