Re: [BLAST_ANAWARE] timing, trigger bug and tdc offsets

From: Chris Crawford (chris2@lns.mit.edu)
Date: Sun Jul 13 2003 - 22:42:05 EDT


hi tancredi et al,
  i just fixed the bug in the trigger-gui, which was causing the delays
not to be:
a) downloaded from the main gui
b) verified from the main gui
c) downloaded from the -d option
  basically, the delay modules had a suffix to the name like '/32' which
was not being ignored when checking which module it was, and so the
names were unrecognizable.
  i checked it into cvs, but et al still has to compile it on blast and
install it. i haven't checked the fix, but am 95% confident that it
will work.
  i suggest that we modify the trigger program to use a little more
class structure, as well as consolidating routines, so that we don't
have problems like this in the future (unless this was the last bug!)
--chris

Tancredi Botto wrote:

>
>
>>Tancredi-
>>
>> Does this apply to when you start the trigger or only to when you
>>make changes? I.e. when you open the gui for the first time does
>>"download all" suffice?
>>
>>
>
>download all does update the trigger paths but not the CFD delays. They
>are simply left what they were. Verify does not help (verifies the MLUs
>and there is no readback of the CFDs). To make changes to those delays
>you have to download explicitly. This clearly has been done at some point,
>which makes me think the delays were set ok a long time ago and presumably
>stayed ok. It could be analyzed of course.
>
>The core camac functions for our modules are from jlab but the problem
>could also be in the gui. I have not looked into it (yet)
>
>
>
>> Pete
>>
>>
>>On Fri, 11 Jul 2003, Tancredi Botto wrote:
>>
>>
>>
>>>Hello,
>>>I've found a bug in the trigger gui. Depending on how the file is
>>>downloaded the CFD retime delays are actually not updated (note their
>>>are not necessarily zeroed). You have to do download form each delay
>>>window (download all or trig -d don't do it). It seems a software problem.
>>>
>>>The problem could have been there since last year. There are two
>>>consequences for our data, but probably not terrible:
>>>
>>> _ the Wch may have not been always retimed (to the tune of a few ns, 20
>>> ns max) which is an issue for resolutions.
>>>
>>> - The Tof timing corrections may not have been applicable since they
>>> somehow "contained" this delay (this is a separate issue and hopefully
>>> is solved differently)
>>>
>>>
>>>--
>>>________________________________________________________________________________
>>>Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124
>>>research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949
>>>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>
>>>
>>>
>>>
>>----------------------------------------------
>>Pete Karpius
>>Graduate Research Assistant
>>Nuclear Physics Group
>>University of New Hampshire
>>phone: (603)862-1220
>>FAX: (603)862-2998
>>email: karpiusp@einstein.unh.edu
>>http://pubpages.unh.edu/~pkarpius/homepage.htm
>>----------------------------------------------
>>
>>
>>



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST