Feature: add control system access to pyAML elements

[GamelinAl]

Description, motivation and use case
For each relevant type of pyAML element, we should provide a shortcut access the the underneath python control system layer (e.g., pyTango/pyEPICS).

Use case: I can easily find BPM.145 using pyAML interface, I use the shortcut access to control system to modify the BPM electronic board configuration (which is not accessible at pyAML level).

Proposed solution
Provide a standard way to access the control system object/properties via its pyAML element:

• Element.cs_object would return the object Tango device, i.e. a DeviceProxy object (AN20-AR/EM/OH.04-CQLN.22) or corresponding EPCIS PV.

I considered if we needed a direct access to the CS attribute (AN20-AR/EM/OH.04-CQLN.22/strength) directly but I don't see the point (at least for Tango) because it's the property that we already link with pyAML.

Example
Sextupole.cs_object returns a tango.DeviceProxy: Magnet(an20-ar/em/sext.12)

[gubaidulinvadim]

Wouldn't it be enough to give a control system name instead of an object? Then you can just do DeviceProxy(pyaml_element.get_cs_name()) in Tango and something else in EPICS?

[kparasch]

I think going with a control system name as @gubaidulinvadim proposed is probably better to stay general between tango/epics/doocs.

From what I understood in the last community meeting, epics names are non-hierarchical, so an address like AN20-AR/EM/OH.04-CQLN.22 wouldn't point to anything. It can be that all addresses which are related to that device will still start with "AN20-AR/EM/OH.04-CQLN.22", but it depends on the control system implementation.

In doocs, the situation is a mix between tango and epics. AN20-AR/EM/OH.04-CQLN.22 would point to a doocs server that handles different properties (e.g. AN20-AR/EM/OH.04-CQLN.22/X, AN20-AR/EM/OH.04-CQLN.22/Y) but there is no device object on the side of the client. Communication still happens only to properties directly.

In summary, I think an optional field like cs_name would be nice to have, which can be specified in the configuration files if one wants it.

[GamelinAl]

For me it's better to provide a direct access if possible and it does not cost much. But I understand that it can be more difficult in EPICS/DOOCS but maybe still possible.
That's also something we should be clear about. Do we restrict pyAML functionalities to what we can fully implement in all 3 control system or not? Is it ok to have convenience function for some control system which are not implemented in others?

For the control system name, it is alreay proposed in #46.

[gubaidulinvadim]

@GamelinAl, you are on 'congé'... I think it's a bit of a hassle to add an object. tango-pyaml links pyaml device properties to tango attributes, not to tango devices. So, at the moment (if I understand correctly) Tango device is not defined anywhere.

[TeresiaOlsson]

For me it's better to provide a direct access if possible and it does not cost much. But I understand that it can be more difficult in EPICS/DOOCS but maybe still possible.
That's also something we should be clear about. Do we restrict pyAML functionalities to what we can fully implement in all 3 control system or not? Is it ok to have convenience function for some control system which are not implemented in others?

For the control system name, it is alreay proposed in #46.

I think convenience functions that only work for one control system is not a good idea because then people might use them in applications without knowing and the application isn't sharable anymore despite that the intention was that it should be.

If tools like that is required I think a better solution is to add it in a separate repository. Then it's clearer that it's a separate thing to extend some functionality. Same as for lab-specific functionality except that in this case it's control system specific functionality.

However, in this specific case I think the problem can be solved by using ophyd-async devices. They have access to the underlying TANGO device like that.

[TeresiaOlsson]

I'm working on it but as a part of an example showing how it would work if we decide to go for full ophyd-async devices and not just including the ophyd-async signal level in the bindings.

[gubaidulinvadim]

@GamelinAl would be good to know what is missing. I think for all elements you can find a string of the device attribute or a PV. In BPM, you have x_pos, y_pos, in magnet you have powerconverter. I think this is always available now. So, it is possible to do

x_pos_attribute_proxy = AttributeProxy(sr.live.bpm.x_pos)
bpm_device_proxy = DeviceProxy(sr.live.bpm.x_pos.rsplit('/', 1)[0])

Getting device proxy is a bit ugly because you need to split by /, but why not.

Yellow pages also cover this.