You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description, motivation and use case RFHolder already resolves named RF plants and exposes frequency and voltage from DEFAULT_RF_PLANT. The original holder proposal expresses this default RF plant as rf.masterclock, which makes its role explicit and leaves room for other RF plants under the same holder.
This improves readability in control applications that operate on the machine master clock while still supporting named RF plants.
Proposed solution
Add rf.masterclock, returning the RF plant configured as DEFAULT_RF_PLANT:
rf.masterclock.frequency exposes its frequency access.
rf.masterclock.voltage exposes its total-voltage access.
rf.get(name) continues to resolve other RF plants by name.
Retain rf.frequency and rf.voltage as backward-compatible aliases for the corresponding masterclock accessors. Raise a clear PyAMLException when DEFAULT_RF_PLANT is absent.
Describe alternatives you've considered
Keeping only rf.frequency and rf.voltage is compact but hides which configured RF plant they refer to. Making masterclock a separate object would duplicate the RFPlant API and create unnecessary synchronization concerns.
The current RFHolder already implements get(name), frequency, and voltage. This issue introduces the explicit default-plant façade proposed in #199 while retaining the current shortcuts.
@gupichon, I am not sure I understand this issue. With the present implementation, I think we cover the simplest case of RF, where there's one single "effective cavity".
rf.masterclock.voltage would not make sense because masterclock is only a clock for the frequency.
sr.design.rf currently refers to "DEFAULT_RF_PLANT" in the configuration, similarly to other utilities like sr.design.tune referring to "DEFAULT_TUNE_CORRECTION". If it's not defined, you need to do sr.design.rf.get('NAME') to obtain the RF object that you need.
For my case, with multiple RF cavities that each have their own voltage is not really covered in detail at the moment. And I don't see if this is necessary in the near future.
@GamelinAl, is there a need to have a more detailed RF implementation?
Activity
gubaidulinvadim commentedon Sep 15, 2026
@gupichon, I am not sure I understand this issue. With the present implementation, I think we cover the simplest case of RF, where there's one single "effective cavity".
rf.masterclock.voltagewould not make sense because masterclock is only a clock for the frequency.sr.design.rf.get('NAME')to obtain the RF object that you need.For my case, with multiple RF cavities that each have their own voltage is not really covered in detail at the moment. And I don't see if this is necessary in the near future.
@GamelinAl, is there a need to have a more detailed RF implementation?
GamelinAl commentedon Sep 15, 2026
I would say probably not at the current time.