feat(api): add option to ignore different tip presence states #14980
Conversation
caila-marashaj
changed the title
There was a problem hiding this comment.
This makes sense and provides a solution path for problems we were running into with partial tip configurations when going beyond one column/row on a given side. Next steps on that particular front would be to identify the sensors associated with a given map, which may be abstract-able based on the nozzle maps primary nozzle and the nozzle ids covered within a given map. This is especially finite now given what we are learning about maximum map sizes available to us based on hardware limitations, so we may be able to add this to definitions somewhere or as an available parameter within the NozzleMap class whenever a given map is configured.
| pipette, and the other is allowed to be different. | ||
| """ | ||
| if ht_operational_sensor: | ||
| target_sensor_id = sensor_id_for_instrument(ht_operational_sensor) |
There was a problem hiding this comment.
In the case that an OT2 has somehow reached this stage, can it be expected that any sensors it has will have properly mapped IDs (primary/secondary), or do we assume an OT2 in this state would deflect to the raise case?
There was a problem hiding this comment.
This should not happen, the OT2 does not have any tip sensing capabilities and does not use the tip presence manager.
|
@caila-marashaj with the approval I am merging so I may build |
* edge: (194 commits) fix(app): clone run with RTPs from HistoricalProtocolRun (#14959) fix(api): Filter out `air_gap()` calls as higher-order commands (#14985) fix(app): fix infinitely re-rendering/never rendering firmware success toasts (#14981) feat(api): add option to ignore different tip presence states (#14980) feat(opentrons-ai-client) add input textbox to container (#14968) fix(app): add robotSerialNumber to proceedToRun event (#14976) fix(api): remove homing patch fix for right mount when a 96-channel is attached (#14975) feat(api-client,app,react-api-client): upload splash logo from desktop app (#14941) fix(robot-server): notify /runs when a non-current run is deleted (#14974) feature(api, robot-server): Allow fixit commands to recover from an error (#14908) feat(hardware-testing): enable multi sensor processing in liquid probe (#14883) fix(app): prevent "run again" banner from rendering after navigating away from the current run (#14973) refactor(components): refactor roundtab stories (#14956) refactor(protocol-designer): assign module slot in createFileWizard instead of modal (#14951) fix(app, api-client): fix choose protocol slideout issue (#14949) refactor(protocol-designer): tip position modal max values round down (#14972) feat(app): add tiprack selection step to quick transfer flow (#14950) ci(shared-data): install dependencies in workflow (#14958) fix(components): fix icon stories (#14969) feat(opentrons-ai-client): introduce react-markdown to chat display component (#14965) ...
## Overview This code adds an argument called `ht_operational_sensor` to `get_tip_presence_status`, that when used tells the api to only return the tip presence state of the instrument probe type specified. This allows calibration and partial tip flows to execute and check against their expected tip status without failing. ## TODO A follow-up pr will go up using this parameter for the `get_tip_presence` call in the calibration flow. ## Review Requests I'll most likely address any non-blocking change requests in a follow-up pr so we can cut the internal release as fast as possible, but let me know if: - `ht_operational_sensor` makes sense or if we can think of a better name - we should otherwise go about anything differently here.
Overview
This code adds an argument called
ht_operational_sensortoget_tip_presence_status, that when used tells the api to only return the tip presence state of the instrument probe type specified. This allows calibration and partial tip flows to execute and check against their expected tip status without failing.TODO
A follow-up pr will go up using this parameter for the
get_tip_presencecall in the calibration flow.Review Requests
I'll most likely address any non-blocking change requests in a follow-up pr so we can cut the internal release as fast as possible, but let me know if:
ht_operational_sensormakes sense or if we can think of a better name