Event Triggered Measurement Acquisition

High time resolution data

Need to be able to pull rolling buffers containing turn-by-turn data (or whatever high time resolution is appropriate). Potential conflicit arises if these buffers are thought of as exclusively post mortem buffers.

BPMs

Need to grab last N turns at pre-assigned points in the cycle - injection, start ramp, 100 seconds into ramp... etc.
(need also to grab the first N turns of injected batch every injection - with or without circulating beam - warning event required). Conflict with RT feed/Closed Orbit?

BPM should not give problems. The 10000 turn acquisition is decoupled from the PM buffers which should not be used for anything but beam dump

BLMs

Need to grab the 2000*40 microsecond (which at the moment is sitting in SRAM "PM buffers") at pre-assigned points in the cycle - injection, start ramp, 100 seconds into ramp, from selected monitors without invoking PM.  Potential conflict if triggered acquisition is followed by real PM.

Comments from Lars:

3) As far as the loss data linked to the injection process I'm much in favor of having Julian create MTG events linked to this and publish the data N msec's after each injection .. If you prefer we can publish the data for ALL the available integration times .. 

This we should do.

4) I would prefer NOT using the post-mortem mechanism to treat the injection process as we will not be able to do this in the future .. We can test the post-mortem triggers anytime if you like, but the best solution IMHO would be to base injection losses on an event as explained above ..

Agreed but they appear to want the contents of the PM buffers...

RADMON

Again high time resolution acquisitons, at pre-defined points of cycle or on request. Selected monitors.

Other

Can also imagine triggered acquisiton from tranverse profile monitors and other instrumentation.

Beam Dump

There are a number of occasions when a beam dump is made and we will not want to force a full post mortem, for example,

• Inject and Dump
• Dump intermediate for re-injection of pilot

However, we will need to acquire data for the XPOC: BLMs, BPMs, screens etc

Dump request passes by BIC, which would normally trigger send of BST and GMT post mortem. Need to discriminate between emergency dump and operational dump request and condition BST/GMT events sent out. System should either:

1. Send full PM event over GMT/BST. This triggers full machine PM and push to PM server
or
2. Send triggered acquistion (buffer capture) event and publish to high level DAQ.

Thoughts

• Presuambly it is no problem for the CBCM/BST master to send out acquistion triggers as required.
• Obviously instrumentation systems concerned have to deal with request as appropriate.
• Data to be published via CMW in the standard way.
• High level DAQ takes care of capture and persistence.

Synchronised acquistion with equipment actions

Transverse feedback and 10000 turns

MQA and 10000 turns

etc.