Feedbacks from EN/STI A. Masi On behalf of EN-STI Mathieu Donze` Odd Oyvind Andreassen Adriaan Rijllart Paul Peronnard Salvatore Danzeca Mario Di Castro Mark Butcher

Scope LHC Collimators FESA class upgrade to FESA 3 Beam Stoppers consolidation project RADMON ver. 6 FESA 3 class AD target controls consolidation North Area Targets controls consolidation Recommissioning movable devices in injectors chain, LHC and experimental area Hardware commissioning LabView tools

Machine Control Coordinators (MCC) BE-CO reference person for controls services need, commissioning coordination, periodical check of the development plan Dry runs Good activities coordination. The BE-CO organization ensured that all the needed services were available in time for the dry- run Smooth Upgrades Good initiative. It allowed the impact of controls upgrades on our equipment to be evaluated. The same model can be used for a new FESA release to check the backward compatibility What worked well in LS1

FESA 3 LHC Collimator FESA class was the first one to be migrated to FESA 3 FESA 3 was available in a stable release to be used for development only well after the beginning of the LS1 The first release on 22/05/2013 was not really usable for the development because of lack of tools (i.e. migration tools, CCDB editor) The LHC collimator class upgrade started with the version The upgrade was not smooth. Migration with automatic tool failed. We decided for a complete re-development to take advantage also of the new features (i.e. rolling buffer). Several bugs slowed down the development (e.g. FESA-5659, FESA- 5110, FESA-5088, FESA-4536, FESA-4333, FESA-4286). LHC Collimator class was a good Beta tester for the new FESA 3 !!!!FESA-5659FESA- 5110FESA-5088FESA-4536FESA-4333FESA-4286 What could have worked better

RDA 3 One of the main motivation for the LHC Collimator FESA class migration to FESA 3 was the resolution of the “slow clients” issue The first FESA 3 release with RDA3 support was released only on 18/08/2014 The Machine Critical Settings were supported only on 20/03/2015 with the FESA release !!!! What could have worked better

Front-ends upgrades The replacement of the old front-ends with the new ones and the consequent migration to SLC6 64 bit came only at the end of the LS1- LHC Collimators: only few months to test the software (i.e. Bug discovered during the commissioning on the DIM library compiled for 64 bit) RADMON: Installation and commissioning of the new devices in the injectors only at the last minute What could have worked better

Timber API to access Timber via LabView very slow- This issue had a direct impact on the speed of the Hardware commissioning !!!! Problems experienced for many years. It was an intermittent fault, reported in CALS-2709, CALS-2649 and with several s sent by ICE-MTA section and the hardware commissioning team (i.e. on , , , , , ) The issue was definitively fixed at the End of February 2015 at the end of the hardware commissioning !!! What could have worked better

Generic feedbacks Robotics projects (i.e. TIM) would appreciate to have Timber working for devices on GPN. A VPN on 3G mobile network is used for communication. This solution is available only on GPN. It would be really helpful to have a BE-CO test environment (i.e. clone on Open Stack) available on GPN to validate new developments on laboratory devices FESA navigator not an ideal tool for generic viewer. Could it be improved in the future ? What could have worked better

Generic feedbacks In addition to the official FESA course the old style on-site trainings would be highly appreciated – Documentation to be improved on the web site Dedicated and not shared FESA development machines would have reduced compilation time What could have worked better

Planning, communication and follow-up: Generally good. It was important the coordination work to ensure all the services available for the dry-runs Tools and processes: Jira and s tools were adequate. More flexibility on the FESA bug resolution would have been accepted EN-STI influence on setting deadlines: Negligible. To be improved (i.e. MCS support in RDA3) Planning & organisation

CO impact on our activities: LHC Collimator migration to FESA 3 and RDA 3 as well as RADMON new FESA 3 class development suffered from the immaturity of the new framework FESA Eclipse plugin, it’s not very user-friendly – time lost to fill-in the XML file Communication: Not clear backward compatibility or impact of new release of FESA 3 and RDA 3 Often bug fix is coupled with a new release For instance the concept of device Id was introduced with the FESA 3 release (2.3.0 plug in). This represented for us a big issue of backward compatibility since we were no longer anymore to use our automatic automatic FESA instantiation files generators (mandatory to apply modification on the instantiation of more than 500 devices) Quality and testing of the implemented changes: Many bugs discovered in FESA 3 gave the feeling that the validation is not performed on complex user cases – The test cases should be more representative Technical

BE-CO timeline and deadlines to develop big changes cannot be the same as the equipment groups. New changes have to be released in a stable and tested version well before the LS to be taken into account Make a clear distinction between bug fix and new release – Improve communication on the backward compatibility of new releases (i.e. information session) Hard deadline for a new release is a few months before the start of the hardware commissioning (i.e. analysis tools need to be operational and well tested for the HC) As for the FESA 2 end of life a migration plan should be defined with each equipment group to evaluate in advance the support needed and possible improvements of the existing tools (e.g. FESA Eclipse plugin) Outlook for LS2 and future long shutdowns