Excursions in Hall D beam positions
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.
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.
--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>; Edith 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 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
Hi Bria=
n.
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.
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.
Hovanes=
.
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
Hi Hova=
nes,
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.
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.
--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>; Edith Nissen <nissen@jlab.org>
Cc: Alexandre Deur <deurpam@jlab.org>
Subject: Excursions in Hall D beam positions
Hi,&nbs=
p;
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.
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
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=
.
The sec=
ond instance from September 20th 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:
The gre=
en graph on the bottom indicates how much the photon flux going through the=
collimator is reduced due to the position shifts.
<= 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_--