Download Proposal for implementation of communication with

Collimator BPM Discussion
14/3/2014


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?
DOROS with
standard BPMs

DOROS with collimator BPMs
Problem might arise in OFC algorithm with
added latency for standard BPMs?

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)

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

Existing feedback loop
Wait for an orbit trigger packet (or timeout)
 Wait for 1 of

Orbit trigger (B1/B2)
BPM
QQP
COD
• DOROS





Treat data appropriately
 Data accepted between acceptance window from BPMs/DOROS
 Asynchronous treatment of data from COD / QQP /DOROS
Send corrections
 Send to OFSU over Tinterlink



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


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;
UDP(12.5(Hz(
Propose
d(System
CBPM% JAWS%
CBPM% JAWS%
BLM%
(
1(Hz(Subscribe(
Proposed(
FESA(Class( TCP(
8(Hz(Set(
1(Hz(
12.5%Hz%BLM%data%
Collimator%Data%Concentrator%
Concentrator%
1(Hz(Subscribe(
Proposed(
FESA(Class( (
e
Perform%
Alignment%
ib
H
8(
(
et
z(S
Online%Monitoring%
Display%
1(Hz(Set(
GUI/Top<
level(
(Su
Hz
5(
.
12
cr
bs
Scan%
Algorithm%
Perform%
Scan%
10(Hz(Subscrib
rib
bsc
z(Su
H
(
1
DOROS%
Controller*%
e(
e(
1(H
z(S
et
(
BPM%
Alignment%
UDP(
25(Hz(
Input%
coefficients%
CMW%
SIS%
Interlock%
z(
UDP(25(H
BLM%
Alignment%
12(Hz(Subscribe(
Concentrator%
1(Hz(Subscribe(
(
CMW%
Logic/Server<
level(
RequiredAbsolutePosi6on/LU%
RequiredAbsolutePosi6on/LD%
RequiredAbsolutePosi6on/RU%
RequiredAbsolutePosi6on/RD%
1(Hz(
(
Subs
cribe
MeasuredCornerPosi6ons/LU%
MeasuredCornerPosi6ons/LD%
MeasuredCornerPosi6ons/RU%
MeasuredCornerPosi6ons/RD%
DOROS%
Exis6ng%
FESA%Class%
OFC%
Logging%
*conversion%of%integers%to%electrode%signals+beam%pos%(mm)%