fix(app): only display Flex robots for Flex protocol slideouts #14236
Conversation
This file contains 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
Co-authored-by: Ed Cormany <[email protected]>
…leAreasInProtocol (#14205) adds the moveToAddressableAreaForDropTip command to the getAddressableAreasInProtocol helper that provides a list of addressable area names referenced in a protocol's commands
This PR is a general second-pass of the drop tip wizard. There's a good bit refactoring, but in terms of functional changes: - The wizard doesn't render BeforeBeginning until the maintenance run has been successfully created - renders a spinner now. This prevents some bugs and is better UX. - Exiting the drop tip wizard now renders a spinner and exits properly. - The home command occurs in a predictable spot - no more instantly homing after completing blowout. - Use moveToAddressableArea instead of moveRelative to prevent unexpected pipette movements (you CANNOT move to a slot with a moveable trash or waste chute loaded -- this is a known issue and currently being fixed). - Fixes an issue where an unreachable step could be hit. - More error messaging! NOTE: you CANNOT move to a slot with a moveable trash or waste chute loaded -- this is a known issue and currently being addressed separately. Closes RQA-2083, RQA-2094, RQA-2066, RQA-2068, RQA-2024
Implement the tcp socket emulator by creating a separate stream that is piped through to the usb connection via its downward interface rather than using the same stream for both the port and the socket or pipelining the two streams together. This implementation allows the lifecycles of the USB port connection, which we want to be the same as the physical robot connection; and the tcp socket emulators, which we want to be more like tcp sockets; to be separate, which really increases reliability because we don't have the port going up and down all the time anymore. This reduces spurious disconnects. It will also allow us to add socket activity timeouts to help with the windows dropping data problem, though we can't really do that until the http requests that cause synchronous actions that we make get keep alive streaming responses.
Since on the 96, that moves motors while someone is holding it in their hands.
Closes RQA-2106 * refactor(app): remove drop tip banner for ot2 after protocol runs * refactor(app): add more error handling to drop tip wizard moveToAddressableArea * style(app): add sensible text when drop tip launches * fix(app): cancelling a run should not unrender drop tip banner * fix(app): include fixed trash as a moveToAddressableArea zoffset exception * fix(app): do not show drop tip/blowout confirmation until moveToAddressableArea has completed * refactor(app): add even more error handling - this time to the droptip and blowout commands
* fix(app): fix estop modal button state issue
…14218) * fix(app): remove dismissCurrentRun when run is cancelled on ODD Mirror the desktop app. Dismissing the run context on run cancel means drop tip will not work.
This seems like a logic problem with how we track tip state, but removing this check (which is really a nebulous "might be using it wrong" check) we fix some incorrect errors in the drop tip wizard.
* fix(app): allow users to use the same name after clearing all data
ensures that all OT2 protocols auto drop tips regardless of version, and that only Flex protocols 2.15 and prior auto drop tips
We have a system to center pipettes appropriately on the wells of labware that span multiple "traditional" wells. For instance, in a 12-well reservoir, we need to move the center of an eight channel pipette to the center of a given well of the 12-well reservoir. However, that code was moving the center of _any_ pipette to the center of a 12-well reservoir, inclunding the center of the 96-channel, which is definitely not right. Instead, what we want to do is move the center of the "active" column (the column that contains the active nozzle, which is the nozzle that is moved when a caller specifies a NOZZLE critical point) to the center of the well. And we only want to do this on labware that have roughly one well per column. The fix is in two parts. First, a Y_CENTER critical point needs to exist. This critical point is aligned in the X direction with the active nozzle of the pipette, but is halfway between the Y positions of the backmost and frontmost nozzles in the column containing the active nozzle of the currently active nozzlemap - so, on an eight channel with a full map it would be the same as XY_CENTER; on a single, an eight channel with a single nozzle map, or a 96 with a single nozzle map, it will be the same as NOZZLE (and the same as XY_CENTER); and on an eight channel or 96 with a partial-column map it will be halfway up the partial. On a 96 with a rectangular map (i.e. either full or quadrant) it will be halfway between the back left and front left nozzles. Next, we have to actually use that critical point. The engine would check for a labware to have the centerMultiChannelOnWells quirk and emit XY_CENTER for both source and destination if it was found; we now also consider how many wells the labware has if it has centerMultiChannelOnWells and (somewhat hackily, sadly) emit - Y_CENTER, if the labware has the centerMultiChannelOnWells quirk and 1 < wells < 96 - XY_CENTER, if the labware has the centerMultiChannelOnWells quirk and wells == 1, wells >= 96 This should probably change eventually into a new quirk called like centerActiveColumnOnWells or something but that's for a different time. Closes RQA-2118
* fix(app): add dimsissing current run back * fix(app): fix robot stuck in cancelled state * test fixes
A previous PR (12a630b / #13989 ) changed the python protocol api in version 2.16 to allow commanding 0ul liquid handling commands like aspirate, mix, and dispense. This is useful in programmatic protocols that read out volumes to handle; they can now handle 0 volume properly. In 2.15 and previous, specifying 0 would lead to those commands doing the most volume they could (i.e. aspirate the full tip volume, dispense whatever's currently in the pipette, mix at full volume) and this likely was an unintentional side effect because of python truthiness. However, that change only touched the python protocol API; that API would emit commands to the engine that specified 0 volume, and those were not allowed: the pydantic models for the commands and responses required strictly greater than 0 volume. This PR - changes the pydantic models and updates the schema to allow 0ul commands - adds a python protocol to be an integration test - adds unit tests for the python protocol api aspirate and dispense commands --------- Co-authored-by: Seth Foster <[email protected]> Co-authored-by: Max Marrone <[email protected]>
--------- Co-authored-by: Max Marrone <[email protected]>
On ProtocolDetails, regardless of whether we show a slideout from sending a protocol to Flex or starting setup, we should retrieve an identical list of available robots. Here, if the start setup button is clicked, I check whether the protocol analysis's robot type is a Flex, and if so, pass a prop to ChooseRobotSlideout to show only healthy reachable Flexes.
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## edge #14236 +/- ##
==========================================
- Coverage 70.44% 70.38% -0.06%
==========================================
Files 2512 2513 +1
Lines 71284 71331 +47
Branches 9003 9033 +30
==========================================
- Hits 50215 50207 -8
- Misses 18861 18918 +57
+ Partials 2208 2206 -2
Flags with carried forward coverage won't be shown. Click here to find out more.
|
ncdiehl11
changed the title
Co-authored-by: wweiye <[email protected]>
Fix bug that was causing ci to attempt the publish step of every pr build
…14138) Updates the PD blow_out default values
* pass around mypy protocol instead of OT3API * Explicit parameterization of config types * Fix some tests with the protocol engine related to protocol changes * Added a `FlexInstrumentConfigurer` for flex-specific configuration extensions * Update test mocks to differentiate ot2/ot3 hardware * Modifed `get_robot_type` to be parameterized on some singleton class types for robot models * remove unnecessary TYPE_CHECKING import * Add tip presence protocol functions to satisfy edits to tip manager
…lient): update to react 18 (#14114) Update all react projects to react 18 and manage its sub dependencies Co-authored-by: Shlok Amin <[email protected]>
#14203) emit dropTipInPlace after moveToAddressableAreaForDropTip commands in step-generation
* fix(app): add dimsissing current run back * fix(app): fix robot stuck in cancelled state * test fixes
|
decided to put on hold until a later release, so opening a new PR pointing at |
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.
closes RQA-2028
Overview
On ProtocolDetails, regardless of whether we show a slideout from sending a protocol to Flex or starting setup, we should retrieve an identical list of available robots. Here, if the start setup button is clicked, I check whether the protocol analysis's robot type is a Flex, and if so, pass a prop to ChooseRobotSlideout to show only healthy reachable Flexes.
Test Plan
Changelog
Risk assessment
Medium