ATTENDEES
Qing, Debbie, Ernest, Patrick, Till, Kukhee, Sonya, Shantha, Tom, Sherry
REVIEW
Slide 2:
- BLEN IOC is required to support up to 4 channels of data
- data should be sent out on FNET with ~1.2msec of pulse
- IMAX calc Plan A: attempt to use the BPM TMIT from FNET to calculate the IMAX; test if this meets above 1.2 msec requirement.
- IMAX calc Plan B: Patrick says we do not meet requirements with the TMIT updating at 10Hz, so the Plan B must be to move the IMAX calculation to the Controller IOC (or BLD?), but make it separate from the feedback processing, since it must be available even when feedbacks are off. We will design this fully if we find the calculation cannot be done in time on the BLEN IOC.
Slide 4:
- There is some question as to what the PAD actually measures and sums - but the PAD data processing is working now and there are no plans to change it.
- Till is currently changing the padStream encapsulation / udpComm that is (sort of) shared between BPMs, RF and BLENs. It was hoped that Till's module changes (for both VME and EIOCs) will work for RF and BLEN applications, but Qing (and Kukhee) will have to evaluate this as soon as it is available from Till.
- Further details: the PADs cannot use ARP to accomplish the unicast communication from EIOCs to the VME IOC - the Multicast message from the VME IOC to the PAD must provide the PADs with the information needed. Qing (and Kukhee) must familiarize themselves with the current VME master<->EIOC communication scheme used by their IOCs, and be prepared to evaluate Till's changes.
- The Ideal solution is to produce a module that satisfies the requirements of all three IOCs - RF, BLEN, and BPMs.
- A Timeline Diagram similar to Kukhee's, that shows the IOC-EIOC communications vs. fiducial interrupts would be very useful.
Slide 6:
There was much discussion on the tradeoffs of the three proposed designs.
- BLEN data could be sent out directly from PADs on FNET by adding multicast send into the PAD code. No need for VME IOC at all
- Can eliminate complicated communications and delay by replacing PAD with VME Digitizer or QADC
- VME bus communication is fairly slow; may not meet time specs - especially if scaled up to multiple digitizers
- QADC is preferable in terms of cost
- FACET has a stake in this choice, FACET will likely use whatever we develop for LCLS
- QADC does not provide full waveform of data, gives a single value only
- Consensus is that if truly capable of working across full charge range, the QADC is preferred over the VME
- New information from Joe F.: the QADC needs additional hardware (in the pre-amp?) to 'shape' the signal before input to the QADC to make it useful for the BLEN. (Joe's email at the end)
- For Fast Feedback project, schedule is king - we will not use the QADC if it cannot be completed and ready for system test by March 7th.
- We need an estimate of software and hardware, effort, schedule and cost for each option:
- upgrade using existing architecture (PAD)
- redesign with QADC (with additional signal shaping)
- Once the hardware cost, effort and schedule is defined for using QADC - if that fits into the Fast Feedback schedule, then Qing can work on a software effort estimate
slide 8:
reiterate previous discussion - Qing needs to become familiar with current BLEN IOC <->EIOC communications scheme and evaluate Till's changes. (Kukhee too...). What we need here is a set of requirements for the padStream/udpComm that includes RF and BLEN needs, or whatever portion of that that can be 'modularized'. Then try to ensure that this code works for all three.
ACTION ITEMS
Qing - review and understand the current BLEN IOC<->EIOC communications. Particularly initial startup and how they sync up when either one is rebooted.
Qing - Document the new BLEN IOC<->EIOC communications scheme with a timeline diagram. See Kukhee's and Till's for examples
Qing and Kukhee - evaluate Till's IOC<->EIOC communications software changes as soon as it's available
Till - is there anything you can send out early, an ICD? that describes your approach and changes.
Diane & Patrick & Ernest - discuss with Hamid and Ray Larson using Qing full-time through March on Fast Feedback (/FACET)
Ernest, Patrick - provide estimates of effort, cost, and schedule for hardware needed to use QADC for BLEN,
Qing - once hardware estimates are available provide estimate of effort for software development to use QADC
ADDENDUM: email from Joe
We can put a pulse shaper on the output of the existing preamplifier that will match the signal reasonably into a QDC. Looking at the data sheet the pedestal without adjustment is ~80uA, OK for 5us gate. The diagnostics group will provide the signal conditioning to convert the pre-amp output to a singnal that will go directly into the adc. So, assume we can use the QDC, but it will of course take time to switch over from the existing digitizer system. BTW, is there a separate account for 120Hz upgreades, or does this go on Franz-Josef's budget? --- Joe Frisch