Repository navigation
Feature: Add setpoint check before applying strengths #106
Description
Description, motivation and use case
In order to avoid that a set of magnet are only partially set, pyAML should check that all power supply setpoint and achievable.
Proposed solution
- Add a valid range to each powerconverter as in the example.
- Add a
setpoint_check()method to MagnetModel that will basicallycompute_hardware_values()and check that all values are in the expected range. If one setpoint is out of range, aPyAMLExceptionshould be raised. - Modify control/abstract_impl.py and add setpoint_check() calls when needed.
- type: pyaml.magnet.cfm_magnet
name: SH2B-C04
mapping:
- [B0, SH2B-C04-H]
- [A0, SH2B-C04-V]
- [A1, SH2B-C04-SQ]
model:
type: pyaml.magnet.linear_cfm_model
multipoles: [B0,A0,A1]
units: [rad,rad,m-1]
pseudo_factors: [1.0,-1.0,-1.0]
curves:
- type: pyaml.configuration.csvcurve
file: sr/magnet_models/SH2_h_strength.csv
- type: pyaml.configuration.csvcurve
file: sr/magnet_models/SH2_v_strength.csv
- type: pyaml.configuration.csvcurve
file: sr/magnet_models/SH2_sq_strength.csv
matrix:
type: pyaml.configuration.csvmatrix
file: sr/magnet_models/SH_matrix.csv
powerconverters:
- type: tango.pyaml.attribute
attribute: srmag/ps-corr-sh2/c04-b-ch1/current
range: [-2.0,2.0] # Power supply range
unit: A
- type: tango.pyaml.attribute
attribute: srmag/ps-corr-sh2/c04-b-ch2/current
range: [-2.0,2.0] # Power supply range
unit: A
- type: tango.pyaml.attribute
attribute: srmag/ps-corr-sh2/c04-b-ch3/current
range: [-2.0,2.0] # Power supply range
unit: AMetadata
Metadata
Assignees
Labels
No labels
Activity
gupichon commentedon Jan 9, 2026
Should the 'range' field be mandatory or not?
gupichon commentedon Jan 9, 2026
Maybe the availability of the powerconverters should be tested too ?
JeanLucPons commentedon Jan 9, 2026
I would say that the range is not mandatory. If the range exists the validity check can be done otherwise we consider that the setpoint can be sent to the PS.
Concerning, the state of underlying PS (is there a FAULT or not) ,I would say that this should also be handled but here some discussions are necessary to find an agreement on PS states management. Today the power converter is a DeviceAccess object, we may need an extra layer if we don't manage to define a common behavior concerning PS states.
gupichon commentedon Jan 9, 2026
State management should be handled by each institute (and even within an institute, there can be debates about it). Maybe we only need a generic module to test the availability of the underlying hardware (for example, a simple ping for Tango)?
gupichon commentedon Jan 9, 2026
Since device access is implemented in the control system layer and is generic for all devices (including BPMs, for instance), I will add check_write_value(float value) and check_device_availability() methods to the device access. This will give us the possibility to use the control system tools. For Tango, the min and max values are available through the device interface, so this field is not even necessary.
JeanLucPons commentedon Jan 9, 2026
Yes if the range is not available in the config file, it can retrieved from the CS device itself.
I would not add a check_write_value() in
DeviceAccessbut rather aget_range()with a priority for the range defined in the config file.I'm not really in favor of having a
ping()in the setpoint check, this should be calculation only. For EBS, writing all the strengths is already long. If the writing fails due to a PS fault, a PyAML exception is returned.gupichon commentedon Jan 9, 2026
A ping is the fastest way to reach a device; it does not take long. Basically, it is a default command that does nothing. It is even faster than checking the state. I suggest either doing a simple ping and letting each institute implement its own behavior, or not implementing it yet.
gupichon commentedon Jan 9, 2026
Ok for the get_range()
With nan's if there ther is no boundary ([0.0, nan] -> 0 to infinite)