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…