We discussed the basic architecture of the feedback timing and data handling in order to complete an API for the feedback controller <-> Fast Feedback Network software interface.
NOTE:
New goal: allow feedback to work on either FastFeedback Network, or Channel Access network
Decisions made:
the Network <--> Controller Inteface API includes the following methods
information included in all 'data' = devicename, data value, data quality, timestamp/timeslot
Additional notes on the above
1) one idea was to have an event code per feedback, or a delay per feedback, which would allow the processing for each feedback to start at a programmable time after the fiducial. Example: If a particular measurement device needs more time to provide data for a feedback then that feedback can wait longer for its incoming data. Phase II feature? To begin with this can be a single 'hard-coded' delay for all feedbacks.
The "sleeps until feedback event" will include a timeout (this is different from the delay). The timeout will occur if the fiber is disconnected from the EVR or the event code is disabled or etc. Your timeout processing is for another discussion (maybe just set status?). Just like the discussion for missing measurement and
bad actuator status is for another day.
If programmable delays are used and if the delay is too long (more than 8 msec), "getPattern" will get a pattern that is too new (the pattern from the fiducial that started the delay clock is overwritten). In this case, you need to wake up once, get the pattern, sleep a little longer, than get the data. Otherwise, we need to keep pattern history that you can browse to find the one that matches the data which would be part of phase II.
2) the getPattern call provides the timing pattern and time-slot information associated with the current pulse
Probably a detail but you may want to do the pattern matching (to decide if you care about this pulse) and go right back to sleep without bothering with getData if you don't care. Won't delay other loops that may have real work to do.
3) The communications 'team' provides the getData function. This is mid-level code that, on request, packages data into a 'vector' based on the list of names. This 'vector' includes value, quality (good, bad), timestamp for each device/attribute named. Different data vectors are needed by different feedback controllers.
We also decided that the actuator IOCs will send value/status/timestamp using the same communication method as the measurement IOCs. So the getData call will get both the new measurements and the previous actuator settings. Note that the timestamps on the actuators will not be the same as the new measurements coming in - I think the timestamp checking on the actuator data can use a tolerance - as long as they're not too old.
Not really relevant to a requirements discussion, but we thought that there probably needs to be 2 intermediate software layers on top of the data. One lower general-purpose layer that other apps can use if they so desire and one on top of the GP layer that is unique to fast feedback.
4) processing loop includes reviewing timestamps to be sure data is from same pulse, and eDef like pre-processing of pulses before calculating new actuator settings. eDef-like processing includes comparing the pattern to a pattern requested by the feedback (part of the feedback configuration) and deciding if the incoming pulse data is to be used, averaged, or tossed out.
We decided that we don't need to implement priority - that feedback loops will be woken up (all at the same time) in ANY order. Actually, if callbacks are used, then it's not that much work for the loops to register themselves as high, medium, or low callbacks.
Did you want to always be woken up at 120hz whether or not there is beam? (The pattern tells you if there's beam or not). If the maximum beam rate for a run is 30hz, do you still want to be woken up at 120hz?
5) setActuators gives a vector of new actuator settings to be sent to the actuators. The time-slot during which the actuator setting is applied, is included - we assume it will actually be indicated by the name, since we expect the actuators to have a PV per Desired setpoint per time-slot. We hope to implement feedbacks on different time-slots as independent feedbacks.
6) We already have a utility package (developed for the slc-aware IOC) for sending inter-thread messages on IOCs. We should make it a design requirement to use this package for communication between threads if two or more feedback related threads operate on the same IOC.
If we need to, we can make the communication technique invisible to the calling thread by creating a wrapper around this message package and the ethernet communications, let the wrapper code make the choice...
7) NEW: make FF or CA a configuration item. the 'middle layer' of controller software then can either:
read measurements and actuator readbacks from PVs, or FF shared memory
set actuators via PV or FF shared memory
set feedback results in PVs or FF shared memory
We can run slow loops over channel access then, and test controller software using a softIOC
8) Stephanie's suggestion for event codes for feedbacks
> Use of one event code per feedback loop
Just a thought about this based on our discussion today and Till's suggestion about delay. If we could keep the number of event codes down to a manageable number like 10 (ie, not one event code per feedback loop but rather one event code per group of feedback loops), then it would be possible to enter the delay value on the EVG IOC and have the EVR IOC wake up on the event code and get the data right away without additional delay.
There are some caveats:
(0) The EVG IOC interface for event codes would need some changing to handle delays that span fiducials (as Till suggested).
(1) If the delay value coincides with the delay value of another event code, the software automatically chooses the next available slot (so the real delay may be slightly different from the actual delay though hopefully by not more than a few 8nsec slots).
(2) All feedback loops using that event code will be forced to use the same delay.
(3) When the event code stops coming out (ie, lost beam), if the feedback loop wants to do some sort of no-beam cleanup processing, it'll need to wake up on its own (but may be able to use the 20msec system timer for that instead of the high-resolution timer).
(4) If the delay is too long, the pattern associated with the beam is lost off the pipeline on the EVR IOC.
(5) Event code processing on the EVR IOC may need some changes depending on the requirements of the feedback. Event record processing is supported but I'm not sure how it works with a regular sequence or task.
(6) Sonya has reported some problems with event code processing happening too late. This may be a bug that would have to be fixed for feedback. It could be a problem with the EVR ISR.
BTW, event code processing can be simulated (slowly) on linux soft IOCs so that's nice for testing.
