Single EPICS PVs¶
In this tutorial we will read, write, and monitor an EPICS PV in ophyd.
Set up for tutorial¶
Before you begin, install ophyd
, pyepics
, bluesky
, and caproto
,
following the Installation Tutorial.
We’ll start this simulated hardware that implements a random walk. It has
just two PVs. One is a tunable parameter, random_walk:dt
, the time between
steps. The other is random_walk:x
, the current position of the random
walker.
python -m caproto.ioc_examples.random_walk --list-pvs
Start your favorite interactive Python environment, such as ipython
or
jupyter lab
.
Connect to a PV from Ophyd¶
Let’s connect to the PV random_walk:dt
from Ophyd. We need two pieces of
information:
The PV name,
random_walk:dt
.A human-friendly name. This name is used to label the readings and will be used in any downstream data analysis or file-writing code. We might choose, for example,
time_delta
.
In [1]: from ophyd.signal import EpicsSignal
In [2]: time_delta = EpicsSignal("random_walk:dt", name="time_delta")
Note
It is conventional to name the Python variable on the left the same as the
value of name
, but not required. That is, this is conventional…
a = EpicsSignal("...", name="a")
…but all of these are also allowed.
a = EpicsSignal("...", name="b") # local variable different from name
a = EpicsSignal("...", name="some name with spaces in it")
a = b = EpicsSignal("...", name="b") # two local variables
Next let’s connect to random_walk:x
. It happens that this PV is not
writable—any writes would be rejected by EPICS—so we should use a read-only
EpicsSignal, ~ophyd.signal.EPICSSignalRO, to represent it in in ophyd. In
EPICS, you just have to “know” this about your hardware. Fortunately if, in our
ignorance, we used writable ~ophyd.signal.EpicsSignal instead, we could
still use it to read the PV. It would just have a vestigial set()
method
that wouldn’t work.
In [3]: from ophyd.signal import EpicsSignalRO
In [4]: x = EpicsSignalRO("random_walk:x", name="x")
Use it with the Bluesky RunEngine¶
The signals can be used by the Bluesky RunEngine. Let’s configure a RunEngine to print a table.
In [5]: from bluesky import RunEngine
In [6]: from bluesky.callbacks import LiveTable
In [7]: RE = RunEngine()
In [8]: token = RE.subscribe(LiveTable(["time_delta", "x"]))
Because time_delta
is writable, it can be scanned like a “motor”. It can
also be read like a “detector”. (In Bluesky, all things that are “motors” are
also “detectors”.)
In [9]: from bluesky.plans import count, list_scan
In [10]: RE(count([time_delta])) # Use as a "detector".
+-----------+------------+------------+
| seq_num | time | time_delta |
+-----------+------------+------------+
| 1 | 12:36:06.2 | 3 |
+-----------+------------+------------+
generator count ['e330d3f7'] (scan num: 1)
Out[10]: ('e330d3f7-6a99-4a17-9de6-9e95d972902c',)
In [11]: RE(list_scan([], time_delta, [0.1, 0.3, 1, 3])) # Use as "motor".
+-----------+------------+------------+
| seq_num | time | time_delta |
+-----------+------------+------------+
| 1 | 12:36:06.3 | 0 |
| 2 | 12:36:06.3 | 0 |
| 3 | 12:36:06.3 | 1 |
| 4 | 12:36:06.3 | 3 |
+-----------+------------+------------+
generator list_scan ['4afa3357'] (scan num: 2)
Out[11]: ('4afa3357-c6dc-43f5-8ea7-bf8f0dd469de',)
For the following example, set time_delta
to 1
.
In [12]: from bluesky.plan_stubs import mv
In [13]: RE(mv(time_delta, 1))
Out[13]: ()
We know that x
represents a time-dependent variable. We can “poll” it at
regular intervals
In [14]: RE(count([x], num=5, delay=0.5)) # Read every 0.5 seconds.
+-----------+------------+------------+------------+
| seq_num | time | time_delta | x |
+-----------+------------+------------+------------+
| 1 | 12:36:06.4 | | -0 |
| 2 | 12:36:06.9 | | -0 |
| 3 | 12:36:07.4 | | -0 |
| 4 | 12:36:07.9 | | -0 |
| 5 | 12:36:08.4 | | -1 |
+-----------+------------+------------+------------+
generator count ['e60beef5'] (scan num: 3)
Out[14]: ('e60beef5-c4a5-4a92-b0d4-e903017196d5',)
but this required us to choose an update frequency (0.5
). It’s often better
to rely on the control system to tell us when a new value is available. In
this example, we accumulate updates for x
whenever it changes.
In [15]: from bluesky.plan_stubs import monitor, unmonitor, open_run, close_run, sleep
In [16]: def monitor_x_for(duration, md=None):
....: yield from open_run(md) # optional metadata
....: yield from monitor(x, name="x_monitor")
....: yield from sleep(duration) # Wait for readings to accumulate.
....: yield from unmonitor(x)
....: yield from close_run()
....:
In [17]: RE.unsubscribe(token) # Remove the old table.
In [18]: RE(monitor_x_for(3), LiveTable(["x"], stream_name="x_monitor"))
+-----------+------------+------------+
| seq_num | time | x |
+-----------+------------+------------+
| 1 | 12:36:09.1 | -1 |
| 2 | 12:36:09.1 | -1 |
| 3 | 12:36:09.4 | -1 |
| 4 | 12:36:10.4 | -2 |
| 5 | 12:36:11.4 | -2 |
+-----------+------------+------------+
generator monitor_x_for ['bb618838'] (scan num: 4)
Out[18]: ('bb618838-ebab-42dd-ba77-fdacb4a3e210',)
If you are a scientist aiming to use Ophyd with the Bluesky Run Engine, you may stop at this point or read on to learn more about how the Run Engine interacts with these signals. If you are a controls engineer, the details that follow are likely important to you.
Use it directly¶
Note
These methods should not be called inside a Bluesky plan. See [TODO link to explanation.]
Read¶
The signal can be read. It return a dictionary with one item. The key is the
human-friendly name
we specified. The value is another dictionary,
containing the value
and the timestamp
of the reading from the control
system (in this case, EPICS).
In [19]: time_delta.read()
Out[19]: {'time_delta': {'value': 1.0, 'timestamp': 1662640566.472364}}
Describe¶
Additional metadata is available. This always includes the data type, shape, and source (e.g. PV). It may also include units and other metadata.
In [20]: time_delta.describe()
Out[20]:
{'time_delta': {'source': 'PV:random_walk:dt',
'dtype': 'number',
'shape': [],
'units': '',
'lower_ctrl_limit': 0.0,
'upper_ctrl_limit': 0.0,
'precision': 0}}
Set¶
This signal is writable, so it can also be set.
In [21]: time_delta.set(10).wait() # Set it to 10 and wait for it to get there.
Sometimes hardware gets stuck or does not do what it is told, and so it is good practice to put a timeout on how long you are willing to wait until deciding that there is an error that needs to be handled somehow.
In [22]: time_delta.set(10).wait(timeout=1) # Set it to 10 and wait up to 1 second.
If the signal fails to arrive, a TimeoutError
will be raised.
Note that set(...)
starts the motion but does not wait for it to
complete. It is a fast, “non-blocking” operation. This enables you to run
code between starting a motion and completing it.
In [23]: status = time_delta.set(5)
In [24]: print("Moving to 5...")
Moving to 5...
In [25]: status.wait(timeout=1)
In [26]: print("Moved to 5.")
Moved to 5.
Note
To move more than one signal in parallel, use the ophyd.status.wait()
function.
from ophyd.status import wait
# Given signals a and b, set both in motion.
status1 = a.set(1)
status2 = b.set(1)
# Wait for both to complete.
wait(status1, status2, timeout=1)
For more on what you can do with status
, see […].
Subscribe¶
What’s the best way to read a signal that changes over time, like our x
signal?
First, set time_delta
to a reasonable value like 1
. This controls the
update rate of x
in our random walk simulation.
In [27]: time_delta.set(1).wait()
We could poll the signal in a loop and collect N readings spaced T seconds apart.
# Don't do this.
N = 5
T = 0.5
readings = []
for _ in range(N):
time.sleep(T)
reading = x.read()
readings.append(reading)
There are two problems with this counterexample.
We might not know how often we need to check for updates.
We often want to watch multiple signals with different update rates, and this pattern would quickly become messy.
Alternatively, we can use subscription.
In [28]: from collections import deque
In [29]: def accumulate(value, old_value, timestamp, **kwargs):
....: readings.append({"x": {"value": value, "timestamp": timestamp}})
....: readings = deque(maxlen=5)
....: x.subscribe(accumulate)
....:
Out[29]: 1
When the control system has a new reading
for us, it calls
readings.append(reading)
from a background thread. If we do other work or
sleep for awhile and then check back on readings
we’ll see that it has some
items in it.
In [30]: readings
Out[30]:
deque([{'x': {'value': -1.5461537788257538, 'timestamp': 1662640571.412302}},
{'x': {'value': -2.3133222534984723, 'timestamp': 1662640572.413357}},
{'x': {'value': -2.621474342758977, 'timestamp': 1662640573.41464}},
{'x': {'value': -2.557979320469065, 'timestamp': 1662640574.416623}}],
maxlen=5)
It will keep the last 5
. We used a deque
instead of a
plain list here because a list would grow without bound and, if left to
run long enough, consume all available memory, crashing the program.