Re: [BLAST_SHIFTS] things that go bump in the night...

From: Tancredi Botto (tancredi@mitlns.mit.edu)
Date: Mon Jul 21 2003 - 09:56:56 EDT


On Mon, 21 Jul 2003, Kevin McIlhany wrote:

> Two main issues:
> 1) There is a problem with e-log submission as one of the scripts ate
> itself (cleanthis.bash). So, we do it the old fashioned way - via
> email.

yes elog is still moving and being fixed daily. However the correcting
action should be a little more specific: in this case the problem was with
updating the web page after download the trigger. A little investigation
into the trig.cc program would have given you the right script name and
that could have been fixed or its updating action be commented out.
Running cleanthis clearly did more than that...

> Investigation shows that at least one environmental variable as lost
> related to Epics ($EPICS_DISPLAY_PATH)

On purpose commented out, as sourcing epics paths (not "ours") typically
brings in the problem of not being able to boot the coda front end. So we
have to do with less epics niceties.

> happened before and to fully cycle power on the HV crates (ie. turn them
> off from the back and let them rest for a minute). After the first try,
> two of the crates refused to make connections (right sector WC and left
> sector TOFs) prompting a second try at a full power cycling. After this
> time, all crates responded and we are back in business.

this is quite usual operation I am afraid it can happen again.

> Well... not quite.... after trying to start a run, we notice that
> there are no scalers being reported although the HV is now behaving (it
> shows trips and recoveries). A trip to the d-tunnel to reboot the
> FASTBUS crate does not help.

fastbus and scaler screen have little in common.

> Finally, a call to Karen Dow helps with her suggestion to try
> "beamgate_on", which magically un-inhibits the datastream and we are
> really back in business now.

related to either a loss of power in the camac crates, or maybe the camac
controller in the scaler VME crate or maybe a down-right bad download
sequence of the camac trigger. I think it is documented in the manual,
the gate circuit is also documented in logbook 6. The beamgate comes on
normally closed (off) after a power up or a camac reset.

Please also check the target state is "defined" (red) as that also inhibit
the trigger



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