Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Priorities

DAQ integration priority order determined together with Sebastien Boutet and hutch scientists

...

  • cameralink
  • coaxpress over fiber
  • anything low-rate (<=100Hz) where it's easy to make an IOC for it (e.g with a company SDK kit we already support, like andor or alvium)
    • anything with an existing IOC that supports LCLS2-timing is "free"

...

  • Nov. 20, 2023 with Sebastien/James/Georgi
  • Mar. 20, 2024 with Georgi/Kristjan/Dan/Chris/Dougie/DJ/Lingjia
  • June 6, 2024 James, Kristjan, Silke, Georgi, Alex, Sebastien, Andy
  • Sept 5, 2024 Alex, Georgi, Jana, cpo, Andy, James, Sebastien

NOTE: Any camera that is implemented as an IOC should submit a Jira ticket for the controls group with "component" set to "Imaging" (ECS Supported Devices Curation) to make sure functionality is not being duplicated.  See approved list of controls-detectors here (https://confluence.slac.stanford.edu/pages/viewpage.action?pageId=326510196#SupportedDevices(SDL)-Addingadevice).

Detector List

In priority order

DetectorEnhances efficiency of current operations

Enhances robustness of operations

Adds new capabilities that broaden the scientific community

Maximizes science output and utilization of the high rep rate SC beam

Maximizes science output and utilization of the kHz UED beam

Reduces complexity of deployment by, for example, allowing older systems to be retired

rixccd (archon)





phase cavity BLD





ebeam BLD





UED 1080Hz epix10ka





mfx jungfrau 15M





alvium support with timetool plug-in





mfx fee spectrometer





rix axis sxr-60





tmo pixel





ued andor ikon ("emccd")





rix epixM





rix epixUHR





opal replacement (alvium?)





rix k-microscope





timepix





mec varex





Notes

Detectors in priority order.  Implementation order will also be affected by available expertise and how long the integration project will take.

  • (almost complete) rixccd (archon)
    • needs new timestamping firmware
  • (almost complete) superconducting phase-cavity BLD
    • (closecloser)
  • ebeam BLD 
  • (cancelled) small txi epixHR (beginning of 2025)
  • (complete) rix high-rate mono-encoder
  • UED 1080Hz epix
  • UED EMCCD?
    • identical to andor iXon listed below with existing timestamping IOC?
    • if so can be implemented as a "pvaDetector"
  • BLD
    • would help if TMO/RIX scientists could push on ACR (Jeremy Mock and cc Matt Weaver?)
    • needed for SXR XTCAV?
  • UED 1080Hz epix10ka
    • some high-rate beam issues. not used at high rates with beam before first half of 2025
    • Julian Mendez writes on Sept 17 2024: Conny took the one that failed but I've no idea if he re-installed it. For the 1kfps I get something working but I don't know if the readout parameter are large enough to acquire data. @gabriel should look at this but I don't know what is the status.
    • Conny writes on Sept 17 2024:The 360Hz UED QUAD is alaive again, the boards had melted and had to be replaced, but it is alive. It is currently with TID. They are supposed to check that some of the temperature sensors are alive and check what values they report for air running. Kaz and I was hoping to get it back this week, but have not heard back from Chris Kenney on this. The UED hutch is open for this work from: 09/23 - 10/18 so everything has to be done within this window
    • The 1080Hz camera is expected to be assembled at end of 2024.  Software compatible with 360Hz camera.  Will set up a piece of the detector in ASC when available to test daq integration.
  • mfx jungfrau15M (early 2025mfx jungfrau16M (a year)
  • mfx usb alvium support (for timetool plug-in) although opal could be used mfx epix100(although end-of-life)
    • ~120Hz 
    • if implemented as IOC: timetool plug-in is non-trivial?  Ask Mat Bain, Matt Britton, Giacomo.  It was pointed out (by Giacomo, cpo believes) that the plug-in is important for MFX but not in RIX (where the piranha is used more).  James disagrees with Giacomo: he believes the 2D detector result is more reliable than piranha for feedback, so argues that timetool plug-in is important for TMO.
    • There are 2 or 3 opals in building 84 in lab2.
    • in UED we have seen that alvium IOC timestamping needs work.  previous experts (Mike Browne and Bruce Hill) have both retired.  no person has been identified to work on this.
    • Silke will work with Dan on this.
  • mfx fee spectrometer support (bld and full ioc image)
    • (standalone running complete) tmo tixel
      • magnetic bottle expts could use existing detector
      • would be nice to replace a dream delay-line-detector with tixel? need a larger one. not obligated to users
      • higher priority than big txi epixHR
      • could replace k-microscope delay-line detector
      • need to check that we have enough network bandwidth to reach the lcls2 daq
    • rix axis sxr-60 camera (chemrix spectrometer) 
      • camera not here yet (sept 5, 2024) but should be here soon 
      • plan is to implement as an IOC (who? dan? if tid could do it that would be great)
      • Silke has a Jira ticket that will go to TID or cosylab
      • smaller pixel than epix
      • can't use andor: flange-mount makes grazing-incidence difficult
      • could happen before "the shutdown" (at slac end of july September 2024, but have framegrabber)
      • commissioned in run 23 (oct 2024 through feb 2025)
      • highest priority for new instrument for rixs experiments
      • plan is to implement as an IOC (who? dan? if tid could do it that would be great)
    • big txi epixHR (big one delayed until aug 2025)
    • tmo tixel
      • waiting for funding on this.  James will look into this. 
      • tmo happy with standalone running 
      • magnetic bottle expts could use existing detector
      • would be nice to replace a dream delay-line-detector with tixel? need a larger one. not obligated to users
      • higher priority than big txi epixHR
      • could replace k-microscope delay-line detector
    • UED EMCCD?
      • an alvium was set up as a "proxy" for this detector and is working at 1Hz.  Patrick/Silke and perhaps Ian will work on this.
      • same as Andor iXon
      • working on a timestamping IOC (in-progress).  Maybe Basel would work on this with advice from Dan.
      • if so can be implemented as a "pvaDetector"
      • medium-term goal for UED
    • (done, to first order, but awaiting TID improvements) rix epixM (depends on approved experiments)
      • in good shape from a daw-integration point of view, but data looked "flakey".
      • Silke says some controls MPOD questions
      • Georgi wants to start testing in hutch in fall 2024
    • epixUHR (testing and in XPP)
      • Riccardo Melchiorri is working on this
      • Dionisio writes to cpo in email: "Detector assembled late 2025 and detector ready for use in mid-2026".
        • needs significant fiber work and daq integration
        • cpo will email Takahiro and cc Sebastien, Silke, Jana to verify schedule.  Would they use Jungfrau instead?  perhaps move up or down in priority list depending on response. (HE beam expected in XPP march 2027)
      • Sebastien writes about priorities on Sept 6, 2024:  "With the timeline now more clear, I think we can de-prioritize this a little bit compared to the meeting yesterday. XPP will not use it for experiments until at best late 2026 and most likely not before LCLS-II-HE beam. That being said, there is clear value in testing early and targeting the ability to test it with 120 Hz beam in the second half of 2026 seems good. So that is about 1 year later than what was discussed yesterday."
      • gain modes (on a per-pixel): fixed high/medium/low, auto-high/low, auto-medium/low,  auto-medium/extralow, auto-high/extralow, and maybe fixed extralow
    • opal replacement (waiting on decision from scientists: see Opal Replacement)
      • would like alvium
    • rix k-microscope delay-line-detector (depends on approved experiments)
      • somewhat similar to tixel. 
      • on-hold.  sept 2024 l2si phasing workshop: saw it on a schedule for Oct 2026?  will know more about schedule requirements in late September 2024.  waiting for management approval.
        • Yves/Markus should communicate with Jake Koralek 
        • cpo estimates 3 more months of FTE effort to integrate 
        • should we use the dream dld or perhaps tixel instead?
        • local contact person: Jake Koralek
        priority depends on conclusions of workshop in March 2024
        • perhaps users in spring 2025
    • epixUHR (testing and in XPP, production not until late 2026)
      • Riccardo Melchiorri is working on this
    • opal replacement (waiting on decision from scientists: see Opal Replacement)
    • timepix
      • workshop in late September 2024 may determine priority
      • a variation on sparkpix?
      • ALS also involved in this?
    • mec varex?  need to talk to mec people to set priority
      • perhaps "someone" will create a timestamping IOC?

    Low priority stuff (to be removed eventually):

    • (strongly deprioritized) small (2Mpx, 5kHz) txi epixHR (beginning of 2025)
      • only for tests, not in official experiments
      • epixHR (4Mpx 35kHz, big one delayed)
        • ON HOLD starting in August because TXI 2M was postponed
    • (we think this is complete, but Dougie is validating it further) rix high-rate mono-encoder
    • (completed by Gabriel Dorlhiac and Julian Mendez) mfx epix100
      • for lcls2, needs work but somewhat done

    Requested Detector Features

    We request that TID support the following features for custom LCLS2 detectors:

    • software readout of all fiber optic powers
    • software/firmware support for eye-diagram scans for all high speed links as pioneered by Julian Mendez
    • when data from a multi-segment detector is transmitted on multiple pgp lanes there should be a batching-event-builder in the receiving kcu1500/c1100 to join all lanes of data together, together with a rogue "blowoff" mechanism to clear the associated FIFOs when needed
    • data appears in a natural unscrambled order (e.g. pixels in an image)
    • event data from detector (or detector segments) must preserve time-order (round-robin of event data across PGP lanes makes this difficult, for example)ued andor ixon (the camera used in the old daq? but maybe not)
    • maybe an IOC because of long integration times
    • might not be too bad if it's an andor
    • get more information