This meeting qualifies as a requirements review and conceptual design.

Attendees:

diane, sheng, terri, hamid, antonio, chris, amedeo

Minutes:

Our current situation: the e-beam 120Hz capable multicast network and data will not be installed and available until ~January 2010. We will need both a short-term solution to providing data to PDCS, and a long-term plan.

We discussed the requirements for this interface between the e-beam and PDCS, both short-term and long-term.

REQUIREMENTS

Data Required short-term:

  • Beam charge
  • Beam energy
  • Beam position and angle (in x and y) at the LTU *The data must be timestamped with the 17-bit pulseid (original source from an IOC w/EVR)

Data Requirements long-term:

  • data from e-beam will be 120Hz data produced by the charge, energy and position/angle feedbacks *data will be timestamped *Only data requirements listed above so far, but we will need to be flexible as PDCS physicists will likely add more...

Other Requirements short-term:

  • Data should arrive at PDCS within the pulse interval (ideally before the next pulse), highest expected rate 30Hz.
  • The packet can arrive within about 3 pulses. PCDS can use a timeout to adjust.
  • Can drop packet once every 3 days
  • Data from e-beam at best will be rough estimates of above, using simple calculations on timestamped data.
  • All e-beam data will be sent in one packet (& one group ID) using the PDCS format described in Chris O=Grady's ICD.
  • Commissioned in mid July.
  • Experiment runs in mid-August

Other Requirements long-term:

  • The goal is to have data arrive at PDCS within the pulse interval, 8.3ms for 120Hz beam.
  • packet format may change as data requirements change

We discussed the various proposed approaches to design and agreed upon the following implementation plan:

CONCEPTUAL DESIGN

A 'concentrator' IOC will be developed. This IOC will have an network interface to the e-beam Channel Access network, and a separate interface to the LCLSBLD subnet for nulticast to the PDCS multicast network.

  • the concentrator will collect the required e-beam data from e-beam IOCs via channel access.
  • the concentrator will calculate the charge, energy, position and angle and *the concentrator will create the PDCS data packet and send on PDCS network
  • if the channel access approach does not meet latency requirements then the e-beam IOCs must send unicast UDP messages to the concentrator.
  • PCDS has tested RTEMS code that can be used as example for UDP approach and data packet formation
  • Long-term: the Channel Access interface will be replaced with an interface to the e-beam multicast network. The rough calculations will be removed, the e-beam feedback data will be placed in the PDCS data packet and sent.

ACTION ITEMS

  • Diane/Hamid - identify and engineer to do this work.
  • Diane - prepare list of rough estimate calculations and review with Emma, Iverson
  • Diane - send list of calculations to group and John Bozek
  • Terri - ask Ernest to identify an existing or new crate.
  • Sheng - provide IOC
  • Chris - send Tony's code (example) that PCDS is adding to their IOCs.
  • Antonio/Terri - drawing of network this week
  • Antonio: implement next week
  • Engineer?: implement IOC with CA high priority client, do calculation, create 1 packet, and multicast from ebeam meas group.
  • Engineer?: convert data collection to non-EPICS if needed. Use code/idea created by PCDS to UDP scalar and timestamp to concentrator IOC.
  • PCDS and ebeam: test latency; PCDS will create a way to measure
  • No labels