[Hallc_running] [Revised Logentry] Run Coordinator report Thursday, Feb 20

Thu Feb 20 11:25:01 EST 2020

Logentry Text:
--
<p><span style="text-decoration: underline;"><strong>RC Report for Thursday, Feb 20, 2020 </strong></span></p><p>Pretty smooth running since yesterday. Yesterday afternoon the beam was very stable, becoming more trippy over time but not worse than usual. Overall we've had very productive shifts. The only hiccup was with the target around midnight last night, about an hour after the most recent NMR had been taken (55.3%). The correction coil had gone off, and after correcting that problem 2 more NMRs were apparently taken which dropped the polarization to 52%. So after talking about it this morning, we decided that the lesson learned for the future is that if you're concerned about some issue and think you need to take more than one NMR every 5 h, please call the target expert on call before doing so. In last night's case, the correction coil should not have affected the polarization so it wasn't necessary to take more NMRs.</p><p>Still need 2 shifts filled: one on Saturday d!
 ay and one on Saturday swing. Please sign up for them!!</p><p>The big news at the 8 AM meeting was that Andre announced there will be an accelerator safety stand-down next week, on Wednesday Feb 26 from 9AM to noon. There will be no beam delivered during that time and no ops support available. At first we thought maybe we could go in the hall and get some things done if we swept the hall prior to the stand-down, but there will be no SSO to let us in or out during controlled access. So it doesn't work- we don't want to go to restricted access. And it's not clear yet whether the all-hands meeting that will be required for accelerator folks will extend to physics staff, etc. either. Stay tuned.</p><p>After the 8 AM meeting I had very productive discussions with the PD (Edith Nissen) and then the Crew chief (Ken Surles-Law) about our laundry list of issues developed at yesterday's RC meeting:</p><ul><li>Burcu had already provoked a response concering the fact that the orbit loc!
 ks seem to go off from time to time. There is now a standing o!
 rder in MCC not to turn these off, and if for some reason they need to go off temporarily anyway, or are discovered to be off, to ELOG it. I asked them to include us as well. You can see this here: <a href="https://accweb.acc.jlab.org/apps/pd/shift-plans/33039">https://accweb.acc.jlab.org/apps/pd/shift-plans/33039</a>. For those off-site, it says: </li><ul><li><strong>Wednesday 19 February 2020 - Are all the locks running that should be running?</strong><div class="standing-order-body" style="box-sizing: border-box; color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, Arial, Helvetica, sans-serif; font-size: 14px;"><em>We need to be move vigilant at restoring orbit locks if we have turned them off - <a style="box-sizing: border-box; background-color: transparent; color: #990000; text-decoration-line: none;" href="https://logbooks.jlab.org/entry/3787347">3787347<br></a>If they are off for a reason there should be a log entry stating wh!
 y and this needs to be turned over. Not that this applies to the log entry above but "They were off when I came on shift" is never a good reason for locks to be left off. An answer like that shows two failures. 1) If the locks are intentionally off that should have been explained at turn over. 2) If you weren't told at turnover then you should have asked. The halls are very particular about having locks and FFB running. If they are off because we believe it is a source for trips or instabilities, there should be a log entry and if it looks like they are not the source, then they should go back on.</em></div></li></ul><li></li><li>Then I asked if the locks could come on at a lower current, around 10 uA, to give us more protection. The answer was that they have no mechanism to set a threshold, it either comes on from the get-go as soon as they start ramping up the beam current, or it comes on after they're ramped up. So I asked about having locks at the get-go. We looked at s!
 ome examples of how much the beam moved on our 3H07A&B BPMs during !
 ramp-up. We didn't see any motion more than a few microns. Then Ken said that about 2 weeks ago, Hall A had begun starting their locks at the get-go, as soon as the beam started ramping up. So I asked him to do that for Hall C as well, starting today. We should observe this carefully today and change back if we're not happy with what we see. Before the weekend if at all possible. </li><li></li><li>Then we talked about the ramp rate. No problem- he changed our beam current ramp rate from 0.5 uA/s to 0.75 uA/s.</li><li></li><li>Then we talked about the raster energy alarms. The working hypothesis is that the mismatch between the raster GUI energy (10.43 GeV) and the Tiefenbach energy (10.386 GeV) is the reason for our nusiance alarms. I told him I was skeptical of this explanation, and thought it was probably transients, but what the hell, why not change the raster GUI energy the 1/2% to match the actual beam energy anyway. I had to go back to the counting room to give h!
 im the process variable name (ecEHCFRHALLC:p). But I noticed that the alarm limits on this are 10 times tighter than the 0.044 GeV actual difference between 10.43 and 10.386 GeV. So it should alarm all the time if that's the problem. And then we had a raster energy alarm while we were looking at the GUI, and the reason was that this PV was "inf", ie it was a readout transient, not a real issue. The crew chief said he'd talk to software about changing the raster energy anyway, and look also for a less noisy PV to use for energy.</li><li></li><li>Finally, after talking to Jay about the fact that our harp wire 3 is often not fully in the travel of the harp scan, and our width for that wire may not always be trustworthy, he said it's just a limit switch and could be moved. So I asked Ken to find out for us how long it would take to move that switch, how difficult it would be, if there's any risk to do so, etc. I also said that we didn't want to interupt production in order to d!
 o this but that we could better plan for this change during an opportun!
 istic access if we had that info. He'll get back to me.</li></ul>

---

This is a plain text email for clients that cannot display HTML.  The full logentry can be found online at https://logbooks.jlab.org/entry/3788114
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/hallc_running/attachments/20200220/10ad3c96/attachment.html>