STARBackend: reject aspirations whose pre-wetting or transport-air peak overfills the tip#1163
Merged
BioCam merged 1 commit intoJul 15, 2026
Conversation
…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
force-pushed
the
starbackend-aspirate-tip-capacity-check
branch
from
July 13, 2026 14:16
b25a0e5 to
4317be1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 reachederror, and only after the channel has already travelled to the well.STARBackend.aspiratebuilds 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:
volume + pre_wetting(pre-wet over-aspiration)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.aspiratenow checks each channel's two peak volumes againsttip.maximal_volumebefore assembling the firmware command, and raisesValueErrornaming 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.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
ValueErrorclient-side instead of surfacing the firmware error after the channel has moved.The guard is on the channel
aspiratepath only;aspirate96is 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), andtest_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