<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
The number of beam trips is tracked and categorized in the downtime
manager.
(<a class="moz-txt-link-freetext" href="https://accweb.acc.jlab.org/dtm/reports/fsd-summary?start=02-May-2015+01%3A00&end=02-May-2015+15%3A35&maxDuration=5&max">https://accweb.acc.jlab.org/dtm/reports/fsd-summary?start=02-May-2015+01%3A00&end=02-May-2015+15%3A35&maxDuration=5&max</a>)
Available on-site only. Below is the number of trips per hour
since 1am this morning. Nominally it looks like the rate is about
one RF trip/h and the rest are associated with BLM/MPS, this is
typically due to tuning or steering activity in the hall lines.
Hall-A stopped taking beam at 10am-1:30pm and the Hall-D line was
steered up around 10:40, leading to a quiet period. The purple
Dump trips are "the cost of doing business" due to the insertion of
various dumps to aid tuning/steering. <br>
<br>
The point is, every beam trip is not RF related, in fact at this
energy there have been periods over 2h in length without an RF
trip. <br>
<br>
One more reason to look forward to single pass operation Monday and
beyond.<br>
<br>
Arne<br>
<img src="cid:part1.00060907.02070105@jlab.org" alt=""><br>
<br>
<div class="moz-cite-prefix">On 05/02/2015 12:43 PM, Maurik Holtrop
wrote:<br>
</div>
<blockquote
cite="mid:FCF654EF-4ADB-4A1B-A917-BB72E32A32CA@physics.unh.edu"
type="cite">
<pre wrap="">Hello Valerie,
Beam trip, or DAQ crash?
When the beam trips, which usually means an RF trip in the accelerator, I see no real reason to start a new run, although stopping and starting runs does not take a huge amount of time either, I don’t think it is necessary. So for beam trips, I don’t really see a problem that can be solved and we can probably just continue data taking when the beam comes back.
If there is a DAQ crash, you have no choice but to reset the DAQ. This does loose time, and I agree those issues need to be resolved. I see from the run sheet that there were about 3 DAQ crashes recently. Too many, but not too horrible. The Shifters should try to document the actual reason for the crash by preserving the diagnostic output in from the xterm window of the process that caused the crash. That will help Sergey diagnose the problem.
Best,
Maurik
</pre>
<blockquote type="cite">
<pre wrap="">On May 2, 2015, at 11:45 AM, Valery Kubarovsky <a class="moz-txt-link-rfc2396E" href="mailto:vpk@jlab.org"><vpk@jlab.org></a> wrote:
Hi All:
We started data taking with 50 nA beam current at 01:59 on May 02, 2015.
It is a great achievement due to the hard work of the HPS team.
Now it is time to improve the quality of the data and minimize the lost of beam time.
Looking at HPS run table I realized that up to now (11:28, 9.5 hours of data taking) we took 23 runs!
ALL of them were ended with the beam trip! You can imagine how much beam time were lost due
to the DAQ restarting.
Does anybody work on this problem? Can we avoid stop data taking after every beam trip?
Regards,
Valery
_______________________________________________
Hps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Hps@jlab.org">Hps@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/hps">https://mailman.jlab.org/mailman/listinfo/hps</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Hps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Hps@jlab.org">Hps@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/hps">https://mailman.jlab.org/mailman/listinfo/hps</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Arne Freyberger
Director of Accelerator Operations
Jefferson Lab
12000 Jefferson Avenue Cell: (757) 876-6289
Postal Suite 19 Email: <a class="moz-txt-link-abbreviated" href="mailto:freyberg@jlab.org">freyberg@jlab.org</a>
Newport News, VA 23606 </pre>
</body>
</html>