Conversation
- NimbusDriver on HamiltonTCPClient with NIMBUS_ERROR_CODES; chatterbox, door, pip backend - TCPCommand as the shared wire command base; client/introspection aligned - Nimbus unit tests for error-code merge and interface resolution
…Nimbus errors & status exceptions
Move HOI error parsing (parse_hamilton_error_*) from messages into hoi_error. Pass HOI entries and per-entry exceptions into ChannelizedError for callers.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
One big thing this PR adds is liquid classes to the Nimbus, which hasn't existed in v0. I actually do not like liquid classes, because they are redundant with the parameters that you can already pass through standard python (whether directly through the capability or through backend params). A "liquid class" is just a 'set of parameters'. It's a relic from venus and anti pythonic imo, so long term I hope to get rid of them, in favor of just storing these 'sets of parameters' in Like you can just store it as follows liquid_class = NimbusPIPBackend.AspirationParams(
x=1,
y=2,
)this is essentially equivalent to a "liquid class" concept in lab automation, and removes the ambiguity (with separate an hlc parameter, you have three sources of information: explicitly passed, hlc, and backend default. not good) would that work for you? |
That works for me. Agree that could be a lot better and direct. Does this also include the volume correction curves that come along? Since some of those defaults can be useful as a starting point/reference. Want me to pull the liquid_class wiring from nimbus and prep for now? Mainly had it just for consistency with star (+vol corrections) |
|
that is an unsolved question :) open to suggestions. I think passing a function/calibration curve would be neat, or if no function/curve is passed just use the value directly, with the default being the current default hlc curve. I am saying it more from a "long term I want to get rid of liquid classes and figure out a better way" point of view, so would prefer to not add it in new code and rather focus on getting it out of old code if that makes sense. |
Totally makes sense. Maybe I can play around a bit and see if there's any solutions there. If I get any ideas I'll put them up on the forum |
# Conflicts: # pylabrobot/hamilton/liquid_handlers/nimbus/chatterbox.py # pylabrobot/hamilton/liquid_handlers/nimbus/driver.py # pylabrobot/hamilton/liquid_handlers/nimbus/nimbus.py # pylabrobot/hamilton/liquid_handlers/nimbus/pip_backend.py
Reverts the HLC pieces of 8c929c6: - Delete pylabrobot/hamilton/liquid_handlers/liquid_class_resolver.py and its tests - STAR PIP backend: restore the local _resolve_liquid_classes helper - Nimbus PIP backend: drop all HLC fields, imports, and resolution/volume-correction logic - Delete the HLC Nimbus pip_backend_tests.py (was added entirely by that commit) The underlying HamiltonLiquidClass and STAR calibration tables predated the PR and are kept. Nimbus is restored to its pre-HLC state (no liquid-class support) with the _on_setup signature updated to accept backend_params for the capability protocol. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Just to clarify, did you want me to pull hlc-related behavior out before merging this? Or just work on moving away from hlc behaviors as this gets built out alongside prep from this branch? |
|
Did that already actually, just forgot to push ... will do when I get home Do you want to keep working on this branch or should I merge it? I thought this just adds/refactors TCP and some nimbus stuff and then we rebase the prep branch onto v1b1 after merging this one. But either way works |
Ah, no prob. Merging is probably easiest. I already split off the prep into a separate branch from here anyway. But whatever is most convenient. |
- Delete docs/user_guide/.../nimbus_v1_aspirate_dispense.ipynb and prune its toctree entry. - Delete NimbusResolvedInterfaces dataclass, `_nimbus_resolved` / `_resolved_interfaces` instance state, and the `nimbus_interfaces` property — never read externally. Setup consumes the resolution dict locally. - Move build_parameters logic into NimbusCommand with an is_dataclass() guard, dropping 10 identical `return self._build_structured_parameters()` overrides and the helper. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2 participants
Mostly @rickwierenga's nimbus v1 port. Aligned with updated tcp_client, introspection, and enriched HoiError+Channelized error driver.