Review of Daresbury Workshop MICE DAQ Workshop Fermilab February 10, 2006 A. Bross

Daresbury MICE DAQ WS  The first MICE DAQ Workshop was held at Daresbury Lab in September of 05  Focus was to give an overview of requirements of the experiment and discuss possible hardware and software implementations.  Included Front-end, monitoring and controls

paul drumm daq&c-ws august/september

4

DAQ Concepts

Daresbury Aug 2005Jean-Sébastien Graulich Introduction  Normal Detector DAQ is synchronised with MICE Beam  We want RF ON and RF Off Data (50/50 ?)  We need calibration data For each run  We want RF Noise data Dedicated Run

Daresbury Aug 2005Jean-Sébastien Graulich DDAQ vs CM Detector DAQ Synchronised with the beam Very fast reaction time (~  s) High transfer rate (~50 MB/s) Read and Store, no time for on-line processing Limited User Interface Run Control only (Slow) Control and Monitoring Continuous and permanent Very reliable (Safety issue) Deal with a lot of ≠ hardware Read and Check Calibration, manage alarms at ≠ levels, soft interlocks, take actions, log history, etc. Extended UI Set many parameters, manage complicate initialisation procedures, etc.  Why separate Particle Detector DAQ and Control Sensor DAQ ?

Daresbury Aug 2005Jean-Sébastien Graulich Concept Schematic MICE Beam Line MICE Cooling Channel MICE Detectors Detector DAQ Slow Control Data Storage Monitoring Data Log Run Control UI MICE User Interface Environment RF Phase

The Parts of MICE Parts is Parts

paul drumm daq&c-ws august/september Beam Line Overview and Controls Needs

paul drumm daq&c-ws august/september Beam Line Overview What’s in the beam line? –ISIS synchronisation pulses –Target –Beam Loss –Beam optics elements (power supplies) Quads, dipoles and muon decay solenoid Trim coils, water flow, temperature –Vacuum system – Warm ion pumps –Muon Decay Solenoid Cryogenics & Vacuum –Diffuser – id-sensor –Diagnostics – Beam Scintillators (not at same time as MICE Running

paul drumm daq&c-ws august/september dipole quads solenoid quads Power supplies - control & diagnostic Assume control feedback is done in the power supply “Control” – consists of setting I in each element “Diagnostic” – output = alarms/mimics etc – input parameters: Quads I,V – x4 each x9 Dipole I,V – x1 each x2 Solenoid I,V Diffuser bar-code reader? Environmental parameters (marshalled elsewhere?) cooling water temperature fault conditions (power supplies) fault conditions (solenoid cryogenics) Vacuum – per pump set Gauges – three: rough – turbo – system Integrated system control through PLC or off-shelf controller: - pump on/off; valve open/closed - auto start-up & shutdown v v v v v v VV Target ISIS: -BLM -Cycle information Solenoid Cryogenics & control system MICE Diagnostics DAQ  Control System Hybrid

paul drumm daq&c-ws august/september Target System Target motion is locked to ISIS cycle R/O system Target Mechanism Control System Drive G-MS PC System Linux / EPICS Event Bus Ethernet Infrastructure System implemented in MICE hall

paul drumm daq&c-ws august/september Mix of levels of monitoring & control –Dedicated hardware to drive the motors Read the position Control the current demand –Control system Used to set parameters in hardware –Amplitude, delays, speed Used to read & analyse diagnostic info –position… GUI – simplified user interaction Used to display diagnostics info

paul drumm daq&c-ws august/september Cooling Channel

paul drumm daq&c-ws august/september Physics Parameters Monitoring system can record many parameters, but: What are the critical parameters? Is the following sufficient? –Beam Line & Target Almost irrelevant Dipole one = momentum of pions Dipole two = momentum setting of muon beam Diffuser = energy loss = momentum into MICE –Poor measurement & p measured by TOF and Tracker Use Table of settings –record table-ID when loaded –“All ok” should be a gate condition –Magnets/Absorber Table of settings as above –RF – more dynamic information is needed High Q system – what does this mean for V &  ? Tuning mechanism – no details yet – pulse to pulse

paul drumm daq&c-ws august/september Superconducting magnets Current Setting –Process control – turn on/off/adjust –Passive monitoring – status Power supply = lethargic parameters Transducers = V&I Temperature monitoring Magnetic field measurements –3d Hall probes –CANBus – PCI/USB/VME interfaces available Feedback system or… Fault warnings –Temperatures / operational features MLS  Record Settings, Report Faults, “All ok” in gate

paul drumm daq&c-ws august/september Absorber (and Focus Coils) Absorber & Focus Coil Module –Mike Courthold’s talk on Hydrogen & Absorber Systems Process control Passive monitoring –Suit of instruments: »Temperature »Fluid Level »Thickness (tricky) Fault warnings –MLS  Record Settings, Report Faults, “All ok” in gate

paul drumm daq&c-ws august/september RF (& Coupling Coil) RF Cavity –Tuning –Cavity Power Level (Amplitude) –Cavity Phase RF Power –LL RF (~kW) –Driver RF (300kW) –Power RF (4MW) MICE has separate tasks to develop cavity and power systems but they are closely linked in a closed loop

The Parts of MICE Parts is Parts

MICE Safety System DE Baynham TW Bradshaw MJD Courthold Y Ivanyushenkov

MICE Layout

MICE Hazards Beam Radiation Fire Explosion Overpressure Material brittleness Skin burn Radiation HV=> Sparks HV RF LH 2 TrackerLH 2 Tracker Particle detectors High magnetic field => High mechanical forces Magnetic stray field Photo detectors and front-end electronics Optical fibres Photo detectors and front-end electronics Optical fibres HV TOF Monitoring the MICE Safety Systems is Important Component of Monitoring System

Controls and Monitoring Architecture

EPICS Experience at Fermilab Geoff Savage August 2005 Controls and Monitoring Group

What is EPICS?  Experimental Physics and Industrial Control System Collaboration Control System Architecture Software Toolkit  Integrated set of software building blocks for implementing a distributed control system 

Why EPICS?  Availability of device interfaces that match or are similar to our hardware  Ease with which the system can be extended to include our experiment-specific devices  Existence of a large and enthusiastic user community that understands our problems and are willing to offer advice and guidance.

EPICS Architecture Input Output Controller (IOC) Operator Interface (OPI) Local Area Network (LAN) OPI – a workstation running EPICS tools. Operating Systems: Linux and Windows XP. IOC – platform supporting EPICS run-time database. Example: VME based PPC processor running vxWorks, Linux workstation. LAN – communication path for Channel Access (CA), the EPICS communication protocol.

IOC Architecture

IOC Database  Collection of records  Each record represents a system parameter (process variable, PV) Unique name Set of attributes Attributes and value can be modified  Records must process to do something An input record can read a value every 10 seconds A CA write to an output record causes the record to process Either input or output, not both

EPICS Records  Input Analog In (AI) Binary In (BI) String In (SI)  Algorithm/control Calculation (CALC) Subroutine (SUB)  Output Analog Out (AO) Binary Out (BO)  Custom – only needed when existing record types or a collection of existing record types are inadequate

Channel Access IOC (CA Server) LAN EPICS Tool (CA Client) One client can connect to many servers. A channel connects to the value or an attribute of a PV. Each channel has a unique name = record name + attribute. CA Services: Search – find a channel by name Get – retrieve a channel value Put – modify a channel value Add monitor – notification of state change

MIL-STD-1553B Bus  Restricted detector access while running  Provides a robust and highly reliable connection to electronics in the remote collision hall  Developed a queuing driver, device support, and a generic record  12 IOCs with ~ busses from the counting house to the detector and ~10 busses within the counting house

Describe a Device with Records Template File Generator File EPICS Database EPICS tool Multiple record definitions with substitution parameters This defines a device. Define instances of a template. Assign values to the substitution parameters in the template file. Database Load ASCII file Instances of records read by IOC to create record database.

Centralized Database System Oracle Hardware Database Template File DB Creation EPICS Database Record Extract Generator File EPICS Database IOC Id Template Extract Generator File Instance Creation Python Scripts Web Access

Support for CFT  Device support for the AFE board using the MIL-1553 driver  AFE and AFE power supply templates  Record and device support for the SVX sequencers  Expert GUI for downloading Does not use COMICS  Calibration software Runs on processor in VRB crate Communicates with AFE

Analog Front End Fiber Wave guide Cryostat VLPC Analog Front End Stereo Board Cassette MIL-1553 Communication

EPICS at Fermilab  SMTF Superconducting module test facility Cavity test in October DOOCS for LLRF – speaks CA EPICS for everything else No ACNET – beams division controls system  ILC Control system to be decided Management structure now forming

EPICS Lessons  Three Layers Tools  EPICS tools  OPI development - CA library Applications  Build base  Build application - combine existing pieces  Develop device templates Development  Records, device, and driver support  EPICS is not simple to use Need expertise in each layer Support is an away  IOC operating system selection

paul drumm daq&c-ws august/september Integration of DAQ & Control systems

paul drumm daq&c-ws august/september Monitoring System

paul drumm daq&c-ws august/september Data Stream? Controls Header MHz Data (DAQ) Controls Footer DB Pointer MHz Data (DAQ) DB Pointer clock

paul drumm daq&c-ws august/september System Concept? equipment Control PCs Master Monitor & Logging ControlDisplay Event (Trigger) bus Ethernet bus

An idea of the DAQ architecture Bit3 SASeq#1 SASeq#2 SASeq#3 SASeq#4 SERDES#1 SERDES#2 SERDES#3 SERDES#4 SERDES#5 SERDES#6 SERDES#7 SERDES#8 VLPC #1 L VLPC #1 R VLPC #2 L VLPC #2 R VLPC #3 L VLPC #3 R VLPC #4 L VLPC #4 R Tracker Collector Upstream Tracker Collector Downstream Tracker Builder PID Builder Beam Builder MICE Builder MICE Storage MICE Control Bit3 SASeq#1 SASeq#2 SASeq#3 SASeq#4 SERDES#1 SERDES#2 SERDES#3 SERDES#4 SERDES#5 SERDES#6 SERDES#7 SERDES#8 Tracker Control Bit Tracker Slow Ctrl VLPC #1 L VLPC #1 R VLPC #2 L VLPC #2 R VLPC #3 L VLPC #3 R VLPC #4 L VLPC #4 R Upstream TrackerDownstream Tracker 4096ch 4kBytes/event 8MBytes/spill 4kBytes/event 4MBytes/spill Cryostat Ctrl/Monitor

Online System

UniDaq  Makoto described the KEK Unidaq system u Used for Fiber Tracker test at KEK s Worked well, interface to tracker readout (AFEII- VLSB) would be the same as in MICE u Could be used as MICE online system u Needs event builder s Significant issue

ALICE approach HLT embedded in the DAQ More than one hardware trigger  not straightforward to change trigger –But DAQ can be very flexible with standard technology. Easy to partition down to the level of the single front-end HLT / Monitoring

Alice HLT

Ready-to-use GUIs Run control should be implemented as a state machine for proper handling of state change Configure and partition Set run parameters and connect Select active processes and start them Start/stop

Ready-to-use GUIs Run control should be implemented as a state machine for proper handling of state change Configure and partition Set run parameters and connect Select active processes and start them Start/stop

Conclusions: never underestimate … Users are not experts: provide them the tools to work and to report problems effectively. Flexible partitioning. Event-building with accurate fragment alignment and validity checks, state reporting and reliability. Redundancy / fault tolerance A proper run-control with state-machine –And simplifying to the users the tasks of Partition, Configure, Trigger selection, Start, Stop A good monitoring framework, with clear-cut separation between DAQ services and monitoring clients Extensive and informative logging GUIs This represents a significant amount of work Not yet started!

Conclusions Coming out of Daresbury  Made Decisions!: u EPICS u Linux u VME/PC s Ethernet backbone u Event Bus (maybe)  The Start of a Specifications document u Has had one iteration

Next  Specify/evaluate as much of the hardware as possible u Front-end electronics needs to be fully specified since it can effect many aspects of the DAQ u Crate specs s PCs s Various interface cards  Assemble Test System u Core system s Must make a decision here (UNIDAQ, ALICE-like TB system,?) –I think we need to make a decision here relatively soon and will likely involve some arbitrariness. Who does the work will present a particular “POV” u VME backbone u Trigger architecture u Front-end electronics u EPICS interface s Need experts to be involved