Much better balanced load between chan A and chan B outputs More even load between generators avoiding loads closish to the power limit Still a problem with Y0805S2 Generator 3 To be revised problem is LVHV for BW A ID: 802619
Download The PPT/PDF document "Remapping of 48V generators in US15 – ..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
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)
Slide2Update 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 useCost 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 AgilentHigher 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
Slide3CAEN 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 mainframeTest 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)10
12-13
5
12-14
1
12-14
Group Update Rate (secs)Measured parameter update for chans in crate 10-2 (sec)5~141~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-31010108-127-137-1254-64-64-84-7 12244-56
New SY4527 + New OPC
Slide4CAEN 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 checksMissing OPC items FixedSelection 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 EventModeWas 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
Slide5CAEN 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 DCSTGC all HV ON takes ~2 mins before channels react in DCSMakes 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 channelConcluded 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
Slide6CAEN 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 ....