Re: [BLAST_SHIFTS] A shift 06/07/03

From: Adam DeGrush (degrush@mit.edu)
Date: Sat Jun 07 2003 - 16:19:54 EDT


With regards to the high voltage, it appears as though there are two or three
problems each with its own source.

1.) Crates Tripping (specifically L2) is a wire chamber problem. The first
step is to figure out which box(es) are the sources of the problem, and
record them in the log book. How to do this is in previously sent message or
probably in the logbook by now. If it turns out to be the same box and is
continously tripping we may decide to turn off that box, if problems with the
beam tune are ruled out.

2. )If a crate is no longer responding to commands from the gui it is
probably a HV mainframe problem. If you look in the xterm window where the
Epics ioc is booted from you may see something like "Broken Pipe" for one of
its response messages. If so record it in the logbook. The solution is to
try to reboot the ioc by hitting "Ctrl-c" in the xterm window where the ioc
was running and typing "./BOOT" and then return. My guess is that this will
not work. If so then you have to go down to the d-tunnel and recycle the
power to that crate. Wait for it to reboot until restarting the ioc. The
fact that everything can run fine for days and then all of a sudden fail
leads me to believe it is a problem with the mainframe and not my code. esp
since the mainframe croaks, and refuses to respond to any line of
communication, bsd or ftp.

3.) The program sticking in a "Restore In Progress" state is probably a
problem with the ioc code that I wrote. I have seen this occur under certain
conditions but those were fixed. I will look at the code again and see but
if anybody sees it again and can tell me under exact circumstances this
happened will make things easier to diagnose.

Cheers,
Adam

Nikolas Meitanis wrote:

> The beam worked withoud any problems.
> Continued data taking. Hydrogen at 2-state flipping, Cell at around 90K.
> The ABS Target screen for BLAST on dblast14 reads the wrong epics channel
> for the cell temperature. According to the ABS display on dblast12 the
> channel should be: ABS:TH:KRDG:5.VAL .
>
> Took runs 709, 711, 712, 713, 714, 715, 716, 717, 718, 720
> The lrn.C , flrn.C and charge.C worked. Crunched runs 705, 706, 707, 708,
> 709, 711, 712, 713, 714, 715, 716, 717, 718, 720. Didnt notice the problem
> reported by the previous shift.
> Compton polarimeter runs were matched to coda runs. The polarimeter runs
> were paused during the injection to prevent the tripping the previous
> shift mentioned.
>
> No Blast power supply problems.
>
> The L2 and R2 crates tripped twice each until 4:50am.
> At around 4:50am the L2 crate tripped for the second time and would not
> come back on when reset on the control screen. I had to reboot it in the
> Dtunnel which solved the problem. I also had to reboot the epics crate
> because the controls screen was stuck in a "Restoring in progress" mode
> (instead of STBY or OPER).
> R2 continued tripping but it was no match for L2 which tripped a whopping
> 12 times during the night. Reset on the control screen worked fine. It is
> also pretty quick so down time is limited.
>
> In the ten minutes after I wrote the last sentence, L2 crashed an
> additional 4 times, so let me rephrase what I said: L2 crashed a lot, it
> favors back to back trips and it disrupts data taking significantly, not
> to say that it endangers the already stretched-to-the-edge sanity of the
> shift crew with all sorts of ultra-annoying alarm messages.
>
> Asymmetry plots of the 13 runs I crunched are shown in the attachment for
> your browsing pleasure.
>
> ------------------------------------------------------------------------
> Name: c1_n3.ps
> c1_n3.ps Type: Postscript Document (APPLICATION/postscript)
> Encoding: BASE64
>
> Name: c1.ps
> c1.ps Type: Postscript Document (APPLICATION/postscript)
> Encoding: BASE64



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