TuneMonitor

[gubaidulinvadim]

This is a discussion for issue python-accelerator-middle-layer/pyaml#20. Presently, in the user interface specification document (https://www.overleaf.com/project/67d2a09691a906145ca2235e) we have the following written for TuneMonitor:

Betatron tune monitor

A \verb|BetatronTune| handle measurement of betatron tune and inherits from \verb|Element|. For the betatron tune adjustment, the tune response matrix is referenced in the configuration file (it can be either obtained from measurement or from design).
Tune monitor configuration (tune\_monitor.yml') should be flexible and allow to define several different tune monitors originating from different hardware/measurement method and use different response matrices. A standard object name (for example, tune_monitor') of the class \verb|BetatronTune| will be used to define which monitor will be used in common high-level applications.
The way the tune is set, for example which quadrupole family is used, is also defined in the configuration

\pymethod{h: ReadWriteScalar}{gets/sets the horizontal tune.}
\pymethod{v: ReadWriteScalar}{gets/sets the vertical tune.}
\pymethod{update_optics()}{if not available, computes tuneRM based on design and stores it the ML data folder.} 
% {\color{red} JLP and SL: should such update method be a measurement if working in live mode?}}

Longitudinal tune monitor

Similarly to the \verb|BetatronTune|, A \verb|LongitudinalTune| can be defined to measure the longitudinal tune.

\pymethod{l: ReadWriteScalar}{gets/sets the longitudinal tune.}
\pymethod{update_optics()}{if not available, computes tuneRM based on design and stores it the ML data folder.}

Combined tune monitor

The betatron tune monitor and longitudinal tune monitor can be combined into one \verb|ElementArray| for machines that want to
measure all three components simultaneously. In case the slowest measurement gives the rate of the array.

I'm not sure that it's a good idea to have set option for the tune. This would mean that the TuneMonitor device has access to and knowledge and the quadrupole/quadrupole corrector families necessary for tune correction and the response matrix. For me, this would be more logical to have a light 'device' that only monitors the tunes and a separate 'device' or tuning tool that will act on the tune. In many applications, we also only need to monitor the tune value but not to change it. I would propose to separate the set() and update_optics() functionality into the tuning tools.

[JeanLucPons]

No problem for me.
We can still have a get()/set() for the tuning tools tune object that bind to the tune monitor device.
So it is always possible to have:

sr.live.tune.get() # Gets the tune from the standalone tune monitor

sr.live.tuning.tune.get()  # Gets the tune from the underlying tune monitor
sr.live.tuning.tune.set( ... ) # Sets the tune

[TeresiaOlsson]

I agree with @gubaidulinvadim. I think it would be good to separate it into two devices, one TuneMonitor and one TuneCorrector to make the functionality more modular and have one device which is a pure diagnostic device.