LLRF
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
this.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
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. Done 11/24/2008
- Implement Laser Phase BSA. Done 11/21/2008
- Create PVs for PAC ADCs (new from Ron, 9/16/2008). Done 10/2008
-
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) In progress, started during downtime. Progress difficult while during running.
- 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. Done 10/2008. Installed on laser, TCav0, TCav3, S29 and S30 PACs. The rest still need to be reprogrammed in situ via JTAG port
- Standardize BSA PV names. Need framework if new ones are to be added. May affect archiver.Template written for what is needed. Physicists requested this not be installed 11/17/2008
- GUI standardization. Various Panel changes - # decimal points... in progress, ongoing
- 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.
He observed that integral term was zero. Need to investigate. unknown scope
- PAC position absorption by VME when feedback enabled (done only for Laser phase loop so far) In progress for laser. Opinions differ re: is this necess anywhere else
- 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. Done for all PCav1,2,3 and 4. 11/24/2008
- (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 for network subnet to be configured (new rule: only 1 subnet per switch)
- PAC for Bob Hettel of SPEAR - started 4/22. hardware ready
Ongoing tasks:
- 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 Done. Details above
-
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.