Update STARBackend Tip Presence Check Commands

[BioCam]

Problem

Currently STARBackend.request_tip_presence() and STARBackend.request_tip_presence_in_core_96_head() appear to do the same task, just for single channels and the 96-head, respectively.
This is incorrect.

• STARBackend.request_tip_presence() is a MEASUREMENT command, i.e. it measures the sleeve sensors on all channels to return the true state of tip presence on channels.
• STARBackend.request_tip_presence_in_core_96_head() is a MEM-READ command, i.e. it reads the STAR(let)'s internal memory which keeps a record of all tip_pickup96 and tip_drop96 commands that have occurred.
  Importantly this means no measurement is being made. Combined with the absence of a tip pickup/drop sensor during these operations, no error can be raised by the firmware if tip_pickup96 is performed on an empty tiprack.

(Also STARBackend.request_tip_presence_in_core_96_head() still returns the firmware parsed dictionary rather than the actual 0/1 state of tip presence)

This PR

In alignment with the Standardised PLR Command Prefix Proposal, I have renamed these STARBackend methods to represent their correct command type:

• STARBackend.request_tip_presence() -> STARBackend.channels_measure_tip_presence() -> List[in]
• STARBackend.request_tip_presence_in_core_96_head() -> STARBackend.head96_request_tip_presence() -> int

-> Please let me know whether you think STARBackend.channels_sense_tip_presence() -> List[int] is a preferred name for this MEASUREMENT command. I think either could work well and have no preference :)

Current version have been given deprecation warnings with a 5 month update period (>2026-06) before deletion of the old methods.

[Copilot]

Pull request overview

This PR deprecates and replaces tip presence detection methods in the STARBackend with more clearly named alternatives. The changes align method naming with a consistent convention (using prefixes like channels_ and head96_) and improve documentation clarity.

Changes:

• Deprecated request_tip_presence in favor of channels_measure_tip_presence with improved documentation
• Deprecated request_tip_presence_in_core_96_head in favor of head96_request_tip_presence with clearer documentation about the command's behavior
• Added deprecation warnings with removal dates set for June 2026

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[rickwierenga]

Why measure for pip , request for 96?

Since it's a memory read, let's use request

[BioCam]

• STARBackend.request_tip_presence() -> STARBackend.channels_measure_tip_presence() -> List[in]
• STARBackend.request_tip_presence_in_core_96_head() -> STARBackend.head96_request_tip_presence() -> int

I agree, that's what I did :)

"measure/sense for pip" & "request for 96"

[rickwierenga]

this is an interesting question, I did not realize the pip tip presence is a measurement.

I think on the one hand it makes sense to look at the machine fundamentals, on the other I can see the argument of having consistent nomenclature between the pip and 96 head (naming it channels_request_tip_presence)

although in the future if there is ever a scenario where it matters whether this is a measurement or memread, misnaming it will be confusing

I think of measure and sense, sense is the better option here because measurement might confuse with analytical machines. the worry is that we drift away too far from the naming proposal (is "sense" going to be a standard word?)

[BioCam]

While I see the point to naming consistency between pip and 96-head, these are actually two different actions and therefore I am convinced that the name should reflect the command type.

I found this super confusing because pip's tip presence check is always correct, because it is a measurement.
Even if the resource model has a problem it will deliver correct results. 96 head tip presence check is different and I found the STAR firmware to be incorrect quite frequently.

I would like to work on a real head96_sense_tip_presence() in the future and have a couple of ideas for it.
But that requires command type-accurate naming :)

[BioCam]

I think of measure and sense, sense is the better option here because measurement might confuse with analytical machines. the worry is that we drift away too far from the naming proposal (is "sense" going to be a standard word?)

Awesome, then I will rename to:

STARBackend.request_tip_presence() -> STARBackend.channels_sense_tip_presence() -> List[in]

I think "sense" is an intuitive word for measurements 🤔
I agree that MEASUREMENT commands shouldn't be as flexible as ACTION commands, but we can update the scope of prefixes for MEASUREMENT commands and still keep it limited:

Command Types
├── 1. Physical Machine Commands
│   ├── 1.1 ACTION      → move_, aspirate_, dispense_, pickup_, shake_
│   ├── 1.2 MEASUREMENT → read_, capture_, measure_, sense_
│   ├── 1.3 MEM-READ    → request_
│   └── 1.4 MEM-WRITE   → set_
└── 2. RMS / Resource Modeling Commands
    ├── 2.1 QUERY       → get_
    └── 2.2 UPDATE      → update_, assign_, unassign_

[rickwierenga]

makes sense

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.