STARBackend: resolve installed X-arms into XArmInformation at setup#1167
Open
BioCam wants to merge 2 commits into
Open
STARBackend: resolve installed X-arms into XArmInformation at setup#1167BioCam wants to merge 2 commits into
STARBackend: resolve installed X-arms into XArmInformation at setup#1167BioCam wants to merge 2 commits into
Conversation
BioCam
force-pushed
the
pr1-xarm-information
branch
2 times, most recently
from
July 20, 2026 14:11
db798f9 to
e960cb1
Compare
Fuse the STAR's X-arm configuration information (arm widths, drive travel ranges, working envelopes) into one record resolved once at setup, mirroring iSWAPInformation and Head96Information. Adds XArmInformation / SingleXArmInformation, the x_arm_information property, _build_x_arm_information, and DriveConfiguration.is_present; the drive-range and working-envelope request methods now parse into typed dicts instead of returning the raw firmware string. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
BioCam
force-pushed
the
pr1-xarm-information
branch
from
July 20, 2026 14:52
e960cb1 to
03630d7
Compare
Comment on lines
+1252
to
+1255
| @property | ||
| def is_present(self) -> bool: | ||
| """Whether this X-drive carries any module, i.e. the X-arm exists.""" | ||
| return any(vars(self).values()) |
Comment on lines
+1380
to
+1399
| @dataclass(frozen=True, eq=False) | ||
| class XArmInformation: | ||
| """The machine's X-arm layout, resolved once at setup. | ||
|
|
||
| The top-level per-machine X-arm record: one `SingleXArmInformation` per installed | ||
| arm, keyed by the rail it sits on. A STAR carries an arm on the `left` rail; an | ||
| optional second arm on the `right` rail makes `right` non-None (so `number_x_arms` | ||
| is 1 or 2). Built by `STARBackend._build_x_arm_information` from the machine | ||
| configuration and the X-drive queries, and immutable thereafter. This is the | ||
| reference frame the arm-mounted modules - pipetting channels, the 96-head, the | ||
| iSWAP - are positioned against. | ||
| """ | ||
|
|
||
| left: Optional["SingleXArmInformation"] = None | ||
| right: Optional["SingleXArmInformation"] = None | ||
|
|
||
| @property | ||
| def number_x_arms(self) -> int: | ||
| """Number of installed X-arms.""" | ||
| return sum(arm is not None for arm in (self.left, self.right)) |
Member
There was a problem hiding this comment.
why does this need a class, why dont we just store these on the star backend?
Collaborator
Author
There was a problem hiding this comment.
The same reasons as Head96Information, PipChannelInformation and ISWAPInformation:
Organisation, rather than dispersion as individual class attributes.
Retrieval of associated values as one unit.
Easier simulation declaration and testing.
Simplified use in the upcoming xarm upgrades (xrange enforcement and iSWAP range).
Member
There was a problem hiding this comment.
oh yes we certainly need a class for what is currently called SingleXArmInformation but it seems we can just store what is currently XArmInformation on the star backend directly in left_x_arm and right
Collaborator
Author
There was a problem hiding this comment.
You mean have two separate class attributes + separate helper property to declare the number available?
Remove `XArmInformation`/`SingleXArmInformation` and resolve each X-drive's geometry (width, travel range, workspace range) directly onto its `DriveConfiguration` inside `request_extended_configuration`, alongside the module bits. `model` and `reference_point` become properties derived from `width`. `right_x_drive` is now `Optional`, `None` when no second arm is installed, so arm presence is a plain `is None` check. The separate `_resolve_x_arm_geometry` setup step is gone. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
The STAR reports its X-arm layout at setup across three replies - arm widths, drive travel ranges, and working envelopes - but nothing fuses them into a single record. The two underlying request methods returned the raw firmware strings, had zero in-tree callers, and left any consumer to re-parse and cross-reference all three sources itself.
This adds the source-of-truth record the X-arm tracking work builds on: one
SingleXArmInformationper installed arm, resolved once at setup, mirroringiSWAPInformation(#1055) andHead96Information(#1084).Resolved parameters
number_x_arms— count of installed arms:1(left rail only, the common STAR) or2(both rails).position— which rail the arm sits on:leftorright.width— arm width in mm, from the machine configuration (e.g.370.0dual-rail;≤300single-rail).model— variant derived fromwidth:hamilton_legacy_star_dual_rail_arm(width > 300) orhamilton_legacy_star_single_right_rail_arm(width ≤ 300).reference_point— where the tracked X refers to, derived fromwidth:center(dual-rail) orright(single-right-rail).x_range— drive travel(min, max)in mm (e.g. dual-rail left(95.0, 1340.4)).workspace_range— reachable X workspace(min, max)in mm (e.g.(-323.2, 1517.4)).Changes
XArmInformation(left/right,number_x_arms) andSingleXArmInformation(the fields above), bothfrozen(eq=False)like the other Information records._build_x_arm_informationfuses the arm widths, drive travel ranges, and working envelopes into the record at setup, exposed via thex_arm_informationproperty (raises before setup)._x_arm_model_and_reference.request_maximal_ranges_of_x_drivesandrequest_working_envelopes_per_arm(renamed fromrequest_present_wrap_size_of_installed_arms) now parse their replies into typed(min, max)dicts instead of returning the raw string.DriveConfiguration.is_presentreports whether a drive carries any module, so an absent right arm resolves toNone.STARChatterboxBackendemits the matching replies and builds the record at setup like the hardware backend.Behaviour: additive - the two request methods had no in-tree callers, so the rename and return-shape change affect nothing downstream, and
x_arm_informationis new surface. The single-rail left-drive minimum is fabricated only in the chatterbox (named_DUAL_RAIL_LEFT_X_MIN, 95.0); hardware reads its own value from the drive-range query, and no single-rail dump exists yet to test that path (#822).Tests: adds
TestXArmInformation(the fused record on the default single-left-arm sim, plus_x_arm_model_and_referenceby width) andTestXArmRangeQueries(the range and working-envelope parsers against replies observed on real machines); ruff format, ruff check --select I,F, and mypy are clean, and the STAR suite passes.🤖 Generated with Claude Code