PROPOSAL FOR DOROS CONTROL & MEASUREMENT

DISTRIBUTION

Collimator BPM Discussion14/3/2014

Requirements DOROS agents produce position data at 25Hz Also need to be sent settings at 1Hz

Settings need to arrive at all agents at exactly the same time

Total number of DOROS agents is ~100 ~20 are involved in the collimation system Rest are placed elsewhere (before experiment IPs for

example) The solution we come up with for the collimator

BPMs should be generic So we should try to use same solution for all agents…

Is this in conflict with the topology already proposed?

Existing proposal

Problem might arise in OFC algorithm with added latency for standard BPMs?

Proposal 1 DOROS agents communicate with a new FESA class

(BPMDOROSLHC) and OFC directly – Collimator control class gets data via new FESA class Collimator class has higher latency due to proxying by

BPMDOROSLHC class BLM UDP data already passes through a proxy Position data more time-critical though…

Not a problem (?) For the OFC, optimum in terms of performance – No proxying

involved Can be treated as reliable as standard BPM data

Conversion factors need to be maintained by BPMDOROSLHC class but also forwarded to the OFSU which will in turn forward to the OFC OFSU would subscribe to Settings@BPMDOROSLHC over CMW

OFC can treat the data arrival like standard BPM data (i.e. very low latency, respecting the time window set by orbit trigger)

Proposal 2 DOROS agents communicate with only

BPMDOROSLHC class BPMDOROSLHC class acts as a proxy and forwards

packets to OFC and collimator control system after applying factors Factors only maintained and used by BPMDOROSLHC

class Proxying adds more than double latency to OFC

reception Can also be disturbed by server actions and general

FESA jitter Could be a problem if used in OFC correction

Doesn’t affect the collimation DOROS agents though

Modification of OFC to accept DOROS data

Existing feedback loop Wait for an orbit trigger packet (or timeout) Wait for 1 of

Orbit trigger (B1/B2) BPM QQP COD

Treat data appropriately Data accepted between acceptance window from BPMs Asynchronous treatment of data from COD / QQP

Send corrections Send to OFSU over Tinterlink

• DOROS

/DOROS/DOROS

Modification to OFC to accept DOROS data 2

New code required to receive and handle the DOROS data How do we handle the data

1) Data is synchronous (like BPM data) Implying that it has to arrive within n milliseconds of orbit trigger We could examine the UDP packet to distinguish between a DOROS packet or

classis BPM packet Extend existing C++ handler for BPM data

Allows incorporation into the OFC feedback in the future 2) … or asynchronous data (like data from the CODs)

Requires a new C++ class : DOROSHandler.cpp Data arrives and is processed Fine for instrumentation via the OFSU (-> YASP) Can’t be used in the OFC feedback

In the case of the ~20 collimation DOROS agents option 2) is OK, but will we need option 1) in the future for the other DOROS agents? Re – Generic solution covering future needs of other DOROS

measurements

Proposed Deliverables Decide which approach we take ASAP Hardware team can’t give us final details of UDP packet

structure until later 2014 But they agree to send UDP packets of some data soon So we should deliver the bulk of the new FESA server soon

(early summer) We then add the details later in the year Data might look like this…?

typedef struct { char packetType[10]; // unique name, e.g. “DOROS.1.x\0" char authorisationKey[8]; // reserved(future safety option) int sourceHostNumber; // reserved unsigned long sendTime_s; // reserved unsigned long sendTime_us; // reserved unsigned long long acqStamp; // reserved (used with synchronization enabled)(micro-seconds from first synchronization pulse (*3.2

time normalization into Seconds)) unsigned long seqNumber; // 0, 1, ... - detects packet loss unsigned short ADCsampleNum; // number of ADC samples unsigned short Average_Factor; // averaging factor unsigned int adcData[NUM_FRAMES*8]; } PacketStruct_DiodeBPM;

Notes…