ATTENDEES
Qing Qing, Debbie, Ernest, Patrick, Till, Kukhee, Sonya, Shantha, Tom, Sherry
REVIEW
Slide Slide 2:- BLEN
- 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 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.
...
- A Timeline Diagram similar to Kukhee's, that shows the IOC-EIOC communications vs. fiducial interrupts would be very useful. Slide
Slide 6:
There was much discussion on the tradeoffs of the three proposed designs.
...
• 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 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.
...