Choose timezone
Your profile timezone:
LHC FBs - weekly meeting
→
Europe/Zurich
Meeting Date: 21-Apr-20 09:30
Location: https://vidyoportal.cern.ch/join/TKVQlkE5c5
Link to Outlook Item: click here
Invitation Message
Participants
Diogo Miguel Louro Alves (Meeting Organizer) - present
Jorg Wenninger - present
Andrea Calia - present
Stephen Jackson - present
Leander Grech - present
Notes
- Pending actions
- BI
- DA + LG: sanity checks of twiss parameters - done and tested from BI side
- Implementation was done in the design file
- OpticsLoader property was made operational and min/max value-items were added
- DA + LG: revert some changes already done for the cancelled "logging Vs feedback functionality" action - done
- DA: Revisit swapped BPMs - ongoing
- Me, Michal, Andrea and Joel had a meeting on this matter. We understood the intention of what was done in the CFV-SR1-BPME crate. The idea was to duplicate the electronics and signals for 2 physical BPMs that see both beams: BPMWF.A1R1 and BPMWF.A1L1 so that the BPM FESA class could easily produce position data for both B1 and B2 in a standard way.
- The conclusion is that the only way to actually confirm which BPM is in which slot is to go there and physically check the fibre connections. There is contradicting documentation on this matter.
- DA: setup meeting with Jakub Wozniak, JW and SJ - done
- Metadata must be published by the FESA class and NxCALS will provide an API for linking the vector numerics data with the corresponding device.
- This metadata can be published periodically at virtually any rate and NxCALS will downsample it as it sees fit
- Mappings property needs to be notified and subscribable - ACTION on DA - done - at the moment this is being done every minute with a dedicated timer and in a dedicated concurrency layer
- DA + LG: check possibility of preventing turning ON the FBs in case valid optics have not been loaded - done - implemented in the SetOrbitAndEnergyFBState server action, it will throw if the calculation status of the active optics is not SUCCESS
- DA + LG: sanity checks of twiss parameters - done and tested from BI side
- OP
- none
- BI + OP
- none
- BI
- Updates from BI
- DA + LG: AC reported that response matrix test is not working
- DA + LG: investigations revealed that this is due to the eradication of the bootstrap file. The bootstrap file used to dictate the element order but now the order is dictated by the BPM2CRATE.mapping and COD2CRATE.mapping files. We believe that the RM entries are correct but it's just that some B1 and B2 COD columns are interleaved, thus causing the observed mismatch. We have proposed that OP generates these files with the various elements in the desired order and provides them to the feedback system which will not change this order.
- DA + LG: exposed OT triggering mechanism in OrbitTriggerAcquisition property - initial implementation done and new field added to OrbitTriggerAcquisition property but further testing is required
- DA + LG: master switch can now be controlled and monitored from the MasterSwitch settings property - the master switch now controls not only the old master switch but also enables/disables packet sending (used to be in CODSender settings) as well as enabling/disabling sending of tune packets.
- SJ: comment that this was used in the past, for example, to assess the sanity of the corrections before actually sending them to the gateways
- JW + AC: leave it like this for the moment and then we can see whether there's use cases to make it more flexible
- Questions for OP:
- Is the FeedForward property required? There's a field (userRFTrim - this is the same field used for the radial modulation, no?) that is required?
- JW: erradicate this property completely
- Regarding the old RefQQP property:
- Tune function player references should be added to a TuneFunctionPlayerSettings property
- requestedTuneB1/2 fields, what are they used for?
- These seem to have been manual tune references, is that true?
- Still use case for manual tune references?
- JW: it should all go through functions - manual tune references are no longer required
- Tune FB switch on/off feedback
- At the moment we have tuneFBStateB1/2 with the possible enum values of: OFF, ON, ON_H and ON_V. How would OP like to have this now?
- JW + AC: 4 independent cmd properties are preferred - ACTION for DA + LG
- At the moment we have tuneFBStateB1/2 with the possible enum values of: OFF, ON, ON_H and ON_V. How would OP like to have this now?
- Reset QQp FB
- cmd property - ACTION
- Is the FeedForward property required? There's a field (userRFTrim - this is the same field used for the radial modulation, no?) that is required?
- DA + LG: AC reported that response matrix test is not working
- Updates from OP
- ACTION - as per BI request - provide min/max limits for the OpticsLoader property
- ACTION on DA+LG: update paths for confdata (mapping files et al) - wget http://bewww/ap/deployments/applications/cern/lhc/lhc-feedbacks/lhc-orbitfeedback-hw-configuration/PRO/source/src/main/resources/ofb/ in the GPN and /user/pcrops/deployments/applications/cern/lhc/lhc-feedbacks/lhc-orbitfeedback-hw-configuration/PRO/source/src/main/resources/ofb in the TN
- AC: cleaning up on the Java side and David is developing components for high level API
- Planning for the week
- BI: carry with the various identified actions and start to implement the tune references
- OP: will finish this mapping issue and fix the CI integration to regenerate the docker images
- AOB
There are minutes attached to this event.
Show them.