Skip to content

Acquire_RBV and Capture_RBV don't reflect actual hardware/software state #5

Description

@ericonr

After a write to the Capture PV, be it 1 or 0, Capture_RBV changes its value immediately, and doesn't reflect that the backend is still setting itself up to receive frames (when the written value is 1) or tearing down the threads used to receive frames (when the written value is 0). This can mainly lead to problems when one tries to start a new acquisition too soon after stopping the previous one (even if they wait for Capture_RBV to return to 0).

After a write to the Acquire PV, be it 1 or 0, Acquire_RBV changes its value immediately, and doesn't reflect that the commands to tell the detector to either start or stop an acquisition haven't been sent yet. This can lead to problems when using the external trigger mode, since Acquire_RBV will indicate that the detector is ready to receive a trigger, but might miss that trigger because it hadn't actually finished setup.

These issues are fixed in the lnls-production branch (v2) in aff6d73, ab8acf9, a9a36fa and 6fc4a87; they caused a regression which was fixed in 3265037.

These fixes also require patches to the pimega-api (for improved error handling that can deal with the new situations) and backend (in order to improve the interaction between it and the IOC, intending to formalize the control flow between them and fix some error conditions).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    master-branchIssue affects master branchpitec-v3Issue affects pitec-v3 branch

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions