Skip to content

STARBackend: reject aspirations whose pre-wetting or transport-air peak overfills the tip#1163

Merged
BioCam merged 1 commit into
PyLabRobot:mainfrom
BioCam:starbackend-aspirate-tip-capacity-check
Jul 15, 2026
Merged

STARBackend: reject aspirations whose pre-wetting or transport-air peak overfills the tip#1163
BioCam merged 1 commit into
PyLabRobot:mainfrom
BioCam:starbackend-aspirate-tip-capacity-check

Conversation

@BioCam

@BioCam BioCam commented Jul 13, 2026

Copy link
Copy Markdown
Collaborator

An aspiration whose transient tip fill reaches the tip's maximal volume is caught only by the firmware, with the opaque Maximum volume in tip reached error, and only after the channel has already travelled to the well. STARBackend.aspirate builds and sends the command with no client-side capacity check, so a caller gets a cryptic wire error at run time on hardware instead of a clear, actionable one.

It turns out that there are actually at least 2 different types of volume in tip overflow that can cause the same firmware error:

  1. volume + pre_wetting (pre-wet over-aspiration)
  2. volume + transport_air (the air gap drawn above the liquid after the tip leaves it).

The firmware rejects when either reaches the tip max -> interestingly, blow-out air sits at the top throughout and counts toward neither peak!

  • STARBackend.aspirate now checks each channel's two peak volumes against tip.maximal_volume before assembling the firmware command, and raises ValueError naming every peak on every channel that reaches it - so a caller sees all offending peaks at once, not just the first channel or the larger of a channel's two peaks.
  • Blow-out air volume is excluded, matching the firmware.
    The bound is exclusive (>): a peak equal to the tip's maximal volume is allowed.

Behaviour:
purely additive for in-capacity aspirations, which is the common case since callers keep within the tip - no wire change, no new default.
Over-capacity aspirations now raise a clear ValueError client-side instead of surfacing the firmware error after the channel has moved.
The guard is on the channel aspirate path only; aspirate96 is unchanged.

Tests: adds test_aspirate_rejects_over_tip_capacity (pre-wet and transport peaks each trip the guard), test_aspirate_capacity_ignores_blow_out (a large blow-out stays within capacity), and test_aspirate_capacity_boundary_is_exclusive (a peak exactly at the tip max is allowed, just above is rejected); the existing STAR command suite passes unchanged.

🤖 Generated with Claude Code

…peak overfills the tip

An over-capacity aspiration was caught only by the firmware ("Maximum volume in tip reached"), after the channel had already moved to the well. `aspirate` now checks each channel's two transient peaks (volume + pre_wetting, volume + transport_air; blow-out air counts toward neither) against `tip.maximal_volume` before assembling the command, and raises `ValueError` naming every peak on every channel that exceeds it. The bound is exclusive. Adds three tests.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@BioCam
BioCam force-pushed the starbackend-aspirate-tip-capacity-check branch from b25a0e5 to 4317be1 Compare July 13, 2026 14:16
@BioCam
BioCam merged commit d6f8cdc into PyLabRobot:main Jul 15, 2026
21 checks passed
@BioCam
BioCam deleted the starbackend-aspirate-tip-capacity-check branch July 15, 2026 21:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant