Add option to disable the control system when loading a PyAML file

[gupichon]

Description:
It should be possible to disable the control system when loading a PyAML file.
This would allow users to load and inspect the configuration (e.g. design, devices, hierarchy) without requiring a live connection to Tango or any other control system backend.

Motivation / Use case:
Enable offline analysis or validation of PyAML files.
Facilitate unit testing without requiring a running control system.
Simplify workflows for configuration editing or inspection tools.

Proposed behavior:
Add an optional flag such as enable_control_system: bool = True (default True) to the PyAML loader or configuration.
When disabled (False), no DeviceProxy, AttributeProxy, or control-system-related initialization should be performed.
The corresponding live section or ControlSystem objects should remain accessible but inactive (e.g., mock or empty implementations).

Example:

from pyaml import PyAML

ml = PyAML("machine.yaml", enable_control_system=False)
sr = ml.get("sr")

# The design tree can still be accessed
print(sr.design.get_magnet("QF1A-C01"))

# But control system operations are disabled
sr.live.get_magnet("QF1A-C01").hardware.set(1.0)  # Should raise or be a no-op

[JeanLucPons]

It would be nice also to deal correctly with control system initialization or to redo the binding so that devices are not instantiated before the control system is initialized. We already had a discussion around this but nothing has been done yet.

[gupichon]

@JeanLucPons Thanks! At the moment this is handled only in the tango-pyaml binding (see PR #13). However, this really belongs at the pyaml level.

The idea is: load and validate the full configuration first, and only then initialize the control system explicitly. Initialization should be an opt-in callable, e.g.:

from pyaml import PyAML

ml = PyAML("machine.yaml", enable_control_system=False)  # parse + validate only
ml.enable_control_system()  # establish connections explicitly

This separation avoids side effects during parsing, enables dry-runs/tests, and makes initialization timing explicit.
These changes should be implemented as part of the resolution of this issue.

[JeanLucPons]

Ok.
In any case (control system enabled or not), the devices need to be instantiated after the CS initialisation. Today I have to work around this by pre-setting the TANGO_HOST variable which is annoying.
In a previous discussion, the following proposal has been made:

put "controls" field outside the instrument and construct pyAML like this:

   set_root_folder(rootfolder)
   aml_cfg = load(os.path.basename(filename))
   if "controls" in aml_cfg:        
        # Make sure CS is done first

        controls = d.pop("controls")
        csList = Factory.depth_first_build(controls)

        for c in csList:

            c.init_cs()

        ....

    aml:PyAML = Factory.depth_first_build(aml_cfg)

[gupichon]

Yes — I agree: we should be able to load a YAML without requiring the live/control-system part. For example, a user working locally should be able to run with just the design/model side. Maybe an environment variable or a flag like disable_live=True when loading would do it.

Also, I agree that the control-system configuration should live at a top level (global), not inside each instrument definition.

[JeanLucPons]

Right, i have nothing against the flag: enable_control_system=False but:

If the device is not instantiated inside the constructor of DeviceAccess but within the Device Factory. It will allow:

• immediate model validation.
• enable_control_system flag would be useless as device would be instantiated only when you make real access to it.
• this would also work with the present control system initialization and fix the TANGO_HOST bug.

This model is use in Tango ATK.

class ConfigModel(BaseModel):

    attribute: str
    """Name of tango attribute (i.e. my/ps/device/current)"""

class Attribute(DeviceAccess):

    def __init__(self, cfg: ConfigModel):
        self._cfg = cfg
        # Extract device name and attribute name from fully qualified attribute name and check for Tango name syntax
        self._dev_name = devname(cfg.attribute)
        self._att_name = attname(cfg.attribute)

    def name(self) -> str:
        return self._cfg.name

    def measure_name(self) -> str:
        return self._cfg.name
   
    def set(self, value: float):
        Factory().get_instance().get_device(self._dev_name).write_attribute(self._att_name,value)

   ...

[gupichon]

I have created the matching issue for tango-pyaml: #15

[TeresiaOlsson]

It will also be required for simulated commissioning. At that point you likely have no control system configuration yet. And if you are a brand new facility you might not even have decided which control system you want to go for.

[TeresiaOlsson]

After looking at ophyd-async and testing it both for EPICS (at BESSY II and MLS) and TANGO (at MAX IV) I'm wondering what the reason is for the cs_init step? What is required to be done there? Is it just to set the TANGO host or something more? It looked like @yhidaka didn't have to implement it in the ophyd-async bindings which means that it's currently something only required for the tango-pyaml bindings. Or have I misunderstood it?

I'm wondering if we could solve this issue by copying how it's done in ophyd-async? As I understand it, the reason it's not needed there is because the connection to the control system isn't done until you run connect on the device which will then connect the individual signals. For the TANGO host we tested at MAX IV that it could both be read from the TANGO_HOST environment variable or be overwritten by putting the host in front of the attribute according to the syntax for the tango trl:

[protocol://][host:port/]device-name[/attribute][->property][#dbase=xx]

So my question is, can't we do the same and remove that initalization step?

[JeanLucPons]

If you don't specify a TANGO_HOST in the attribute name, it will get by default the environment variable. The TANGO_HOST variable needs to be initialized prior to any connection. Today the native Tango binding prevents to use several TANGO_HOST and this should be done later.

controls:
  - type: tango.pyaml.controlsystem
    tango_host: acs.esrf.fr:10000
    name: live
  - type: tango.pyaml.controlsystem
    tango_host: ebs-simu-1:10000
    name: simu1
  - type: tango.pyaml.controlsystem
    tango_host: ebs-simu-2:10000
    name: simu2
  ...

We don't want to specify the TANGO_HOST in the attribute name in the yaml file, otherwise this will prevent the above to be implemented. I have no objection to remove the init_cs() but to you will also have to redo https://github.com/python-accelerator-middle-layer/tango-pyaml/blob/a6175160d98b3fef5e1ad874da7ef4b6d1eeefa2/tango/pyaml/controlsystem.py#L121.

[TeresiaOlsson]

My suggestion is not to change how it's done in the yaml file. The tango_host and attribute should still be two separate fields like they are at the moment. The idea is just that instead of relying on the TANGO_HOST environment variable, the code will automatically add the tango_host from the configuration to the attribute and use the trl to connect with the control system.

The way it's done for TANGO would then match how it needs to be done for EPICS. In the EPICS case, instead of a host the yaml file would define a prefix which is added in front of the existing PV prefix and the live machine and virtual accelerator would have different prefixes.

In that way, it becomes easy to have as many control systems simultaneously as you like and it's possible to push all the initialization steps to when a device is initialized. When we tested at MAX IV we had problems with the tango-pyaml bindings because it was done in two steps whereas it worked much easier in ophyd-async where no common initialization step is required and it's all done at the device level. Then we could for example create a single device just for testing purposes and playing around without having to set up any configuration at all. When we tried that using the tango-pyaml bindings it didn't work because we were missing the cs_init step that needed to be done separately from the device.

I will try to write a pull request with the change.

[JeanLucPons]

My suggestion is not to change how it's done in the yaml file. The tango_host and attribute should still be two separate fields like they are at the moment. The idea is just that instead of relying on the TANGO_HOST environment variable, the code will automatically add the tango_host from the configuration to the attribute and use the trl to connect with the control system.

Yes this is how we would like to handle the connection to multiple control systems.
This is a bit tricky to implement:

• Need to refurbish current native Tango backend and add a connect() that will return a new DeviceAccess attached to the good CS.
• Refurbish control.abstract_impl.py so that each implementation work with correct references of DeviceAccess, something very similarly to what is done for Simulator and AT element reference.

I can help in the refursbishment of abstract_impl and Tango backend if you want.

[TeresiaOlsson]

That sounds very good. It would be nice if you could help because at the moment I don't have any really good way to test if it's working correctly and I'm still in the process of learning the details of TANGO.