lemke_handClaude Sonnet 5
35c4e6bbd5
from eco import bernina
from eco import ipymagic
ipymagic.start(bernina)
In [1]: (1 / ...).plot()
(1 / bernina.mono.energy).plot()
<plot appears>
In [2]: cen = (left := ...) - (right := ...)
cen = (left := bernina.mono.energy) - (right := bernina.attenuator.transmission)
A bare `...` (the builtin Ellipsis literal -- not an IPython special form,
so this works anywhere IPython's own ast_transformers hook runs: terminal,
notebook/JupyterLab, qtconsole) is replaced, before execution, by the
picked component's real dotted path -- the expanded code is printed, then
run, so what actually executed stays visible and re-typeable. Multiple
`...` in one statement resolve left to right. A `...` used as a numpy
subscript (`arr[...]`) is left alone. Reuses eco.widgets.component_selector
for the actual tree/fold-state/Recent-list machinery -- nothing new there.
New eco.widgets.component_selector_qt.pick_component_modal(): the existing
ComponentSelectorQtWindow is built for embedding/async display (start()
hands off to IPython's own Qt pumping, or run() blocks the whole process
forever); an AST transform needs an actual answer before it can even
return control to IPython, so this drives the same window with its own
nested QEventLoop that quits the instant a pick (or a close) happens.
Also fixed a real bug found while testing this live: IPython's
ast_transformers calls `.visit(node)` on each registered entry (expects
an ast.NodeTransformer-shaped object) -- a bare function registered there
throws 'function' object has no attribute 'visit' once, and IPython
*silently* unregisters it with only a warning, no visible error. Verified
end-to-end against a real Qt window on a real X11 display (Xvfb) plus a
real IPython shell: spawned the picker, drove a real selection via
QTimer, confirmed the printed/executed code and result were both correct.
Deliberately namespace-tree-only for now -- picking from prior *commands*
(eco.logs' kernel history) is a planned second mode, not built here.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
eco — Experiment Control
___ _______
/ -_) __/ _ \
Experiment Control \__/\__/\___/
eco is a Python-based control environment for experiments, developed and used at SwissFEL, PSI. It is used both as:
- a library of experimental devices for higher-level Python applications or GUIs, and
- an interactive command-line interface, e.g. from an IPython/Jupyter shell or notebook.
eco follows an object-oriented approach: every device is represented as a Python object with a small, predictable interface, so devices can be freely combined in generic control/acquisition routines and analysed with the scientific Python ecosystem. For a general introduction to object-oriented Python, see e.g. this short introduction.
Documentation
The full documentation — installation, core concepts, and worked examples (listening monitors, archiver data and strip charts, pipeline offload, motor configuration) — lives in docs/ and is built with Sphinx, configured to build on Read the Docs via .readthedocs.yaml.
Build it locally:
pip install -r docs/requirements.txt
sphinx-build -b html docs docs/_build/html
Installation
conda install -c paulscherrerinstitute eco
or, for development, in editable mode from a checkout:
git clone https://github.com/paulscherrerinstitute/eco.git
cd eco
pip install -e .
See Installation for beamline-specific setup (the
eco launcher, .ecorc defaults) and the full dependency picture.
Creating a new device
New devices are implemented as a subclass of Assembly, which provides
naming, aliasing, and shell representation:
from eco.elements.assembly import Assembly
class MyDevice(Assembly):
def __init__(self, name=None):
super().__init__(name=name)
self._append(MySubObject, name="my_sub_object", is_setting=True, is_status=True)
is_setting=True marks the child as a setting of the assembly (shown by
.settings() and captured when settings are saved); is_status=True marks it
as contributing to the assembly's .status(). See
Representing real devices — the Assembly in the full docs
for the rest of the model (Adjustable, Detector, Namespace) and a
from-scratch, runnable example of each.