13 adding a field for catalog name for the control system and a catalog registration method new impl

[gupichon]

Summary

This PR adapts pyaml-cs-oa to the new PyAML API and adds catalog support to resolve EPICS and Tango devices from PyAML keys.

Main Changes

• add a catalog field to the OphydAsyncControlSystem configuration
• add static and dynamic catalogs for EPICS, plus a dynamic catalog for Tango
• add support for indexed access to vector signals through index, read_index, and write_index
• update signal wrappers to support reading a single array element and targeted read-modify-write updates
• tighten Pydantic models and apply related cleanup

Closes #13

Impact

This branch makes pyaml-cs-oa easier to integrate with PyAML's new resolution mechanisms while covering both scalar and vector signals, including partial access to array values.

Dependency

The related PyAML developments are available in branch 187-adding-catalogs-section-in-the-pyaml-configuration-file-new-implementation (PR #234).

[JeanLucPons]

There are 17 files modified + 36 files modified in pyaml !
Would it be possible to try to cut in several smaller updates with well defined tasks ?

However i did a small check on BESSY2 example reading an orbit:

sr = Accelerator.load("BESSY2Orbit.yaml")
SR = sr.live
orbit = SR.get_bpms("BPM").positions
print(orbit.get())

Here is what i get ?

[[3285.8356434 3285.8356434]
 [3285.8356434 3285.8356434]
 [3285.8356434 3285.8356434]
 [3285.8356434 3285.8356434]
 [3285.8356434 3285.8356434]
 [3285.8356434 3285.8356434]
...

Here is what i expect:

[[ 3.28583564e+03  0.00000000e+00]
 [ 2.19512518e+03  0.00000000e+00]
 [ 1.12020909e+04  0.00000000e+00]
 [ 1.75602034e+04  0.00000000e+00]
 [ 9.97247501e+03  0.00000000e+00]
 [-1.08780425e+03  0.00000000e+00]
 [-6.43913112e+02  0.00000000e+00]
...

[gupichon]

How do you simulate the live?
I would like to reproduce it locally.

[gupichon]

There are 17 files modified + 36 files modified in pyaml !
Would it be possible to try to cut in several smaller updates with well defined tasks ?

I realize it's a substantial PR, but since it’s a major architectural change, it’s difficult to break it down into smaller updates, they wouldn't make much sense in isolation as the pyaml branch (187-adding-catalogs-section-in-the-pyaml-configuration-file-new-implementation) requires the full implementation to be functional.

The main parts of this update are:

• Catalog integration for the ControlSystem class.
• Support for indexes in DeviceAccess implementations (this is the most significant change).
• Static and dynamic catalogs (mostly consisting of new files).

[JeanLucPons]

It is important to try to cut in smaller task otherwise it is too difficult even impossible to review.
For instance:

• New Device Access interface.
• Static catalog.
• Dynamic catalog.
• Indexed attribute.
  etc...

For examples, you have them in pyam/examples (including the soleil ones) with README that explain how to run them.

[JeanLucPons]

I made the BESSY2 example working.
However, the factoring of signals is not done and the reading of the same PV is done once for each BPM when reading using aggregator. There is now a significant job in scalar_aggretor to factor reading (and writing) of indexed value.
The indexed_signal.py is not needed.

[JeanLucPons]

Handle error here when the get_value() return a float and and index is present.

[gupichon]

It's done

[gupichon]

I made the BESSY2 example working. However, the factoring of signals is not done and the reading of the same PV is done once for each BPM when reading using aggregator. There is now a significant job in scalar_aggretor to factor reading (and writing) of indexed value. The indexed_signal.py is not needed.

Thank you very much for this contribution. I agree with you, but I would like to postpone these optimizations until we have fully functional catalogs, at least for the BPMs.

[JeanLucPons]

is hasattr() needed ?
hasattr is a slow call.

[gupichon]

You're right, it was completely unnecessary, except for the specific error message. I've removed it.

[JeanLucPons]

print in epcis.py: get_SP_RB() method.

ORBITCC:rdPos:<ophyd_async.core._signal.SignalR object at 0x7f6f440f1550>
ORBITCC:rdPos:<ophyd_async.core._signal.SignalR object at 0x7f6f440f1760>
pons:ORBITCC:rdPos:<ophyd_async.core._signal.SignalR object at 0x7f6f440f19a0>
pons:ORBITCC:rdPos:<ophyd_async.core._signal.SignalR object at 0x7f6f440f1bb0>

It seems that unattached signal are created ?!!!

[JeanLucPons]

I patched epics.py to avoid duplication of signal (epics only) for aggregators implementation.
Tango will need ophyd async 0.17 which should be published soon

[JeanLucPons]

I committed a first implementation of aggregator (it supports only read or readback for the moment) but it should be however compatible with the rest.

[JeanLucPons]

For me it is stilll unclear how Catalog works and why unattached signal are constructed as shown above ?