[TRCL-675][fix] SPARC GUI: don't prevent acquisition when ebeam-gun-exciter interlock is open

[pieleric]

As much as the light (aka laser) interlock can indicate a safety issue
(because it can mean the SPARC optical path is opened), an acquisition with
with the ebeam-gun-exciter interlock open would at worse mean that it
would acquire a dark measurement. More over, in many cases, the user
might not even want to be using the gun exciter. So no need to prevent
the acquisition in such case.

[Copilot]

Pull request overview

Adjusts SPARC acquisition UI gating so that an open e-beam gun exciter interlock does not block acquisitions (since it would at worst produce a dark measurement), while keeping existing interlock handling for systems that expose the light/laser interlock VA.

Changes:

• Introduces _interlock_blocks_acquisition to control whether an interlock state disables acquisition.
• Sets _interlock_blocks_acquisition = False when subscribing to ebeam_gun_exciter.interlockTriggered.
• Updates update_acquisition_time() to only disable acquisition when both the interlock is triggered and blocking is enabled.

[coderabbitai]

Caution

Review failed

The pull request is closed.

📝 Walkthrough

Walkthrough

The pull request modifies the SPARC acquisition controller to introduce fine-grained control over whether a triggered laser interlock blocks acquisition. A new private flag _interlock_blocks_acquisition is added (defaulting to True for backward compatibility). When an e-beam gun exciter has an interlockTriggered value attribute, this flag is set to False, allowing acquisition to proceed even if the interlock is triggered. The acquisition-time logic now checks both the interlock status and this flag before deciding whether to block acquisition. Minor clarifications are added to comments and behavior notes regarding blanker state preservation.

Sequence Diagram

sequenceDiagram
    participant User as User/Acquisition Request
    participant Acq as Acquisition Controller
    participant Interlock as Laser Interlock
    participant Blanker as Blanker
    participant Engine as Acquisition Engine

    User->>Acq: Start Acquisition
    Acq->>Interlock: Check interlockTriggered status
    Interlock-->>Acq: Interlock status
    
    alt Interlock Triggered and _interlock_blocks_acquisition = True
        Acq->>User: Block Acquisition (Warning)
    else Interlock Triggered and _interlock_blocks_acquisition = False
        Acq->>User: Warn about interlock
        Acq->>Blanker: Preserve/Restore blanker state
        Blanker-->>Acq: State preserved
        Acq->>Engine: Proceed with Acquisition
        Engine-->>Acq: Acquisition running
    else Interlock Not Triggered
        Acq->>Engine: Proceed with Acquisition
        Engine-->>Acq: Acquisition running
    end

Loading

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}