180 likes | 191 Views
This article provides a user perspective on tune and orbit feedbacks in the context of the Evian 2011 run, including statistics, issues, solutions, and improvements for 2012. It also explores the use of feed-forward strategies and the problem with the H plane.
E N D
Tune and Orbit Feedbacks perfomances: A user perspective L. Ponce On behalf of the OP team Special thanks for discussions to Joerg, Ralph, Marek and Wolfgang
Outline • Some statistics over the year (OP point of view) • Status and major issues: • QPS trip • Tune measurement • The OFB H plane • Feed-forward strategy Evian 2011
Evian 2011 Some statistics • Total 131 dumps when feedbacks are ON (ramp + squeeze): • 33 dumps attributed to Feedbacks • Distribution by machine modes:
Dump reasons • 3 main causes: • Triggering of trim quadrupoles (RQTF/D) QPS • Wrong references sent to FB controllers • Instabilities of the tune measurement: • Tune FB driving tunes to third order resonance (beam dumped by BLM) during the squeeze • Orbit FB not correcting (dump by SIS) during the ramp • Large majority of the dumps due to QPS trips: Evian 2011
Wrong references • Since beginning of the run, both orbit and tune feedback are sequencer driven • Settings stored in LSA • Most of the errors came when cloning hypercycles for MDs and in BEAM SETUP mode => need test, consistency checks, more discipline Evian 2011
QPS trips • QPS is triggered by the real time trims sent by the tune feedback oscillating or too large • Above 50 A, QPS triggered if U_res is > 100 mV for more than 190 ms • Typical case : signal oscillating around the threshold. Evian 2011
1st solution : increase threshold? • New simulations of the protection system showed that threshold could be relaxed (see R. Denz talk). • Present strategy: bellow 50A, Ures threshold is at 2V and decrease to 100 mV above 50 A • Proposed change: keep the threshold at 2 V till 100 A, providing current is limited to 200 A on the hardware level • Should avoid problem for 2012 • But still not enough for higher energy. Evian 2011
2nd solution : reduce «noise» • Test during ions run: Tune FB response bandwidth has been reduced by a factor 5 • To be seen if it is also possible with protons, especially after FF? • High gain was motivated by initial specification of keeping dQ < 0.001 => could it be relaxed? response bandwidth reduced by a factor 5: Evian 2011
Evian 2011 Tune measurement • 2 different problems: ADT on (max gain) ADT off • S/N ratio = multiple peaks • Tune peak damped • BBQ vs ADT settings • Saturation = peak disappearing • High bunch intensity • Internal limitation of the system
Improvements for 2012 • Saturation effect appeared with the increase of bunch intensities above nominal. • For next year, dynamic range will be adapted for higher bunch intensities. • HW modification to allow remote settings (no more access needed) • Could lead to less sensibility for the pilot => should not be a problem anymore for 2012 run • Problem of tune measurement : ADT vs BBQ war! • CHIRP could be used to enhance the tune peak (MPP for high intensity ?) • More set-up time to study compatible settings for ADT and BBQ • Other mean for tune measurement : ADT signal for Q measurement, gating... Evian 2011
ADT + BBQ Gating • At the end of 2011 run, bunch gating for ADT has been successfully tested : • Principle is to disable the ADT for defined bunch train • Problem: BBQ signal sensitive to bunch intensity, the more intense bunches contribute more to tune signal • ADT gating tested on train with 20% more bunch intensity • could use the first 12 bunches and guarantee increased bunch intensity on these bunches? • To be used in nominal operation, ADT gating should be combined with BBQ gating: • Not fully ready yet, to be tested at the beginning of next run Evian 2011
3rd solution : switch OFF QFB • Several fills (difficult to trace in the statistics) were put in physics with FB OFF (~ 10 with ions, several fill when increasing bunch intensities) • To avoid big trims/oscillations when the tune signal is not stable/too low. • Automatic with tune stability measurement : self-protection in the QFB • Operators decision Evian 2011
Feed-forward vs feedback • The extreme solution to switch OFF tune feedback during ramp or squeeze is OK provided that the bigger part of the Real Time corrections have been incorporated in the functions • FF regularly done during commissioning of the beam processes. • Incorporation of the RT corrections into functions at the matched points • For the orbit corrections, FF regularly done in V plane: • Reduction of the strength of the RT trims from 10 to 3 µrad • more difficult in H (see next slide) Evian 2011
FF during ALICE squeeze Courtesy of N. Ryckx Evian 2011
Problem with H plane • Orbit feedback is “pushing” up the orbit : H tune is drifting. • Q feedback needed to compensate: QFB cannot be switched OFF • Origin not yet understood • Cannot feedforward the corrections • Cannot switch off the feedback Evian 2011
High gain test of OFB • Detailed presentation by J. Wenninger at LBOC • Orbit excursion spikes are clearly visible, especially during the squeeze: • Becoming a problem (losses) when trying tight collimators settings • When investigating possible cures, test with higher gain of OFB have been performed: • Rather successful in the first part of the squeeze where FF was performed • But driving instabilities in the squeeze of IR2 to 1m (beam dumped) • As a result of the test, possible to envisage the following sequence: • Perform a test squeeze with high gain (low intensity) • Apply FF based on the high gain test • If successful, operate the OFB with lower gain for high intensity Evian 2011
Requests for 2012 • From Feedback expert side: • TIME to optimize settings at each significant step in the commissioning • MD time (see BI MD requests) • From OP side: • More transparency on used settings • Some GUI modifications to ease the operation • Distinction between on-demand and continuous • Direct access to signals seen by the FB • From both side: • Software release and test procedure • Test time allocated after new software version deployment Evian 2011
Summary • Feedbacks saved more fills than they dumped: we cannot leave without it • Most of the dumps we had in 2011 should be avoided next year thanks to : • Change of QPS thresholds to avoid RQTs trips • HW modifications to avoid BBQ saturation => Should be left with 2-3 dumps! but what will we found if beams not dumped? • Proposal to improve tune measurement to be tested at the beginning of the run : ADT gating in combination with BBQ gating • Problem with real time trims in H plane to be sorted out to allow FF, already exploited as much as we could in 2011. Evian 2011