DeviceProxy integration

English | 日本語

Purpose and evidence

Earlier documentation describes DeviceProxy as an architectural abstraction intended to expose local and remote devices through a common application interface. That design is retained. However, the supplied pixet_ctrl.py does not define DeviceProxy; its constructors, registration functions, and transport implementation cannot be verified here.

Intended responsibilities

  • Local: MiniPixCtrl controls PIXet and the detector (verified).

  • Remote: a gRPC client delegates calls to a server (not verified from the supplied source).

  • Proxy: the application uses a uniform interface regardless of transport (design goal; implementation unverified).

Previously documented names such as register_device and DeviceProxy are retained as possible future or separate implementations, not runnable examples. When their source is available, document the actual import paths, constructor signatures, and synchronous/asynchronous behavior.

Interface compatibility

Candidate common methods include connect(), disconnect(), set_mode_all(), set_threshold(), acquire_frames(), acquire_integral(), stop(), and state(). Only the local MiniPixCtrl implementation is verified; remote compatibility is not yet established.

Transparent gRPC frame and API mapping

grpc_frame is a transparent transport frame for local control; it does not add detector-control operations. Remote control is therefore bounded by the operations implemented by the local controller on the server. Whether RPC/client names and signatures exactly match local methods requires the corresponding source code.

Do not interpret older RPC names as independent control features. If an operation is absent from local control, the transparent gRPC frame cannot supply it. Transport implementation and exposed RPC names cannot be verified from pixet_ctrl.py alone.