set/get and readback with same behaviour for TANGO and EPICS

[TeresiaOlsson]

I have been trying to understand how the setpoint and readback works in TANGO compared to EPICS and I think I have finally understood it with some help from @gubaidulinvadim, looking at the code from @gupichon and the presentation by Benjamin on the community meeting. Now I'm trying to understand what we need to get the same behavior in TANGO and EPICS when using the same pyAML command.

This is how I currently understand how the TANGO bindings work. Is this correct @gupichon?

• You configure one TANGO attribute per pyAML device attribute. This attribute could be read-write or read only in your TANGO device but this you don't specify in the pyAML config. Do you need to specify it somewhere in pyAML? Maybe it's in the implementation of the device?
• For pyAML you bind set to write_attribute_asynch in pytango which writes asynchronously.
• Then you have a function set_and_wait bind to write_attribute which writes synchronously and the user needs to input a wait time.
• You bind get to read_attribute.w_value which reads the last value that has been written to the attribute - so you get the existing setpoint.
• To get the readback you bind readback to read_attribute but then do something in addition which I don't fully understand. Is it some metadata so the readback returns more than just the value?

            quality = Quality[attr_value.quality.name.rsplit('_', 1)[1]] # AttrQuality.ATTR_VALID gives Quality.VALID
            value = Value(attr_value.value, quality, attr_value.time.todatetime() )

This I understand how it works for magnets because then the user is mostly interested in reading the setpoint. The readback you only need for determining if the device has finished moving or not (and this maybe TANGO already does automatically?). But how does it work for a BPM? Can you still read the BPM with get or you need to do it with readback? Will a read-only device in TANGO also have the read_attribute.w_value?

Then for EPICS I think we have the following situation:

The setpoint and readback are separated into two PVs. We also need the solution to work for both channel and PV access ideally with the same behaviour for both. See Issue #21.

We could maybe do the following:

• We configure a setpoint and a readback for each pyAML device attribute. The setpoint is always read-write and the readback read-only but that we don't specify in the config but at some level of the EPICS specific implementation. This seems to me somewhat similar to the Setpoint and Monitor fields in MML.
• We bind the setpoint to set but I'm not sure how easy it is to make it asynchronous without using asyncio and then the behaviour would be different between TANGO and EPICS which is perhaps not so nice?
• The set_and_wait function I don't think we want to have. We rather want the device to have a status when it is done moving and wait until then so the user never have to specify wait times anywhere.
• We bind get to the setpoint.
• We bind readback to the readback.

This will however give us the problem that we need to read the orbit with readback rather than get which isn't nice and the users won't like since the default command to read a device won't be the same for all devices. For EPICS it feels like maybe we need some functionality where we can have a general get function and to that function specify if we want to get the setpoint or readback? Like how it is done in MML or pytac?

What do you think?

[eddybl]

It would be helpful to have a concrete code snippet (can be simplified) to show how Tango would do read and read/write.

Maybe use a power supply as an example with the following "features":

• Set new current value
• Read measured current
• Read set current
• Read status (on / off)
• Change status to off and/or on

[TeresiaOlsson]

I think I have understood it by looking at the implementation of the Tango bindings, reading the pyTango documentation and trying with @marlibgin2 in the MAX IV control room.

You need to first create a proxy for a Tango device. When you read an attribute it returns a structure where value corresponds to the readback and w_write contains the last value that was written to the device (i.e. the current setpoint). Here is a screenshot from MAX IV where we made a device for a quadrupole power supply and read it.

pyTango also has asynchronous versions of the read/write methods, so there is both read_attribute and read_attribute_async. The async version will return an id which you later can use in a second command to retrieve the result. At least at MAX IV this is what they currently use in their MML setup.

In addition to this, there is also a way to read groups of devices. As I understand it, if you have devices with the same attributes you can group them and read them all at once. At MAX IV they use this in MML for reading the BPMs. This is the documentation for that: https://tango-controls.readthedocs.io/projects/pytango/en/latest/api/client_api/group.html#tango.Group

[TeresiaOlsson]

I have not fully understood yet what the _async methods actually do. In the documentation there is also an example using asyncio and it says that is the way to use for the future but it doesn't show how this is connected to the _async methods https://tango-controls.readthedocs.io/projects/pytango/en/latest/tutorial/green_modes/green_modes_client.html#asyncio-mode.

It seems like somehow the _async methods make use of asyncio if you choose that mode but that there also other modes to choose from. If it's just a wrapper to make it easier for the user and they don't need to care about things like await and event loops it sounds like a very nice solution to me.

[gupichon]

Hello @TeresiaOlsson , your conclusions seems correct to me.
The binding with tango must be improved. I have done only the minimal for now. The async mode must be improved and the set_and_wait feature must be change regarding to the specification.
I'll do that in a nearby future.

[TeresiaOlsson]

I think the tango bindings are already pretty good. I think we could copy your code and make something similar for the epics bindings as a start.

The problem for me is on the device level. That doesn't seem to be sufficiently general to add epics bindings. But I have also not fully understood how the tango bindings connect to the pyAML devices. There is this https://github.com/python-accelerator-middle-layer/pyaml/blob/main/pyaml/control/device.py but that has a setpoint and the readback and no attribute. Where does the attribute come in?

If I have understood it correctly, the base class for devices is DeviceAccess https://github.com/python-accelerator-middle-layer/pyaml/blob/main/pyaml/control/deviceaccess.py but I don't think it's sufficiently general. If the methods instead where something like set, get_setpoint and get_readback it would be easier to add epics bindings where setpoint and readback are separated into two different PVs. Then I guess it would be possible to later add a generic get method that for settable devices per default returns the setpoint and for read-only devices returns the readback so the user can use the same command to read independently of the type of device.

[eddybl]

Not sure if I am missing the obvious: Is there currently an implementation on any of the pyaml branches which actually has a tango readout implementation?

Also, if we the "tango/epics bindings" for me this means the implementation in the pyaml code, not the actual bindings itself. I don't think pyaml will/should try to change the upstream code of the bindings, but rather work on how to use the existing possibilties of the bindings (unless something is actually broken)

[gubaidulinvadim]

@eddybl there's a repository named tango-pyaml that set's up tango 'bindings' for pyaml repository. This is a simple mapping of DeviceAccess class of pyaml to TANGO device/attribute.

@TeresiaOlsson, I don't follow what do you mean here. Is your suggestion "let's simply rename the existing methods" because you don't find the names of the methods intuitive?

[TeresiaOlsson]

@gubaidulinvadim This is my current understanding:

• The default method for reading a device will be different if it's a read-only or a settable device. At least for MAX IV it looked like the user needs to do readback to read a BPM (where there is no setpoint to read) and get to read a magnet (where the user in most cases is interested in the setpoint rather than the readback). I think that is a worse user interface than in MML where you can either use getsp and getam or the generic getpv where you specify if you want the setpoint or monitor field since you can only use get for some devices and it isn't clear from the name of the method that it is the setpoint you get.

• For EPICS the setpoint and readback is separated into two PVs. So when in TANGO there for example can be one current attribute, that in EPICS needs to be one current_setpoint and one current_readback similar to like in MML where there are separate fields for setpoint and monitor. That will quickly get annoying if a device has many attributes but similarly it will be annoying for TANGO with separate fields since the user then needs to add the same attribute at two places in the configuration (I think that is the case for MML since it was EPICS only in the beginning).

  I'm currently thinking that one solution might be to define something like a pyAML attribute which for TANGO just links to a TANGO attribute whereas it for EPICS links to one setpoint and one readback PV. I currently trying to figure out how they do this in ophyd-async because they have a declarative way to generate devices where the user can specify if it's a TANGO or EPICS device and then the code creates the correct device for them. But I'm not sure if I like it or not yet. I'm still trying to play with it to see if I think there is some good idea there which is worth for us to borrow. Here is an explanation of it: https://blueskyproject.io/ophyd-async/main/explanations/declarative-vs-procedural.html. I'm thinking that maybe it could be possible to write a generic pyAML device with the pyAML attributes one wants and then using some declarative approach like this, the correct device for the control system will be created.

• Then there is the asynchronous implementation. I looked briefly at the documentation of pytango last week and I quite liked that they had implemented separate asynchronous functions using the _asynch at the end of the same synchronous function. And especially if the _asynch functions are using asyncio internally somehow because that would mean that we might be able to implement the same for EPICS. I'm wondering if perhaps in pyAML it would be a good idea to separate it in a similar way by having something like get_synch and get_asynch and then for get the user can either specify which mode to use or there is a default that the user can change? I quite liked when using pytango that I could just from the name of the command know what I was actually doing and didn't have to look in the documentation or inside the code. It would also give the user the possibility to switch from asynchronous to synchronous if needed for debugging since the mode isn't hardcoded into the bindings.

• Then TANGO also have the group functionality. If I have understood correctly, this is the behaviour @simoneliuzzo would like if you run a get on an array. I don't think EPICS have this but I think there might also be a way to implement something similar in the EPICS bindings. I think this is also not yet covered by the TANGO bindings?