1. 20 September 2000 LHC slow timing implementations brainstorming on slow timing Wednesday 20 September M.Jonker

2. 20 September 2000 LHC slow timing implementations See also... \\srv2_home\usr_f2j\Home\Jonker\Presentations LHC timing working group l LHC slow timing implementations, Friday 1 September, M.Jonker l LHC Slow Timing Requirements for operations Friday 27 August M.Jonker & M.Lamont l SPS LEP LHC timing Friday 12-may-1999, M.Jonker Conclusion: LHC timing requirements reflect very much the requirements for LEP, however, does this mean that we need the MTG timing network? RT working group brainstorming l RT control issues and architecture April-2000, M.Jonker Unpublished l Slow timing over ‘common purpose’ network media

3. 20 September 2000 LHC slow timing implementations The users In LEP: l Power converters l RF equipment during filling (Nope! they were driven by the SPS timing!) l RF during the ramp l Separators l BI measurement (through the BST) l Experiments l Beam dump l Kickers? Huh, were they driven by slow timing?

4. 20 September 2000 LHC slow timing implementations The events Only a few critical events were needed: l Start ramp l Do trim (a-sync set) l Notes: –The PC group had even oversimplified this and made the two events equal. –With the inclusion of a stop vector in the ramp command, the stop ramp event became almost obsolete. (if not for the PC, and the emergency stop option). So should we base our control system on a one event timing system? l No, definitely not. We found some more potential usage of timing events –Communication with experiments (mini ramps, vernier scans) –K-modulation –RT knobs (Almost as k-modulation but I should have insisted on it with the PC group ) –Concurrent trims (only in our dreams) –Measurement procedures (I.e. inject & dump, Q’ measurement)

5. 20 September 2000 LHC slow timing implementations Requirements and Issues Number of distinct events: –Currently 2 16 but why not 2 32 ? Bare minimum 256 or even lower? Do we know what ideas may come up in the future. Time slots size: –Currently 1 ms, but we could settle for larger values e.g. 10 ms, provided the event includes a delay within the time slot. Number of events per time slot ? –Depends on what you want to do with it. (E.g. for K-modulation in LEP 3 events per ms was just ok for 16 frequencies). Latency before event delivery ? –LEP 100 ms, but will we have many ‘unscheduled’ transactions? (I.e. beam dump, emergency stop)? Reliability of delivery ? –Can we tolerate missing event delivery? (LEP ok, but LHC is a different story) –Do we need a two way system? (I.e. acknowledgement of reception?)

6. 20 September 2000 LHC slow timing implementations LHC slow timing Possible ways to implement LHC slow timing l Classical l BST based l Based on absolute time l ‘Irradication’ I.e. replaced by RT system

7. 20 September 2000 LHC slow timing implementations LHC slow timing Classical l Standard MTG and TG8’s l Timing distribution into the alcoves (Cabling) l Equipment groups to sort out how to distribute timing into the tunnel (if at all needed). l Minimal software effort l No hardware development

8. 20 September 2000 LHC slow timing implementations LHC slow timing BST based l Use BI-BST distribution system to distribute slow timing messages. Synchronization is provided by GPS time. Lep equivalent: bandwidth of 64 Kbit. l Some HW development to feed MTG events into BST (Synchronisation with ms tick from GPS time) l Use BI developed equipment to pick up BST signals l Some software effort l Hardware development for slow timing receivers

9. 20 September 2000 LHC slow timing implementations LHC slow timing Based on absolute time l Use GPS absolute time for synchronization and send messages over Ethernet, WorldFip fieldbus l PC group will solve the problem? l HW development to create new timing receiver modules that work on the WorldFip bus. l Major software effort –create MTG equivalent –provide reliability

10. 20 September 2000 LHC slow timing implementations LHC slow timing Replaced by RT system l Best solution: No more problems for slow timing Injection related slow timing signals can be generated by the SPS slow timing system. It is already foreseen to distribute these signals to the LHC-RF. For timing events during the ramp see later note: l Do we need an RT system anyway for feedback and RT knobs? l Or will we use slow timing for feedback and RT knobs? This needs an investigation of what a RT control system is and the functional needs.

11. 20 September 2000 LHC slow timing implementations LHC slow timing Note on RT systems l RT does not imply fast fancy and expensive. l RT means predictable latency. l Example the RT system for –Weather forecasting –LHC control –Rapid cycling accelerator They may have all a real time control system, however, the bandwidth maybe different. l LHC control needs to be reliable, this could interfere with predictable latency.

12. 20 September 2000 LHC slow timing implementations LHC conclusions l If you are going to do something fancy, try the slow timing ‘irradication’ first (use of RT system). This need a detailed study of the RT architecture, independent of the implementation (Ethernet, ATM,...). (Slide from RT workshop) l BST options seems to be very promising, it has the advantage to distribute the events signals also to the experiments. l Otherwise, best bet is the classical system.

13. 20 September 2000 LHC slow timing implementations Some more comments l What the timing will deliver. l Local timing distribution from the alcoves to the equipment in the tunnel. l Fallback solutions in case something goes wrong. l How to satisfy the RF l Development of common hardware.

14. 20 September 2000 LHC slow timing implementations What the timing will deliver. l Programmable modules that provide hardware signals and/or VME software interrupts. These signals are triggered by messages that are broadcast from a common source (Master Timing Generator or equivalent) l The messages are tightly linked to the ms clock of the GPS. Or the 10 ms clock of the WorldFip?

15. 20 September 2000 LHC slow timing implementations Local timing distribution l Local timing distribution from the alcoves to the equipment in the tunnel is responsibility of the equipment groups? After discussion with Quentin: l If the local timing distribution over worldfip does not provide the required reliability, then either: –the PC should have a way to fire the beam dump, or –the local timing trigger should be distributed by a separate cable. But these are not timing problems (unless the timing uses an unreliable communication system itself, in which case we will have a common problem).

16. 20 September 2000 LHC slow timing implementations Fallback solutions in case something goes wrong. l Important in case the timing is bases on an unreliable message delivery system (e.g. ethernet). Complete new philosophy of timing distributions: –MTG will needs to know who its clients are and how critical they are. –Clients will have to register their interest and criticality in timing events with the MTG. –In case of non acknowledged message, the MTG will call the beam dump. –(note: this start to look like RT timing - feedback)

17. 20 September 2000 LHC slow timing implementations How to satisfy the RF or more in particular Ph.Baudrengien l See also the slide on “What the timing will deliver”. l How we will deliver it (and more in particular whether a TG3 is most suitable) is part of the solution, not the requirements. l Timing events during injection: –During injection the LHC is slave of the SPS, hence like in LEP, the injection can be driven from the SPS timing.

18. 20 September 2000 LHC slow timing implementations How to satisfy the RF l Timing events during the ramp: (Proposal) –Use digital function generators for all that is ‘function driven’ Nothing new, just like the SPS Rocks/Mugef’s. –Study the remaining timing events that are needed during the ramp. –My guess: most of these events are linked to energy or some other machine parameter. Output-A ::= @ energy=500GeV –Develop a version of the digital function generator in which one can load functions. The output is used to trigger logical conditions. –Hence events are generated with respect to the loaded function: l a linear ramp-time function:  events as a function of the ramp time, l energy function:  events as a function of the energy, l bucket size function:  events as a function of the bucket size function Programming of RF timing events becomes ‘deterministic’

19. 20 September 2000 LHC slow timing implementations How to satisfy the RF l Timing events during the ramp: (Proposal) Condition 1 Condition 2 Condition 3 etc... Out 1 Out 2 Out 3 Out etc Start Ramp Digital output Loaded function e.g. energy: Loaded condition table:

20. 20 September 2000 LHC slow timing implementations Development of common hardware l Development of common hardware. l Digital function generators everywhere as the basis of control? l This should also include the generation for the reference settings in local feedback loops! (I.e. radial position in SPS is a good example, LEP Q-loop is a bad example).