BLM data for XPOC

7th November 2007

Present:      J. Axensalva, B.Goddard, M.Lamont, E.Gallet, B.Dehning, C.Zamantzas, S.Jackson, M.Sapinski

The issues of BLM data acqusition were discussed for the LBDS XPOC.

• Requirements and scope

  - the normal LHC BLM XPOC buffer freezes on receipt of the "beam_1_dumped" or "Beam_2_dumped" timing events

  - the XPOC needs ~100 turns before and ~100 turn after the trigger

  - buffers are frozen for ALL BLMs, for both beams

  - for a programmed dump of one beam, this means the PM buffer will need to be used for data for the other beam

  - three crates located in point 6 are concerned

  - methods and data structures are identical for all BLMs (ring, extraction elements, TD line and dumps)

  - the 'direct BLM' is totally different with only the status, triggered flag and analogue count and threshold readings available via GET

  - the lists of BLM names are not yet in the layout DB but the present version can be sent 'privately' by BI - action Bernd/Mariusz

   

• Data format

  - data blocks will be acquired from each crate by the XPOC process using a GET

  - the CPU in the BLM front-end will ensure that the buffered data is available

  - the data structure will give back all 256 channels from the crate, with the channel-BLM name information and timestamp

  - the sequencer will need to check once per fill that the channel-BLM name configuration data is correct wrt the LSA DB

   

• Prototyping and testing

  - data in the correct format will be soon made available on 3 test (or deployed?) crates - action Stephen

  - the lab crate names are ppcbibl1, ppcbibl2 and ppcbibl3 (CMW devices BLMLHC_LAB1, BLMLHC_LAB2 and BLMLHC_LAB3)

  - deployed LHC crate names? - action Christos

  - storage for the SDDS logging needs to be found so that the 'event' based logging can be started - action Mike/Jerome

   

• Triggering

  - in a first instance the buffer freeze will be triggered internally by BI in a repeat mode

  - should soon be possible via the LHC timing system with 'real' events (start 2008) - action Christos/Stephen

  - the timing tables for the expected scenarios need to be decided and produced - action Mike/Brennan/Jerome

   

• XPOC functionality and application

  - the XPOC FS should be circulated - action Brennan

  - some of the expert browser functionality may be reusable for the XPOC data browser - to check - action Eric/Stephen

   

• Injection quality check data and 'operational' triggered data acqusition

  - requirements not clear - cannot use XPOC or PM buffers - to be clarified with OP - action OP/BI

   

BG, 7/11/07