Mix: add optional surface_following_distance#1085
Merged
Merged
Conversation
BioCam
force-pushed
the
mix-surface-following-distance
branch
from
9969597 to
5aebe16
Compare
rickwierenga
approved these changes
Jun 10, 2026
Comment on lines
+83
to
+84
| surface_following_distance: The distance (mm) the tip follows the liquid surface each cycle on | ||
| backends that support it (e.g. Hamilton STAR); others ignore it. |
Member
There was a problem hiding this comment.
other backends should not just ignore things when they dont support it, they should raise errors when the value is not None
should we clarify the direction as well? probably negative for going down?
Collaborator
Author
There was a problem hiding this comment.
I agree on the raising but that would be part of each "wire into backend x PR"
I don't think the value should be negative because the direction seems to be always dictated by the atomic command:
Aspirate has to follow downwards
Dispense has to follow upwards
Because that is "following the surface" by definition
And mixing is defined as repeated aspirate-dispense cycles
Add an optional surface_following_distance (mm) to the Mix dataclass. It is an essential part of a good in-place mix on liquid handlers whose firmware drives Z in parallel with the piston (e.g. the Hamilton STAR), keeping the tip near the surface as the level changes. Backends without that capability ignore it; the default None is no surface following. Optional with a default, so existing Mix construction and serialization are unchanged; no backend behaviour changes here. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
BioCam
force-pushed
the
mix-surface-following-distance
branch
from
5aebe16 to
c2a3051
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
2 participants
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.
Adds an optional
surface_following_distance(mm) toMix. On liquid handlers whose firmware drives Z in parallel with the piston during a mix (e.g. the Hamilton STAR), following the surface as the level changes is an essential part of a good in-place mix. Backends without that capability ignore the field; the defaultNonemeans no surface following.This is the same shape as other capability-dependent parameters in PyLabRobot - for example a plate reader exposing a reading mode (orbital shaking, a given wavelength range) that some models support and others don't. The protocol states the intent once; backends that can honour it do, and those that can't ignore it, rather than the protocol branching per device.
Backward compatible: optional with a default, so existing
Mix(volume, repetitions, flow_rate)construction and serialization are unchanged. No backend behaviour changes in this PR - it just adds the parameter to the shared vocabulary so supporting backends can consume it.