repics

EPICS Channel Access and pvAccess for Python, built on epics-rs. No libca, no libpvxs: the protocol stacks are the Rust crates, compiled into one extension module.

from repics import ca

ca.caput("SIM:ao", 2.5)
v = ca.caget("SIM:ai", form="ctrl")
print(v, v.units, v.severity, v.timestamp)

with ca.camonitor("SIM:cnt", print):
    ...

from repics.ca.asyncio import caget, camonitor

async def main():
    v = await caget(["SIM:ai", "SIM:long"])
    sub = await camonitor("SIM:cnt", print)

Every read returns an augmented value: a float/int/str/numpy.ndarray subclass carrying name, status, severity, timestamp, raw_stamp, and for form="ctrl" the units, precision, limits and enum strings.

Channel Access

caget, caput, camonitor, cainfo and connect take one PV name or a sequence and return a result of the same shape; a sequence is worked on concurrently, connect included, against one timeout. A failure raises CaError (CaTimeout, CaDisconnected); with throw=False it is returned instead as a CaNothing, whose ok is False and whose errorcode is the libca ECA_* status. cainfo returns a CAInfo.

• form picks the metadata class: "plain", "sts", "time" (default), "gr", "ctrl".
• datatype overrides the wire type: str, int, float, a numpy dtype, a DBR_* code, or DBR_CHAR_STR / DBR_CHAR_BYTES / DBR_CHAR_UNICODE to read a char waveform as text, DBR_ENUM_STR to read an enum as its label.
• count is 0 for the server's current element count, negative for the full native count, else a cap.
• camonitor(pv, callback, ...) returns a Subscription at once and connects in the background; connect_timeout reports a CaNothing with ECA_TIMEOUT if it passes, and the monitor keeps waiting. Callbacks run on one dispatcher thread (ca) or one task per event loop (ca.asyncio), in arrival order. With all_updates=False (default) updates that queued while the callback ran collapse into the latest and dropped_callbacks counts them. notify_disconnect=True delivers a CaNothing with ECA_DISCONN on disconnect; the monitor resumes on reconnection.
• repics.pv.PV is a pyepics-shaped object (get, put, add_callback, auto_monitor, char_value, units, ...) over one subscription; it raises on failure like the rest of the package.

A CA server hosts bare value channels — caget, caput and camonitor reach them, but there is no record, no RPC and no per-channel connect edge, so the only handler is put:

from repics.ca.server import SharedPV, Server

pv = SharedPV(initial=1.0)

@pv.put
def onput(pv, op):
    pv.post(op.value())      # accept: publish to monitors
    op.done()                # or op.done(error="...") to reject

Server.forever(providers=[{"X:val": pv}])

A SharedPV with no handler refuses every put. post() fans a new value out to monitors; values are plain scalars, strings, lists or 1-D numpy arrays. repics.ca.server.asyncio.SharedPV is the asyncio flavour, whose handler may be a coroutine. Handlers run on Python-owned threads (or the event loop), never on the network runtime.

pvAccess

The API follows p4p: Context, Value/Type, the nt wrappers, and SharedPV/StaticProvider/Server.

from repics.pva import Context
from repics.pva.nt import NTScalar, NTURI

with Context("pva") as ctxt:
    v = ctxt.get("SIM:ai")            # augmented, as for CA
    ctxt.put("SIM:ao", 2.5)
    r = ctxt.rpc("SIM:sum", NTURI([("a", "d"), ("b", "d")]).wrap("SIM:sum", kws={"a": 1, "b": 2}))
    with ctxt.monitor("SIM:cnt", print, notify_disconnect=True):
        ...

from repics.pva.server import SharedPV, Server

pv = SharedPV(nt=NTScalar("d"), initial=1.0)

@pv.put
def onput(pv, op):
    pv.post(op.value())
    op.done()

Server.forever(providers=[{"SIM:ao": pv}])

repics.pva.asyncio.Context and repics.pva.server.asyncio.SharedPV are the asyncio flavours; handlers there may be coroutines. Put and RPC handlers run on Python-owned threads (or the event loop), never on the network runtime, and a slow monitor consumer squashes updates in Rust instead of queueing Python objects. NTNDArray reads are zero-copy views of the received buffer.

Performance

The extension owns one tokio runtime with one worker thread (override with REPICS_WORKERS); every blocking call releases the GIL and waits for its future, every ca.asyncio call returns a future that is already done when the answer is in hand. Metadata is attached to a value lazily, list operations run in Rust as one concurrent batch, and all monitors of a front end feed one bounded queue that is drained in batches, so a callback costs one queue pop rather than one thread wake-up.

bench/bench_ca.py runs repics, pyepics and aioca in separate processes against the same softioc-rs. On a Xeon Gold 6542Y, pinned to four cores with the SMT siblings kept busy so the cores hold their clock (--pin 2,3,4,5 --hot; unpinned, schedutil parks the ping-ponging threads at 800 MHz and every library halves):

Monitor rows are under a 20 000-put storm from a separate writer process; every client received 20 099–20 100 of the 20 100 events on the 100-PV row.

bench/bench_pva.py does the same for pvAccess. Client rows run each library in its own process against one repics thread SharedPV server; server rows run each server flavour in its own process, measured by the p4p thread client. Same machine, same pinning:

pvAccess has no fire-and-forget put: every put is a completed round trip, and with the default get=True the current value is read first. repics and pvxs both do this as one two-phase put operation, the readback riding the put's own channel op, so the put rows are on par. The client monitor rows are under a storm from a separate repics writer running four threads of put(wait=True), about 14 000 puts/s, and every client received 19 857 or more of the 20 001 events, so the CPU column is the comparison. The server storm is one thread posting as fast as post() returns; the repics server delivers about twice as many posts as pvxs and spends about 13 us of CPU per post, delivery included, where pvxs spends about 6 us and, on one PV, squashes away more than half of them. Medians of the blocking repics client moved between 44 and 79 us on get across runs of the same command (thread placement inside the four cores); each table is one run.

Reference documentation: docs/index.md.

Building

pip install maturin
maturin develop            # into the active environment
pytest                     # needs `softioc-rs` on PATH or REPICS_SOFTIOC=<path>

softioc-rs is cargo install epics-ca-rs --bin softioc-rs.

Status

Channel Access client and server, blocking and asyncio. pvAccess client and server, blocking and asyncio; tested against p4p on both sides of the wire (pytest tests/pva needs p4p installed).