...

• Assume we'll never have a detector that adds payload to SlowUpdate timing stream data
  • Payload is added at the segment level
• Let the L1Accepts have a SlowUpdate modifier bit
  • Could maybe be a different transition ID, but I think that means more conditionals and will be messier
• If this bit is set:
  • The DRPs handle the L1A as usual
  • The DRPs look up a transition buffer using the L1A's pebble index and fills it in with the SlowUpdate data
    • The SlowUpdate EbDgram has the same pulseId, etc. as the L1A but its timestamp will be the L1A's incremented by 1 ns for psana EB
  • EbReceiver checks this bit and if set:
    • Writes out the L1Accept
    • Looks up the SlowUpdate dgram in the transition pool using the L1A's pebble index and writes it out (both to the file and the meb's)
  • psana sees two independent events, an L1Accept and a SlowUpdate, each with a separate timestamp, and handles them as currently
  • Only the L1A with the SU modifier bit set is forwarded to the TEB
    • TEB doesn't really do anything with transitions (e.g. the teb configuration is written out by the timing system we believe) 
    • Is it okay that the TEB doesn't get SlowUpdate trigger input data? (cpo thinks it's OK)
      • Perhaps such input data could possibly be included in the associated L1's payload (for both directions: drp to teb and vice-versa)
    • A plus of this idea: There is possibly no room in the batch for the SlowUpdate at 1 MHz
• If the bit is not set:
  • The DRPs handle the L1As as usual
• If there is no collision, SlowUpdate is generated and handled as usual
  • Since these can occur in slow RoGs when the fast RoG gets L1SU, the slow RoGs need to increment the timestamp (the +1ns) so that psana can event build
  • For all SlowUpdates, OK to unconditionally increment the timestamp by 1 ns?
    • Feels a bit kludgy
    • Maybe store the transition ID and/or group in the lower timestamp bits?
• The TEB would need to be changed so that slow RoG SlowUpdates are built with L1As having the SlowUpdate bit set
  • Probably not a big modification as the pulse ID build happens naturally and only consistency checks need to be adjusted
• The MEB changes might be minimal?
  
  • The EB is shared between TEB and MEB
  • Unlike for the TEB, L1As and SUs would need to be built separately by the MEBs, despite sometimes having the same pulseId
  • Maybe avoid the conflict by vetoing the monitor trigger request in the TEB if the L1A has the modifier bit set, so the MEB doesn't get two events (SU, L1A) with the same pulse id?
    • The MEB would then receive both L1As and SUs, none with the same pulseId
  • In any case buffer handling for the 3 cases should not be an issue

Another "locally generated" slowupdate idea

...

meb tells teb, teb tells drp which L1 meb to use (for L1)

...

could epicsarch EbReceiver make up a slowupdate locally using
(timestamp=last_L1_time+1ns) (on a timer) and push it in timeorder time order to
a free meb buffer?

  - need to tell worker to poll all the variables 
  - could the epicsarch worker attach the payload to a high-rate l1accept
    at some slow rate (allows the slowupdate to flow from worker to ebreceiver)
  - EbReceiver would translate the low-rate L1Accept into a slowupdate transition
    (using the +1ns hack) and save SlowUpdate to xtc
  - could keep the L1Accept (a little ugly) could truncate it in epicsarch.
    The MEB needs the L1Accept header at least to complete the event-build!
    Mona doesn't need the L1Accept, cpo thinks.

...