1 / 12

Proposal for DOROS CONTROL & measurement distribution

Proposal for DOROS CONTROL & measurement distribution. Collimator BPM Discussion 14/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

leal
Download Presentation

Proposal for DOROS CONTROL & measurement distribution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Proposal for DOROS CONTROL & measurement distribution Collimator BPM Discussion 14/3/2014

  2. 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?

  3. Existing proposal • Problem might arise in OFC algorithm with added latency for standard BPMs? (a) DOROS with standard BPMs (b) DOROS with collimator BPMs Figure 10 – The DOROS architecture, with standard and embedded collimator BPMs (DC = DOROS Controller; CC = Collimator Concentrator; OFC = Orbit Feeback Controller; DB = Database).

  4. 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 proxyingby 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)

  5. 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

  6. 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

  7. 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

  8. 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…? • typedefstruct { • char packetType[10]; // unique name, e.g. “DOROS.1.x\0" • char authorisationKey[8]; // reserved(future safety option) • intsourceHostNumber; // reserved • unsigned long sendTime_s; // reserved • unsigned long sendTime_us; // reserved • unsigned long longacqStamp; // 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 intadcData[NUM_FRAMES*8]; • } PacketStruct_DiodeBPM;

  9. Notes…

More Related