Notes on RF Actuator Detailed Design Review  

* The PAU/MUX design allows for n patterns/data-slots.  We must choose a number of data slots to instantiate EPICS records and support EDM displays for user interface, since these cannot be generated on the fly. We will initially build the PAU/MUXes with 4 data-slots for 4 patterns. 

* PAUs are not required to be created on-the-fly; they can be created at IOC boot-up as part of the initialization.  Later comments: We decided for simplicity not to associate multiple MUXes with a single PAU, instead Kukhee can create one PAU per MUX, or re-arrange code to combine PAU/MUX functions - Kukhee's choice. We will keep the multiple MUX per PAU concept as a backup if it ever becomes necessary.  To the user/feedback it will look like every current control parameter/PV becomes 4 control parameters/PVs, with an associated mask for each (eg: BDES1, MASK1; BDES2, MASK2; etc...) 

* Feedback ON/OFF transitions need to be documented for the RF IOC - what steps will it perform when feedback is turned ON? What steps will occur when feedback is turned OFF? At the least current DES and Patterns must be copied from one control source to the other (eg: from FCOM memory to PVs when turning off...) (for reference: I believe some of this was documented in the Controller Conceptual Design Review) 

* FCOM needs to have a configurable priority, so that the RF IOC can set it's priority below that of the thread that pushes the actuator settings to the PAC. 

* LOCAL FEEDBACK LOOPS: In RF stations that have local feedback loops the Beam-based feedback will be setting the setpoint of the local loop (eg: ADES = local feedback setpoint). Tom Himel has kindly provided a new feedback algorithm that will allow the local feedback loop to work correctly with it's setpoint being updated at 120Hz.  The email with the new algorithm is included far below. Additional comments in subsequent emails are also at the end. 

* There was discussion about the utility of the Ultra-high priority thread, where Kukhee wished to separate PAU functionality from the fiducial processing.  Currently there are no other functions registered with the fiducial processing in RF or magnet IOCs. Stephanie felt the ultra-high priority callback was probably not necessary, that Kukhee should consider removing the Ultra-high priority thread and have the registered fiducial function do more work. Stephanie will add a parameter to the fiducial registration to support Kukhee's code. 

* The amplitude and phase settings of a station need to be converted to I&Q, so within the RF master IOC a station's amplitude and phase need to be associated, and both values available in order to convert to I&Q - need to document how the I&Q conversion is triggered so that it is guaranteed to be using the correct amplitude and phase setpoints (in time, and per station). 

* Need more error checking detail. For instance, be sure to check for all error returns from EVR processing, FCOM interface, any other interfaces used. List errors to be reported from PAU, additional 120Hz processing. 

* Kukhee will have a table (in header file...) associating PADs with PACs, so that readbacks as associated with the correct setpoint. Likely there is other association-type information in this table (FCOM IDs, amp&phase maybe?) 

* there needs to be a more clear separation of functionality between PAU, BSA support, updComm, FCOM. For instance:

  • all PADs must provide readbacks at 120Hz to BSA (whether there is a PAU or not)
  • All actuators with FCOM will have PAUs, but
  • can an actuator have a PAU without FCOM? (data source is CA? - Controllers are doing this for debugging...) This is not a requirement for Fast Feedback, but maybe should keep it in mind and be sure that FCOM/PAU functionality is separable. 

* we discussed the PAU epics records: Steph suggested Kukhee consider using Subroutine records for PAU, MUX. Also look at EVR(EVG?) record processing to see how she uses events to cause all records to process together... * FCOM Pull function: Steph wonders why the timeslot is checked before pulling FCOM data - just go ahead and pull then decide if needed...? I did not get these notes fully Kukhee or Steph please add description if you can...   

ACTION ITEMS from REVIEW:

1) Diane and Kukhee - create timeline of feedback processing chain, can we run a real 120Hz feedback? (not two 60hz loops). 

2) Kukhee to incorporate, and document, separation between BSA, PAU, udpComm, and FCOM functionality 

3) Diane to compare 120Hz upgrade prioritized list with fast feedback list and assign overall priorities for Kukhee (with input from Ron A. of course) 

4) Kukhee to create Design Document, including all information in slides and above comments/actions 

5) we will meet again to complete detailed Review of action items 1)processing timeline and full 120Hz, and 2)modular design with separation of PAU, BSA, FCOM, udpComm, 

NOTES from Follow-up meeting for 1) an 2)

ATTENDEES:

Kukhee, Diane, Debbie, Stephanie, Tom, Patrick

NOTES:

  • Kukhee went thru slides covering 1) the Full 120Hz operation of the PAU, and 2)modular design wrt PAU, udp, fcom, etc.
  • Stephanie suggested that the udp send operations not be in a separate thread 
  • Stephanie suggested using a different time delay for 60Hz operation. The user needs to input these delays, so we could set two default time delays
  • We noted that the delay will be on the order of 0.4msec after TS2 fiducial
  • The master/offset setpoint PVs are to be maintained when the FBCK On/Off PV is changed. When the feedback control is turned on, it begins by using the master/offset setpoint PVs as a starting point. When the feedback control is turned off, the master/offset setpoint PVs must be updated to the current setpoint values from FCOM.
  • We agreed that at this time, each IOC will have ONE PAU, but the design allows for more. NOTE: multiple PAUs may use the same timer (same delay value) even if the muxes patterns are different. We may want to pass in the timer to the PAU, so that PAUs may share the same timer 
  • The Timer wrapper should be in a shareable module, so that other apps in an IOC can use this module. Should be included under epics/modules
  • The Master/Offset setpoint PVs will be included in the PAU module. 
  • ISSUE: the local RF loop logic is placed inside the PAU (part of the data-pull processing(question) )This means that RF stations WITHOUT a PAU will handle local loops differently than those WITH a PAU.  This must be coded in a modular way so that it is easy to configure the RF control either way. This will add time to the RF development because it is likely that the RF controls we are not upgrading to use a PAU will still  have to change.
  • Ask Joe Frisch how to back propagate L2 Amplitude and Phase to 24-1 phase+24-2 phase+L2 Phase Shifter phase. This needs to be calculated when turning feedback control off - must read current 24-1, 24-2, L2 shifter values and set the Master/Offset setpoint PVs properly

TEXT FROM EMAILS on local rf loop algorithm

---Original Message-----

From: Himel, Thomas M.

Sent: Friday, September 04, 2009 8:52 AM

To: Kim, Kukhee; Fairley, Diane M.; Decker, Franz-Josef; Allison, Stephanie; Krejcik, Patrick; Akre, Ronald A.; Williams Jr., Ernest L.

Cc: Himel, Thomas M.

Subject: RF feedback 

At Kukhee's feedback actuator design review yesterday, the question came up about how to mesh the beam based feedback with the local feedback on the RF amplitude and phase. We had not actually gotten to those slides yet, but it was stated that with beam based feedback on, it would write directly to the PAC and the local feedback would effectively be disabled.  

I suggested it would be better to have the beam based feedback change the setpoint of the local feedback. That way, if the beam based feedback has a slower time constant than the local feedback, the local feedback would still be helping to correct the klystrons amplitude and phase at its fast rate. 

I was informed that with the current equations, when the setpoint of the local loop is changed that it gets implemented slowly (with the same averaging that is done for the local measurement) and that one needed to have the beam based changes happen immediately. 

I claimed there was a simple change to the feedback equations that would allow the setpoint change to be implemented immediately. This showed a lack for foresight on my part because I was immediately challenged to provide such a formula as a homework assignment. 

Well, I actually did my homework.  Here it is: 

The present formula for the local phase feedback is given on slide 37 and is Pn = Pn-1 + G(Pdes - Pavg). 

Here I believe Pn is the actuating phase shifter output on pulse n (actually converted to I & Q), Pn-1 is the same thing for the previous pulse, Pdes is the desired phase also known as the setpoint and Pavg is the most recently measured phase (if it is in fact averaged over multiple pulses as its name may imply, then my formula will need more work.). G is the gain and is typically set to 0.4. 

A modified equation which I believe does what we want is: 

Pn = Pn-1 + G(Pdes.n - Pavg) + (1-G)(Pdes.n - Pdes.n-1) 

Where pdes.n is the value of the setpoint on the nth pulse and Pdes.n-1 is the value of the setpoint on pulse n-1. 

Note that the last term is 0 if the setpoint has't changed, so this equation reduces to the original one in that case. 

Another simple limiting case is to consider Pavg = pdes.n-1. In that case, if the set point did not change, the output out not change. Plugging that into the above formula and simplifying gives Pn = Pn-1 +Pdes.n - Pdes.n-1  meaning Pn immediately changes by the change in the setpoint. 

----Original Message----

From: Akre, Ronald A.

Sent: Friday, September 04, 2009 1:19 PM

To: Himel, Thomas M.; Kim, Kukhee; Fairley, Diane M.; Decker, Franz-Josef; Allison, Stephanie; Krejcik, Patrick; Williams Jr., Ernest L.

Subject: RE: RF feedback 

Assuming Pavg=Pdes.n-1 which it should if the feedback is working, this does what we want. 

Something similar should work for amplitude. 

Thanks, 

Ron 

---Original Message-----
From: Decker, Franz-Josef
Sent: Friday, September 04, 2009 2:07 PM
To: Akre, Ronald A.; Himel, Thomas M.; Kim, Kukhee; Fairley, Diane M.; Allison, Stephanie; Krejcik, Patrick; Williams Jr., Ernest L.
Subject: RE: RF feedback

Hi Tom 

Rearranging your formula gives: Pn = Pn-1 + G(Pdes.n-1 - Pavg) + (Pdes.n - Pdes.n-1)  

First you compare the just measured value (Pavg) with the one you wanted (previously), on top of that comes the desired change (delta) in Pdes.

And it is all o.k. for the next pulse too (delta = 10, then Pavg+1 should be better Pavg + 10). 

FJD 

  • No labels