This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern for current CERN information.
Requirements specification circa September 2007
Notes from LHC tune software meeting Monday, January 22, 2007.
The BBQ system is the standard LHC tune meter. We will have a dedicated pick-up fitted with a BBQ front-end, which is just used to give continuous tune spectra using either Q-kicker, damper or residual excitation.
The LHC Tune PLL system will also use a BBQ front-end to provide the tune data, but will then have a digital PLL implemented within the digital acquisition part of the chain. Excitation for the PLL is either via the damper or dedicated BI stripline "beam ticklers". The PLL system will use different pick-ups from the ones used for standard tune measurement.
One imagines a tune "application" providing panels for device configuration/setup & measurement displays for:
Priority in that order. Re-using tools from SPS development would be reasonable but development of a generic cross-accelerator tool would appear not to be a good idea.
With further, shall we say, commissioning requirements (RS):
Will also need a "deamon" process for background acquistion and, possible processing to feed fixed displays and logging systems.
Essential requirements:
For example, LEP Tune feedback
Questions from JP...
Is what you are looking for a standard control system interface with a FESA front-end and Java/LSA applications?
Yes - we would expect the GUIs to use standard LSA components, FESA and the LSA middle tier where appropriate - this for maintainability primarily.
If so, are you looking for help just with the Java application(s), or with the front-end as well?
The front-end side of things is being taking care of by the Beam instrumentation group in collaboration with BNL. This is the standard CERN split. The tracker is reasonably complicated so the interaction with BI will be an important one.
If so, what is the desired functionality of the Java applications? Some subset of the expert Labview system that would be appropriate for use by operators? Or is the intention that the Labview system will eventually be replaced and so the controls applications assume the complete Labview functionality?
Normally the high level application would only expose a subset of the full system - appropriate for routine control room use - we need to talk this through with BI - they are controlling the PLL in LabView at the moment (gains, delays etc.). Whether they'd want us to provide the ability to twiddle loop parameters (for example) at the top end would need to be checked with them.
It is our understanding for early commissioning a single kick excitation method
using the regular BPM system and also higher resolution dedicated BPMs with
BBQ readout will be used. Is this being covered by others?
BPMs will probably only be used to get a rough handle on the tune. This is
covered.
The BBQ system is the standard LHC tune meter. The BBQ itself is basically a very sensitive front-end acquisition system. We will have a dedicated pick-up fitted with a BBQ front-end, which is just used to give continuous tune spectra using either Q-kicker, damper or residual excitation. Any application has to interface to exciters.
The LHC Tune PLL system will also use a BBQ front-end to provide the tune data, but will then have a digital PLL implemented within the digital acquisition part of the chain. Excitation for the PLL is either via the damper or dedicated BI stripline "beam ticklers". The PLL system will use different pick-ups from the ones used for standard tune measurement.
These two are not covered by others.
Is the PLL system the baseline for stabilizing the tune up the ramp?
Absolutely... we would hope to have an essentially turn key PLL system ready
to go at start-up. Initially plan to use feed forward from PLL measurements
to stabilize the tunes enough to get low intensity beam up the ramp, but would
hope to close the loop pretty quickly.