The Big Picture... answering the big picture questions will help to design and implement solutions in many of the smaller tasks.
Big picture question 1: Is
there/will there be a finalized list of LLRF BSA PVs or should this be
open-ended, i.e. design a system that can handle an ever-increasing
number? Note that Franz-Josef is currently asking for new BSA PVs that
originate on IOCs that are not on the private LLRF network. Adding
these would require long-haul ethernet cabling to klystrons in the
gallery and even additional switch if no free ports.
Big picture question 2: Will
the BSA acquisition PVs be moved off to a Linux server so that the IOC
does not have to take the load? This action would make big picture
question 1's answer be able to be the open-ended solution.
If the IOC has to handle an
open-ended load, it may be necessary to add mvme6100s to the crate and
divide up the code across the processors.
Big picture question 3: What
is the plan for beam-based longitudinal feedback? I.e. where will this
processing reside? Originally, it was planned to reside on the LLRF VME
crate at Sector 20. That is the reason ALL of the
LLRF local fast feedbacks reside in one IOC.
Big picture question 4: How
does the AIP LLRF upgrade, including MKSU and SCP applications, fit
into the picture? We need to make decisions that allow a path for
Tasks: in the order I plan to do them
Fix laser jumps at startup and after source change. Be able to boot up
correctly with any source (before, laser phase was always initialized
to use 119 MHz source and then operator could switch to 2856 MHz after
init). Automate the bucket preservation when changing from 119 MHz
source to 2856 MHz source. 1 week. Can be done during downtime (need laser oscillator and consent of laser people)
- Implement Laser Phase BSA. 1 day implementation. 1 day commissioning time (with timing system)
- Create PVs for PAC ADCs (new from Ron, 9/16/2008). 1 day
Design/implement udp protocol for sending I and Q adjusts from
VME to PAC over 2nd ethernet. BPM app is monitor only. LLRF does
control. The second ethernet could be used to send the adjustments out.
Note that this is AFTER BSA has occurred. BSA PVs are only actual
values, not setpoints. Determine how this data will be sent to PAC
(i.e. new task or triggered by incoming data) 2 weeks during downtime, then several days of commissioning to convert all PACs.
- Modify PAC
software changes to do waveform calculation in FPGA. Jeff Olsen has
changed the FPGA code to do this calculation. Coldfire can now stop
doing the calc and just set values into newly defined registers. 1 day implementation. 1 day test. Several days of commissioning to convert all PACs
- Standardize BSA PV names. Need framework if new ones are to be added. May affect archiver. 3 days
- GUI standardization. Various Panel changes - # decimal points... need agreement on this. different opinions of what is required have created a nonstandard mess.
- Temperature monitors - assign so that we can use these. need names, offsets, scale factors
- Gun Tune
Feedback - during last week of the run (11-18 Aug), Joe was asking for
additional changes because of the results of the 120 Hz gun processing.
I need a description of what he wants. unknown scope
- PAC position absorption by VME when feedback enabled (done only for Laser phase loop so far) 1 week. I am not really clear on if this is needed or not; opinions are inconsistent
- Access security for PVs to protect values. This would be nice, but probably not going to happen this fall
6/30/2008: new request for alarms when phase,ampl setpoints do no agree
with actual averaged values. Done but may have a race condition with
average amplitude since it ALREADY was alarmed when below threshold. 1 day
- LCLS PLL Oscillator: Use event
to reset request instead of write_bo. Grab data waveforms each trigger
and process them for analysis.
- Finish testing of phase cavity BSA. I cut this short at end of the run in order to do the Bunch Length monitor BSA. 4 hours operation time
- (Optional) Add the option to send the full waveform OR the processed values. This is probably not going to get done this fall
(Optional) Write new code to handle the full waveform if sent from
PAD. The processing done on the PAD now would be implemented on the
VME, but now, with floating point, calcs could be different. This is probably not going to get done this fall
- PADs and PACs needed for Klystron test lab stations -- started 4/21, waiting on switch upgrade next fiscal year
- PAC for Bob Hettel of SPEAR - started 4/22. in holding pattern. no hardware allocated for this
- Add alarms to channels at all levels with summaries propagated up
- Save and restore new channels
- Archive new channels
- Check archiver for disconnected channels
New, from Joe Frisch, Franz-Josef 9/16/2008
1. RF feedbacks need to respond fast to changes in operating points (redundant with my task list)
2. Add diagnostic klystron PADs to BSA (new. see big picture questions)
3. Set up a test stand in the gallery for BSA testing (new)
4. Laser BSA (redundant with my task list)
5. Phase Cavity testing (requires test setup)(redundant with my task list, although I wasn't going to use the test setup)
6. Second Ethernet for PACs (redundant with my task list)
Ron's additions to 9/16/2008 list:
- Read out and process PAC slow ADCs
There is a large amount of PAD test software done by Bob Steele before
he was laid off. I need someone to support this software.
No problem today.
- Test software for PAD second ethernet
port. Assign MAC address and store in database. Would like
to incorporate this into work started by Bob Steele.
- Test software for PAC including PAC second ethernet port. Assign
MAC address and store in database. Till started first part of
this and Vojtech will work more on this. Nothing has been done
with second Ethernet port. kdk comment: The part that Till started has
nothing to do with the second eth port. It is a mod that moves calcs
out of coldfire into the FPGA. I think this is two separate tasks. We
could, in theory, install the BSA upgrade and then separately, upgrade
the FPGAs. I think this way is a more cautious upgrade path. (redundant with my task list)
AMRF will needs a test station and software to maintain LCLS LLRF
chassis. After tests this past summer, we now know that 120Hz operation
will require separation of LLRF feedbacks into four 30Hz channels.
MPS Link Node
Add additonal PVs as register definition unfolds