1. Remapping of 48V generators in US15 – Load Balancing Much better balanced load between chan A and chan B outputs More even load between generators, avoiding loads clos(ish) to the power limit Still a problem with Y0805S2 Generator 3: To be revised (problem is LV/HV for BW A)

2. Update on remote control for RPC/TGC 48V Service Reminder: Uniformly agreed on the importance of implementing a remote control also for RPC and TGC 48V Service, to allow interlock functionality and remote expert on call support... Hardware/Status: DCS community opted for adding a (larger) 34980 DAQ module from Agilent (place for 8 insert cards) instead of another 34970 unit as we already have, to have free channels for additional future use Cost will be O(3-4k), green light from Ludo One complication: New module no longer has a RS232 interface, but is connected to a computer via USB Delayed order for the new module until it is proven how to read out from PVSS/DCS Communication: Established that the way to go is to implement a DLL/shared library for PVSS (WinCC) with the basic open, close, read, write operations emulating a serial interface – C++ programming, based on skeleton code from Agilent Higher level integration into DCS then comes to replacing the built-in serial calls to calls of functions of the new library --- (Stephanie, tbc, into fwAtlasAgilent) Arranged with a MDT colleague from Freiburg to work on a prototype library to prove the concept.... No time estimate, one activity among many, speeding things up we would have to commit a dedicated person ! Suggest RPC or TGC takes care of interconnects, cables, patch panel design etc. Once the module is ordered

3. CAEN New Mainframe Evaluation Last week worked with 2 CAEN engineers and our contact from EN/ICE on debugging for the new CAEN SY4527 mainframe ---- very productive !! Performance Evaluation (measurements in Feb): MDT system, ~1200 chans HV, 250 chans LV per mainframe Test done measuring Vmon update rate during HV ramping of the full system Group Update Rate (secs) Measured parameter update for chans in crate 10-2 (sec) 1012-13 512-14 1 Group Update Rate (secs) Measured parameter update for chans in crate 10-2 (sec) 5~14 1~13-16 Old SY1527 + OPC, polling mode (MDT, TGC default) Old SY1527 + OPC, event mode (previously stability issues....) Group Update Rate (secs) Measured parameter update rate (secs), for different crates/number of channels on a branch Crate 0-0Crate 0-1Crate 2-1Crate 2-3Crate 3-3 10 8-127-137-12 54-6 4-84-7 12244-56 New SY4527 + New OPC

4. CAEN New Mainframe Evaluation Problems/Issues investigated last week: Instable operation, crash of OPC communication after ~8 hours operation with the MDT watchdog script running (group refresh, alive flag toggling)  traced to a memory leak in the SY4527 firmware, only when changing mainframe parameters (remote channels, board items are fine). In the part storing settings in a SQLLite DB... Test version without DB write runs since then, have gotten a special release allowing access to SY1527 linux for memory/CPU checks Missing OPC items  Fixed Selection of TTL or NIM mode for Reset Signals not persistent across a power cycle  Fixed Missing Crate command „Reset“ and „Recovery“ for standalone control  Fixed „Transparent Mode“  Has been implemented.... Continuing/open items: Instabilities when concurrently accessing the mainframe with OPC (DCS) and web console and/or standalone control program (which replace the old telnet login) – reproduced at CAEN, not yet solved New OPC server version (mandatory for Win7/2008) does not work properly with current SY1527 in EventMode Was reproduced at CAEN; a bug fixed but with the large system @ CERN there are still (different) problems --- more feedback/details/investigations needed from us Still a smaller memory leak (O(out of mem. After 40 days)) seen, important to buy the new SY4527 early enought to allow long term evaluation before data taking

5. CAEN Event Blackout Behavior and Possible Improvements Event Blackout refers to the behavior of the CAEN system that during massive command execution monitoring of values (vMon, status, iMon) appears suspended MDT all HV ON takes about 70secs before channels react in DCS TGC all HV ON takes ~2 mins before channels react in DCS Makes artifically slow ramp up speed necessary to guarantee the state change is caught by DCS (requirement for the FSM) Limits what can be done in terms of adjusting trip limit, etc dynamically Discussion/Analysis with CAEN: Identical behavior of old and new mainframe  Blackout stems from commands having priority over monitoring together with the strictly sequential processing of commands, ~50-60 ms per remote channel --- wait on each channel to signal command completion before addresssing the next channel Concluded command shaving priority over monitoring is the correct thing Concluded that with a mainframe firmware modification alone one should be able to allow parallel issuing of commands to branches (branch controllers) No new hardware (branch controllers) needed as so far always part of any suggested solution Estimate a gain by a factor 6-8 for systems with 8-10 branch controllers, both in overall command execution time and in blackout duration will loose the mainframe preserving the order of commands issued to different channels  not an issue for us

6. CAEN Event Blackout Behavior and Possible Improvements Next Steps: CAEN to evaluate effort needed for implementing modified firmware --- manpower and time, then to provide an offer ---- will probably cost us something It should make sure it is understood that we commit a lot of money for the upgrade to the new SY4527 already, as first system at CERN PH/ESE raised the point that such a modified firmware would probably be benefical also for other CERN users.... With the old SY1527 ---- true, but we should make sure we do not pay the bill for modifying the old SY1527....