Received: from BY5PR09MB5666.namprd09.prod.outlook.com (2603:10b6:a03:249::23)

by BLAPR09MB7315.namprd09.prod.outlook.com with HTTPS; Fri, 23 Sep 2022
00:06:08 +0000

Received: from BLAPR09MB7153.namprd09.prod.outlook.com (2603:10b6:208:28b::12)

by BY5PR09MB5666.namprd09.prod.outlook.com (2603:10b6:a03:249::23) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.19; Fri, 23 Sep
2022 00:06:05 +0000

Received: from BLAPR09MB7153.namprd09.prod.outlook.com

([fe80::9c13:d155:846d:125]) by BLAPR09MB7153.namprd09.prod.outlook.com
([fe80::9c13:d155:846d:125%4]) with mapi id 15.20.5654.017; Fri, 23 Sep 2022
00:06:05 +0000

From: Hovanes Egiyan <hovanes@jlab.org> To: Brian Bevins <bevins@jlab.org>, Brian Freeman <bfreeman@jlab.org>, Edith

Nissen <nissen@jlab.org>

CC: Alexandre Deur <deurpam@jlab.org>, Igal Jaegle <ijaegle@jlab.org> Subject: RE: Excursions in Hall D beam positions Thread-Topic: Excursions in Hall D beam positions Thread-Index: AQHYzocqv7X/l1G4HEa+J6Ou/kTMl63rj/UtgAAEJw2AAAnBKoAAMqJ6gABMPug= Date: Fri, 23 Sep 2022 00:06:05 +0000 Message-ID: <BLAPR09MB715377A75B89AD4A01FB3785C34E9@BLAPR09MB7153.namprd09.prod.outlook.com> References: <BLAPR09MB7153B51FC1C4BCAE96198C77C34E9@BLAPR09MB7153.namprd09.prod.outlook.com>

<BLAPR09MB60998CBEC3D2241146FDD5EBAE4E9@BLAPR09MB6099.namprd09.prod.outlook.com>
<BLAPR09MB71534E9315834D6521DBA778C34E9@BLAPR09MB7153.namprd09.prod.outlook.com>
<DM6PR09MB56382EC55217A6878F7A88E5BF4E9@DM6PR09MB5638.namprd09.prod.outlook.com>
<BLAPR09MB6099134CF20CFB8465768A3EAE4E9@BLAPR09MB6099.namprd09.prod.outlook.com>

In-Reply-To: <BLAPR09MB6099134CF20CFB8465768A3EAE4E9@BLAPR09MB6099.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 04 X-MS-Exchange-Organization-AuthSource: BLAPR09MB7153.namprd09.prod.outlook.com X-MS-Has-Attach: yes X-MS-Exchange-Organization-Network-Message-Id: 683c37f4-5488-4bff-a510-08da9cf7688a X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 x-ms-publictraffictype: Email authentication-results: dkim=none (message not signed)

header.d=none;dmarc=none action=none header.from=jlab.org;

x-ms-office365-filtering-correlation-id: 683c37f4-5488-4bff-a510-08da9cf7688a x-ms-traffictypediagnostic: BLAPR09MB7153:EE_|BY5PR09MB5666:EE_ x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:-1;SRV:;IPV:NLI;SFV:SKI;H:BLAPR09MB7153.namprd09.prod.outlook.com;PTR:;CAT:NONE;SFS:;DIR:INB; x-microsoft-antispam: BCL:0; x-ms-exchange-crosstenant-network-message-id: 683c37f4-5488-4bff-a510-08da9cf7688a x-ms-exchange-crosstenant-originalarrivaltime: 23 Sep 2022 00:06:05.0805 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: b4d7ee1f-4fb3-4f06-9037-2b5b522042ab x-ms-exchange-transport-crosstenantheadersstamped: BY5PR09MB5666 x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BLAPR09MB7153.namprd09.prod.outlook.com X-Microsoft-Antispam-Mailbox-Delivery: ucf:0;jmr:0;auth:0;dest:I;ENG:(910001)(944506478)(944626604)(920097)(425001)(930097); X-Microsoft-Antispam-Message-Info: YWjclveopigzPPibF5UDsIpVHxI0bt2CjEDXihwSqTWB36mj4FNLAxqY1ZsmQIK2rqzE20a9QXROIYCLLuRMwOP0dzilUcjHAS6z5+g9X/QGcfBrnqFE6WksYVqVs/KJdt9AIe5uIb8B1hzYaHGxqf62Sfz7BYNYOQSHftsrPHEf8RC1S6SYUi+9vEXFBeK4jndNrz0kwtp8cOEHixD58z70mpPz/r7ipF8plg9Za9m+kOCjKJBWqa5Hb13c9W4CboGAK3oYqNz7q+/8j5/Ic5EUxfk+tgBwGNRLSF10DKBXpC11UVMQJkzGsSZ6rVaOTTwOqfcRHUG4Wl0ICRmHz8b6BUgL6pFZ16/TIdRivS92m6x8rzwdLi/AP2QCZMUOA4ObfQ9SNPlb6zpBTgxlLCKQ6WIKjQ1nUlVdo4gWe4TpVsggemygW7Wi9If8aLqjtBDOsI6IoSxdaWg3dEKsuavJTZJnQMTGO/r23W5e8I4HHLCaLZS7SB965FU5e2x9ApGr8bShpLfuKNQPGu5wi/o1dbK7xUp4NvCAh5RR32j+AjAkdQ7vmQxBZNXX2y4ozJh9D5j0HfSP+8kW6ty8hRNf1gbzx5R/YKjRyUH7S7eVGf/n9QgUS7quRTTuwhqLTwoIv/gH/qAiGGLzjwZ6GOPIvhdOPu/B6OdhFd7RXTQ0P9Ot4M6O4lsY7YTKnEgZXbypiwvBJ8OVT5HKggNnDFH++CkNqh++Lu3bQie5me36esXKpPtH7BB21V0YGocsNA4vsKW3MyGaLCpik8mEurYxht3a95J74DFTxB3wXHF43eHS4hYM3SuBGuCJukWKp/64hUQkxQK9SHcdI+ax8jyVzc/+wOwoqMnXg55vr4E= Content-Type: multipart/related; boundary="_004_BLAPR09MB715377A75B89AD4A01FB3785C34E9BLAPR09MB7153namp_"; type="multipart/alternative" MIME-Version: 1.0

--_004_BLAPR09MB715377A75B89AD4A01FB3785C34E9BLAPR09MB7153namp_ Content-Type: multipart/alternative; boundary="_000_BLAPR09MB715377A75B89AD4A01FB3785C34E9BLAPR09MB7153namp_"

--_000_BLAPR09MB715377A75B89AD4A01FB3785C34E9BLAPR09MB7153namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I think I should include the low intensity condition into AC:valid variable= . I believe it needs to be done internally to AC calculations since the val= idity of the calculated numbers has to do with the beam current/radiator co= mbination and the gains of the AC. When the signals on AC are too low (abou= t the same as the pedestals values) the asymmetry calculation becomes probl= ematic, basically it is 0/0 ratio, so based on some cuts the beam positions=

are assigned (0,0). I will include this condition of very low intensity on=
AC into AC:valid.  Hopefully this will cover the TAC normalization running=
as well since then the AC gains are supposed to be raised to be sensitive =

to the photon beam from 1na beam (even from bleedthrough) on a 2x10^-5 rad.=

length radiator.

If the 5C11B BPM is used in the position lock then I guess it=92s reading h= ave to be valid too. What happens when we have 2nA mostly bleedthrough elec= tron beam current during TAC normalization runs? Would it disable the lock?=

Should there be a different BPM enabling condition for these very low lumi=

nosity runs?

Hovanes.

From: Brian Bevins<mailto:bevins@jlab.org> Sent: Thursday, September 22, 2022 3:28 PM To: Brian Freeman<mailto:bfreeman@jlab.org>; Hovanes Egiyan<mailto:hovanes@= jlab.org>; Edith Nissen<mailto:nissen@jlab.org> Cc: Alexandre Deur<mailto:deurpam@jlab.org>; Igal Jaegle<mailto:ijaegle@jla= b.org> Subject: Re: Excursions in Hall D beam positions

The orbit lock does use AC:valid as a status indication for the AC. There s= eems to have been some misunderstanding about what the AC:valid PV means. O= ps set up the PID locks (and I also assumed with the orbit lock) that "vali= d" meant that the positions reported by the AC were usable. It now seems th= at "valid" is a necessary but not sufficient condition to rely on the AC po= sitions if I understand Hovanes correctly. Perhaps adding a current check i= nto the AC:valid computation, or adding a new PV for that purpose, would im= prove the reliability.

The orbit locks do not check beam current directly. They rely on the BPM's = to indicate whether or not beam is present. Since the new lock does use a = BPM in addition to the AC, it won't run if the BPM says no beam is present = even if the AC reads "valid". If IPM5C11B does erroneously light up from up= stream field emission or rf noise, that would be a problem. It can be addre= ssed by raising the wiresum zero threshold for that BPM. That value serves=

as a cutoff such that lower wiresum values are treated as beam off. This m=

ight create problems for very low current runs. But if real beam current is=

so low that it can be confused with field emission, the BPM is probably no=

t reliable anyway. Adding an explicit current check to the lock server can = also be done but will require significant software changes to the server.

--Brian

From: Brian Freeman <bfreeman@jlab.org> Sent: Thursday, September 22, 2022 12:13 PM To: Hovanes Egiyan <hovanes@jlab.org>; Brian Bevins <bevins@jlab.org>; Edit= h Nissen <nissen@jlab.org> Cc: Alexandre Deur <deurpam@jlab.org>; Igal Jaegle <ijaegle@jlab.org> Subject: Re: Excursions in Hall D beam positions

Brian,

Does the new lock look at the AC:valid PV? Does it use anything as a check = for the Active Collimator?

Not sure if you were able to replace the BPM status word that the lock look= s for in the BPMS, with anything for the Active Collimator. If not, It may = be worth adding this. I could see a condition where D beam is off and the 5= C11 BPM sees bleed though noise and indicates "OK", if the Active Collimato= r always appears "OK" too, the it the lock will drive the correctors.

-Brian

From: Hovanes Egiyan <hovanes@jlab.org> Sent: Thursday, September 22, 2022 11:53 AM To: Brian Bevins <bevins@jlab.org>; Brian Freeman <bfreeman@jlab.org>; Edit= h Nissen <nissen@jlab.org> Cc: Alexandre Deur <deurpam@jlab.org>; Igal Jaegle <ijaegle@jlab.org> Subject: Re: Excursions in Hall D beam positions

Hi Brian.

Thanks for looking into this. I can add the beam current to AC:valid condit= ion. I assumed that the beam current is check by the locks separately and A= C:valid was originally introduced to indicate if the AC was in the beam and=

if there is a radiator in the electron beam to produce photons. I can add =

beam current condition to it too, it is easy. That way it will be on us to = set this value properly for TAC normalization runs with almost no beam curr= ent and for normal runs, which makes a lot of sense. This way we will elimi= nate the first type of drifts.

I do not know how damaging this drifts are to the experiments. The current = experiment does not use diamond to produce linearly polarized photons, so i= t is mostly the loss of the statistics, meaning it depends how often this h= appens and how long it lasts. But for most of the GlueX run linearly polari= zed photon beam is used, and the amount and the direction of photon polariz= ation get affected by these shifts. And the polarization enters the figure=

of merit quadratically, but the effect of the shifts on the photon polariz=

ation is not that easy to calculate. We may need to observe this new lock s= etup and see how often this happens with the new lock.

Hovanes.

From: Brian Bevins <bevins@jlab.org> Sent: Thursday, September 22, 2022 11:30 AM To: Hovanes Egiyan <hovanes@jlab.org>; Brian Freeman <bfreeman@jlab.org>; E= dith Nissen <nissen@jlab.org> Cc: Alexandre Deur <deurpam@jlab.org>; Igal Jaegle <ijaegle@jlab.org> Subject: Re: Excursions in Hall D beam positions

Hi Hovanes,

I looked at some archiver data here and I can shed a t least a little light=

on this. Excursions of the first type seem to have been caused by the fact=
that the AC:valid PV continues to indicate that AC positions are valid eve=

n when the beam is off. The PID locks that saw only the AC would thus conti= nue to ramp while the beam was off, giving the large excursion when beam wa= s restored. The new dedicated orbit lock should not exhibit this behavior = since it looks at BPMs as well as the AC and the BPMs always give a correct=

"no beam" indication. The underlying problem with AC:valid should still be=
addressed.

I cannot say what is causing the second excursion, but it is upstream of th= e orbit lock area. The attached plot shows the lock correctors initially be= having as expected after beam resumes. They then make large swings to bring=

the AC and BPM positions back where they should be and eventually drift ba=

ck down to the values they had before the excursion. This sheds no light on=

what causes the excursion, but it does show the lock responding appropriat=

ely, if a bit too slowly to prevent trouble. More aggressive lock gains mig= ht help to mitigate the problem, at the risk of adding steady state noise t= o the beam position.

--Brian

From: Hovanes Egiyan <hovanes@jlab.org> Sent: Thursday, September 22, 2022 9:55 AM To: Brian Freeman <bfreeman@jlab.org>; Brian Bevins <bevins@jlab.org>; Edit= h Nissen <nissen@jlab.org> Cc: Alexandre Deur <deurpam@jlab.org> Subject: Excursions in Hall D beam positions

Hi,

at today's MCC morning meeting I mentioned that we see excursions on the Ha= ll D active collimator as large as 1mm that reduce the photon flux on the t= arget in the hall by quite a bit. Here I show two examples of that, I think=

the origins of these excursions are different. Hopefully they get addresse=

d in this new position lock setup.

The first instance from September 15 you can see as a comment in the log en= try https://logbooks.jlab.org/entry/4041917, but I also made a WAVE URL fo= r it : https://epicsweb.jlab.org/wave/?start=3D2022-09-15+12%3A10%3A31&end=3D2022-= 09-15+12%3A45%3A00&myaDeployment=3Dops&myaLimit=3D100000&windowMinutes=3D30= &title=3D&fullscreen=3Dfalse&layoutMode=3D1&viewerMode=3D1&pv=3DAC%3Ainner%= 3Aposition%3Ax&pv=3DAC%3Ainner%3Aposition%3Ay&pv=3DPSC%3Acoinc%3Ascaler%3Ar= ate&pv=3DMBD5C11BHM&pv=3DMBD5C11BVM&pv=3DIBCAD00CRCUR6&AC%3Ainner%3Apositio= n%3Axlabel=3DAC%3Ainner%3Aposition%3Ax&AC%3Ainner%3Aposition%3Axcolor=3D%23= ff0000&AC%3Ainner%3Aposition%3AxyAxisLabel=3D&AC%3Ainner%3Aposition%3AxyAxi= sMin=3D-2&AC%3Ainner%3Aposition%3AxyAxisMax=3D2&AC%3Ainner%3Aposition%3AxyA= xisLog&AC%3Ainner%3Aposition%3Axscaler=3D&AC%3Ainner%3Aposition%3Aylabel=3D= AC%3Ainner%3Aposition%3Ay&AC%3Ainner%3Aposition%3Aycolor=3D%231f78b4&AC%3Ai= nner%3Aposition%3AyyAxisLabel=3D&AC%3Ainner%3Aposition%3AyyAxisMin=3D-4.0&A= C%3Ainner%3Aposition%3AyyAxisMax=3D0.&AC%3Ainner%3Aposition%3AyyAxisLog&AC%= 3Ainner%3Aposition%3Ayscaler=3D&PSC%3Acoinc%3Ascaler%3Aratelabel=3DPSC%3Aco= inc%3Ascaler%3Arate&PSC%3Acoinc%3Ascaler%3Aratecolor=3D%23b2df8a&PSC%3Acoin= c%3Ascaler%3ArateyAxisLabel=3D&PSC%3Acoinc%3Ascaler%3ArateyAxisMin=3D&PSC%3= Acoinc%3Ascaler%3ArateyAxisMax=3D&PSC%3Acoinc%3Ascaler%3ArateyAxisLog=3D&PS= C%3Acoinc%3Ascaler%3Aratescaler=3D&IBCAD00CRCUR6label=3DIBCAD00CRCUR6&IBCAD= 00CRCUR6color=3D%23e31a1c&IBCAD00CRCUR6yAxisLabel=3D&IBCAD00CRCUR6yAxisMin=

3D0&IBCAD00CRCUR6yAxisMax=3D300&IBCAD00CRCUR6yAxisLog&IBCAD00CRCUR6scaler

=3D

The 5C11B corrector magnets seem to drift when there is no beam, and when = the beam is turned on the position are off, the vertical is off by over 3mm=

and the photon beam does not get through the collimator at all, as the bot=

tom plot for the pair spectrometer rate shows.

The second instance from September 20th shows when the beam comes back afte= r a trip at more or less OK positions but for some reason drifts by a larg= e amount before it comes back to the nominal positions. The vertical shift=

is about 2mm. You can see it on this WAVE page:

https://epicsweb.jlab.org/wave/?start=3D2022-09-20+04%3A45%3A31&end=3D2022-= 09-20+05%3A15%3A31&myaDeployment=3Dops&myaLimit=3D100000&windowMinutes=3D30= &title=3D&fullscreen=3Dfalse&layoutMode=3D1&viewerMode=3D1&pv=3DAC%3Ainner%= 3Aposition%3Ax&pv=3DAC%3Ainner%3Aposition%3Ay&pv=3DPSC%3Acoinc%3Ascaler%3Ar= ate&AC%3Ainner%3Aposition%3Axlabel=3DAC%3Ainner%3Aposition%3Ax&AC%3Ainner%3= Aposition%3Axcolor=3D%23ff0000&AC%3Ainner%3Aposition%3AxyAxisLabel=3D&AC%3A= inner%3Aposition%3AxyAxisMin=3D-1.5&AC%3Ainner%3Aposition%3AxyAxisMax=3D1.5= &AC%3Ainner%3Aposition%3AxyAxisLog&AC%3Ainner%3Aposition%3Axscaler=3D&AC%3A= inner%3Aposition%3Aylabel=3DAC%3Ainner%3Aposition%3Ay&AC%3Ainner%3Aposition= %3Aycolor=3D%231f78b4&AC%3Ainner%3Aposition%3AyyAxisLabel=3D&AC%3Ainner%3Ap= osition%3AyyAxisMin=3D-3.0&AC%3Ainner%3Aposition%3AyyAxisMax=3D0.&AC%3Ainne= r%3Aposition%3AyyAxisLog&AC%3Ainner%3Aposition%3Ayscaler=3D

The green graph on the bottom indicates how much the photon flux going thro= ugh the collimator is reduced due to the position shifts.

In both cases the positions drifts are large enough for the large portion o= f the beam to miss the target in the hall because it is blocked by the coll= imator. I think the first case can be address by improving the condition fo= r the AC lock being enabled. I do not know what happened in the second case=

that caused such a drift, other locks could have affected the AC positions=
before it got restored. Hopefully these cases can improve too.

Hovanes.

--_000_BLAPR09MB715377A75B89AD4A01FB3785C34E9BLAPR09MB7153namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I think I should include the low intensity condition = into AC:valid variable. I believe it needs to be done internally to AC calc= ulations since the validity of the calculated numbers has to do with the beam current/radiator combination and the gains= of the AC. When the signals on AC are too low (about the same as the pedes= tals values) the asymmetry calculation becomes problematic, basically it is= 0/0 ratio, so based on some cuts the beam positions are assigned (0,0). I will include this condition of ve= ry low intensity on AC into AC:valid. Hopefully this will cover the T= AC normalization running as well since then the AC gains are supposed to be= raised to be sensitive to the photon beam from 1na beam (even from bleedthrough) on a 2x10^-5 rad. length radia= tor.

If the 5C11B BPM is used in the position lock then I = guess it=92s reading have to be valid too. What happens when we have 2nA mo= stly bleedthrough electron beam current during TAC normalization runs? Would it disable the lock? Should there be a diffe= rent BPM enabling condition for these very low luminosity runs?

Hovanes.

From: Brian Bevins
Sent: Thursday, September 22, 2022 3:28 PM
To: Brian Freeman; Hovanes Egiyan; Edith Nissen
Cc: Alexandre Deur; Igal Jaegle
Subject: Re: Excursions in Hall D beam positions

The orb= it lock does use AC:valid as a status indication for the AC. There seems to= have been some misunderstanding about what the AC:valid PV means. Ops set = up the PID locks (and I also assumed with the orbit lock) that "valid" meant that the positions repor= ted by the AC were usable. It now seems that "valid" is a necessa= ry but not sufficient condition to rely on the AC positions if I understand= Hovanes correctly. Perhaps adding a current check into the AC:valid computation, or adding a new PV for that purpose, would impro= ve the reliability.

&n= bsp;

The orb= it locks do not check beam current directly. They rely on the BPM's to indi= cate whether or not beam is present. Since the new lock does use a BP= M in addition to the AC, it won't run if the BPM says no beam is present even if the AC reads "valid". If= IPM5C11B does erroneously light up from upstream field emission or rf nois= e, that would be a problem. It can be addressed by raising the wiresum zero= threshold for that BPM. That value serves as a cutoff such that lower wiresum values are treated as beam off. This m= ight create problems for very low current runs. But if real beam current is= so low that it can be confused with field emission, the BPM is probably no= t reliable anyway. Adding an explicit current check to the lock server can also be done but will require signifi= cant software changes to the server.

&n= bsp;

--Brian=

&n= bsp;

From: Brian Freeman <bfreeman@jlab.org>
Sent: Thursday, September 22, 2022 12:13 PM
To: Hovanes Egiyan <hovanes@jlab.org>; Brian Bevins <bevins= @jlab.org>; Edith Nissen <nissen@jlab.org>
Cc: Alexandre Deur <deurpam@jlab.org>; Igal Jaegle <ijaegle= @jlab.org>
Subject: Re: Excursions in Hall D beam positions <= /p>

Brian,

Does the new lock look at the AC:valid PV? Does it use = anything as a check for the Active Collimator?

Not sure if you were able to replace the BPM status wor= d that the lock looks for in the BPMS, with anything for the Active Collima= tor. If not, It may be worth adding this. I could see a condition where D beam is off and the 5C11 BPM sees bleed th= ough noise and indicates "OK", if the Active Collimator always ap= pears "OK" too, the it the lock will drive the correctors.

-Brian

From: Hovanes Egiyan <hovanes@jlab.org>
Sent: Thursday, September 22, 2022 11:53 AM
To: Brian Bevins <bevins@jlab.org>; Brian Freeman <bfreeman= @jlab.org>; Edith Nissen <nissen@jlab.org>
Cc: Alexandre Deur <deurpam@jlab.org>; Igal Jaegle <ijaegle= @jlab.org>
Subject: Re: Excursions in Hall D beam positions <= /p>

Hi Bria= n.

&n= bsp;

Thanks = for looking into this. I can add the beam current to AC:valid condition. I = assumed that the beam current is check by the locks separately and AC:valid= was originally introduced to indicate if the AC was in the beam and if there is a radiator in the electron beam = to produce photons. I can add beam current condition to it too, it is easy.= That way it will be on us to set this value properly for TAC normalization= runs with almost no beam current and for normal runs, which makes a lot of sense. This way we will eliminat= e the first type of drifts.

&n= bsp;

I do no= t know how damaging this drifts are to the experiments. The current experim= ent does not use diamond to produce linearly polarized photons, so it is mo= stly the loss of the statistics, meaning it depends how often this happens and how long it lasts. But for most of t= he GlueX run linearly polarized photon beam is used, and the amount and the= direction of photon pola= rization get affected by these shifts. And the polarization enters the figure of merit quadratically, but the effect = of the shifts on the photon polarization is not that easy to calculate. We = may need to observe this new lock setup and see how often this happens with= the new lock.

&n= bsp;

Hovanes= .

&n= bsp;

From: Brian Bevins <bevins@jlab.org>
Sent: Thursday, September 22, 2022 11:30 AM
To: Hovanes Egiyan <hovanes@jlab.org>; Brian Freeman <bfree= man@jlab.org>; Edith Nissen <nissen@jlab.org>
Cc: Alexandre Deur <deurpam@jlab.org>; Igal Jaegle <ijaegle= @jlab.org>
Subject: Re: Excursions in Hall D beam positions <= /p>

Hi Hova= nes,

&n= bsp;

I looke= d at some archiver data here and I can shed a t least a little light on thi= s. Excursions of the first type seem to have been caused by the fact that t= he AC:valid PV continues to indicate that AC positions are valid even when the beam is off. The PID locks that = saw only the AC would thus continue to ramp while the beam was off, giving = the large excursion when beam was restored. The new dedicated orbit l= ock should not exhibit this behavior since it looks at BPMs as well as the AC and the BPMs always give a correc= t "no beam" indication. The underlying problem with AC:valid shou= ld still be addressed.

&n= bsp;

I canno= t say what is causing the second excursion, but it is upstream of the orbit= lock area. The attached plot shows the lock correctors initially behaving = as expected after beam resumes. They then make large swings to bring the AC and BPM positions back where they s= hould be and eventually drift back down to the values they had before the e= xcursion. This sheds no light on what causes the excursion, but it does sho= w the lock responding appropriately, if a bit too slowly to prevent trouble. More aggressive lock gains might h= elp to mitigate the problem, at the risk of adding steady state noise to th= e beam position.

&n= bsp;

--Brian=

&n= bsp;

From: Hovanes Egiyan <hovanes@jlab.org>
Sent: Thursday, September 22, 2022 9:55 AM
To: Brian Freeman <bfreeman@jlab.org>; Brian Bevins <bevins= @jlab.org>; Edith Nissen <nissen@jlab.org>
Cc: Alexandre Deur <deurpam@jlab.org>
Subject: Excursions in Hall D beam positions

Hi,&nbs= p;

&n= bsp;

at toda= y's MCC morning meeting I mentioned that we see excursions on the Hall D ac= tive collimator as large as 1mm that reduce the photon flux on the target i= n the hall by quite a bit. Here I show two examples of that, I think the origins of these excursions are differen= t. Hopefully they get addressed in this new position lock setup. =

&n= bsp;

The fir= st instance from September 15 you can see as a comment in the log entry&nbs= p;https://logbooks.jlab= .org/entry/4041917, but I also made a WAVE URL for it :

https:/= /epicsweb.jlab.org/wave/?start=3D2022-09-15+12%3A10%3A31&end=3D2022-09-= 15+12%3A45%3A00&myaDeployment=3Dops&myaLimit=3D100000&windowMin= utes=3D30&title=3D&fullscreen=3Dfalse&layoutMode=3D1&viewer= Mode=3D1&pv=3DAC%3Ainner%3Aposition%3Ax&pv=3DAC%3Ainner%3Aposition%= 3Ay&pv=3DPSC%3Acoinc%3Ascaler%3Arate&pv=3DMBD5C11BHM&pv=3DMBD5C= 11BVM&pv=3DIBCAD00CRCUR6&AC%3Ainner%3Aposition%3Axlabel=3DAC%3Ainne= r%3Aposition%3Ax&AC%3Ainner%3Aposition%3Axcolor=3D%23ff0000&AC%3Ain= ner%3Aposition%3AxyAxisLabel=3D&AC%3Ainner%3Aposition%3AxyAxisMin=3D-2&= amp;AC%3Ainner%3Aposition%3AxyAxisMax=3D2&AC%3Ainner%3Aposition%3AxyAxi= sLog&AC%3Ainner%3Aposition%3Axscaler=3D&AC%3Ainner%3Aposition%3Ayla= bel=3DAC%3Ainner%3Aposition%3Ay&AC%3Ainner%3Aposition%3Aycolor=3D%231f7= 8b4&AC%3Ainner%3Aposition%3AyyAxisLabel=3D&AC%3Ainner%3Aposition%3A= yyAxisMin=3D-4.0&AC%3Ainner%3Aposition%3AyyAxisMax=3D0.&AC%3Ainner%= 3Aposition%3AyyAxisLog&AC%3Ainner%3Aposition%3Ayscaler=3D&PSC%3Acoi= nc%3Ascaler%3Aratelabel=3DPSC%3Acoinc%3Ascaler%3Arate&PSC%3Acoinc%3Asca= ler%3Aratecolor=3D%23b2df8a&PSC%3Acoinc%3Ascaler%3ArateyAxisLabel=3D&am= p;PSC%3Acoinc%3Ascaler%3ArateyAxisMin=3D&PSC%3Acoinc%3Ascaler%3ArateyAx= isMax=3D&PSC%3Acoinc%3Ascaler%3ArateyAxisLog=3D&PSC%3Acoinc%3Ascale= r%3Aratescaler=3D&IBCAD00CRCUR6label=3DIBCAD00CRCUR6&IBCAD00CRCUR6c= olor=3D%23e31a1c&IBCAD00CRCUR6yAxisLabel=3D&IBCAD00CRCUR6yAxisMin= =3D0&IBCAD00CRCUR6yAxisMax=3D300&IBCAD00CRCUR6yAxisLog&IBCAD00C= RCUR6scaler=3D

&n= bsp;

The&nbs= p; 5C11B corrector magnets seem to drift when there is no beam, and when th= e beam is turned on the position are off, the vertical is off by over 3mm a= nd the photon beam does not get through the collimator at all, as the bottom plot for the pair spectrometer rate shows= .

&n= bsp;

The sec= ond instance from September 20^th shows when the beam comes = back after a trip at more or less OK positions but for some reason dr= ifts by a large amount before it comes back to the nominal positions. The vertical shift is about 2mm. You can see = it on this WAVE page:

&n= bsp;

The gre= en graph on the bottom indicates how much the photon flux going through the= collimator is reduced due to the position shifts. <= /p>

<= o:p>

In both= cases the positions drifts are large enough for the large portion of the b= eam to miss the target in the hall because it is blocked by the collimator.= I think the first case can be address by improving the condition for the AC lock being enabled. I do not know wh= at happened in the second case that caused such a drift, other locks could = have affected the AC positions before it got restored. Hopefully these case= s can improve too.

<= o:p>

Hovanes= .

--_000_BLAPR09MB715377A75B89AD4A01FB3785C34E9BLAPR09MB7153namp_--

--_004_BLAPR09MB715377A75B89AD4A01FB3785C34E9BLAPR09MB7153namp_ Content-Type: image/png; name="BF65DD6E0DC44AC9A70750561530BDFC.png" Content-Description: BF65DD6E0DC44AC9A70750561530BDFC.png Content-Disposition: inline; filename="BF65DD6E0DC44AC9A70750561530BDFC.png"; size=504; creation-date="Fri, 23 Sep 2022 00:06:04 GMT"; modification-date="Fri, 23 Sep 2022 00:06:08 GMT" Content-ID: <image002.png@01D8CEBE.BE668ED0> Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAArYAAAADCAYAAABmm0wDAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAA0SURBVGhD7dZBCQAwDATB+DdVBVUQMSn0GQcH szAets7tAQCAdH9sS5IkSUpvny4AAOTpeVQ/cX0X8qc8AAAAAElFTkSuQmCC

--_004_BLAPR09MB715377A75B89AD4A01FB3785C34E9BLAPR09MB7153namp_--

Excursions in Hall D beam positions

3D0&IBCAD00CRCUR6yAxisMax=3D300&IBCAD00CRCUR6yAxisLog&IBCAD00CRCUR6scaler

Navigation menu

Views

Personal tools

Navigation

Search

Tools