-
Notifications
You must be signed in to change notification settings - Fork 180
docs(api): lids updates in 8.4 #17914
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good so far, some comments below regarding a few edge cases.
api/docs/v2/moving_labware.rst
Outdated
Use ``move_lid()`` again to move a used ``opentrons_tough_pcr_auto_sealing_lid`` to a ``WasteChute`` or ``TrashBin`` loaded in your protocol. | ||
|
||
.. note:: | ||
You can only move an ``opentrons_flex_tip_rack_lid`` from a new tip rack to the ``WasteChute`` or ``TrashBin``, either manually or with the Flex gripper. The tip rack lid must be defined in your protocol using the ``lid`` parameter of ``load_labware``. For more, see :ref:`loading-lids`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can also move them onto another tip rack which does not currently have a lid. The example case being, you load one tiprack with a lid and one tiprack without a lid. On step two, you move the lid from tiprack A to tiprack B.
@@ -1391,13 +1391,13 @@ def load_lid_stack( | |||
version: Optional[int] = None, | |||
) -> Labware: | |||
""" | |||
Load a stack of Lids onto a valid Deck Location or Adapter. | |||
Load a stack of Opentrons Tough Auto-Sealing Lids onto a valid deck location or adapter. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Load lid stack can in theory be used by any stackable lids (of which only the auto-sealing lids apply), so we might want to use more general terminology.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like limiting it to what's possible now — we can always update when we add more labware and this becomes a more broadly applicable feature.
quantity="4") | ||
|
||
## move an Opentrons Tough PCR Auto-Sealing Lid to a compatible well plate in the Thermocycler | ||
protocol.move_lid( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@CaseyBatten do we not specify the load name for the lid being moved?
lid="opentrons_flex_tiprack_lid") | ||
|
||
|
||
You might need multiple lids during your protocol. Use ``load_lid_stack`` to stack up to five Opentrons Tough Auto-Sealing Lids on a deck slot, riser, or compatible adapter. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@CaseyBatten is there a maximum of 5? I can't find where I read this originally. If true, should also maybe add to API reference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its a maximum of 5 based on the stackLimit
in the labware definition for the Tough Auto-Sealing lids. Technically a labware could have a stack limit of any number, so long as we define it as such. The auto sealing lids become unstable after 5 lids, so we limit them to 5.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some comments on the use of code formatting vs regular text formatting. My main takeaway:
- When referring to literal code, use the code formatting.
- When referring to an actual thing or general concepts or to enhance readability, sometimes plain text/regular text is better.
PS I have probably used the wrong full name for the auto-sealing PCR plate. I'm not really sure what that thing is called, its full, formal name.
api/docs/v2/moving_labware.rst
Outdated
|
||
You can move compatible Opentrons lids manually or with the Flex gripper, but some restrictions apply. For more, see :ref:`moving-lids`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is minor, the "For more" perhaps should be:
You can move compatible Opentrons lids manually or with the Flex gripper, but some restrictions apply. For more, see :ref:`moving-lids`. | |
You can move compatible Opentrons lids manually or with the Flex gripper, but some restrictions apply. For more information, see :ref:`moving-lids`. |
or just "See moving-lids
"
api/docs/v2/moving_labware.rst
Outdated
|
||
Lids on well plates or tip racks can help prevent contamination on the deck and are required for use with some modules, like the Thermocycler. You can use :py:meth:`.ProtocolContext.move_lid` to move an ``opentrons_tough_pcr_auto_sealing_lid`` or ``opentrons_flex_tiprack_lid`` manually or using the Flex gripper. | ||
|
||
An `opentrons_tough_pcr_auto_sealing_lid` can be moved between deck slots, lid stacks, or compatible labware, modules, and adapters loaded in your protocol. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sometimes, a bit of text can read easer if the noun is referred to by name rather than by code. If you're explicitly referring to a code example, then I'd use the code
typeface, but this seems more like a "general" type example so I'd suggest regular text because the sentence is about the actual object, not the code.
An `opentrons_tough_pcr_auto_sealing_lid` can be moved between deck slots, lid stacks, or compatible labware, modules, and adapters loaded in your protocol. | |
An Opentrons Tough PCR lid can be moved between deck slots, lid stacks, or compatible labware, modules, and adapters loaded in your protocol. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree in general, prefer plain English names unless directly referring to something in a code block.
api/docs/v2/moving_labware.rst
Outdated
Use ``move_lid()`` again to move a used ``opentrons_tough_pcr_auto_sealing_lid`` to a ``WasteChute`` or ``TrashBin`` loaded in your protocol. | ||
|
||
.. note:: | ||
You can only move an ``opentrons_flex_tip_rack_lid`` from a new tip rack to the ``WasteChute`` or ``TrashBin``, either manually or with the Flex gripper. The tip rack lid must be defined in your protocol using the ``lid`` parameter of ``load_labware``. For more, see :ref:`loading-lids`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest the same thing as my comment above, though this might be an ambiguous case. Consider this:
Use ``move_lid()`` again to move a used ``opentrons_tough_pcr_auto_sealing_lid`` to a ``WasteChute`` or ``TrashBin`` loaded in your protocol. | |
.. note:: | |
You can only move an ``opentrons_flex_tip_rack_lid`` from a new tip rack to the ``WasteChute`` or ``TrashBin``, either manually or with the Flex gripper. The tip rack lid must be defined in your protocol using the ``lid`` parameter of ``load_labware``. For more, see :ref:`loading-lids`. | |
Use ``move_lid()`` again to move a used Opentrons Tough PCR lid to a waste chute or trash bin loaded in your protocol. | |
.. note:: | |
You can only move an Opentrons Tough PCR lid from a new tip rack to the waste chute or trans bin, either manually or with the Flex gripper. The tip rack lid must be defined in your protocol using the ``lid`` parameter of ``load_labware``. For more information, see :ref:`loading-lids`. |
The "note" is a good example here. You're moving a lid not a piece of code to other real, physical objects.
Now the last sentence of the note is ok because it is talking about code.
26a88b0
to
f188a10
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## chore_release-8.4.0 #17914 +/- ##
=======================================================
- Coverage 26.55% 26.47% -0.08%
=======================================================
Files 3111 3115 +4
Lines 236772 237781 +1009
Branches 19221 19194 -27
=======================================================
+ Hits 62880 62958 +78
- Misses 173870 174801 +931
Partials 22 22
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
f188a10
to
ab6fb90
Compare
ab6fb90
to
41bf7e5
Compare
Since we have isolated Robot Stack release 8.4 into `chore_release-8.4.0` we must lock down command schema 12 for that Robot Stack Release. If changes are needed to command schema 12 they must first be done in `chore_release-8.4.0` then incorporated in `edge` via a merge back.
This PR adds the ability to generate python for quick transfer behind a feature flag. It also logs it in devtools so you can view the actual python file, otherwise there is no other way to view the file.
…nds (#17881) # Overview We want to enable error recovery during a protocol if the Flex Stacker shuttle is not detected. This PR does the first step, which is to catch this error. The hardware controller layer now checks for the platform status before executing dispense and store labware, and raises the appropriate error. closes EXEC-1287, EXEC-1200
…o stall obstruction (#17773)
…with liquid (#17818) <!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview Removing instances where tips were returning with liquid in them ## Test Plan and Hands on Testing Ran protocols and checked tip rack bases upon completion to ensure they were empty. ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. -->
…17899) <!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview DVT Flex Stacker Accelerated Lifetime Test ## Test Plan and Hands on Testing Ran in SZ ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. -->
…ime Test (#17898) <!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview DVT Flex Stacker Labware Compatibility Lifetime Test ## Test Plan and Hands on Testing - Ran in SZ ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. --> --------- Co-authored-by: Carlos <[email protected]>
…uipment up in invariantContext (#17865) Pretty big refactor with step-generation in particular (but also touched a few files in PD and the app for quick transfer) where the `invariantContext` type key `additionalEquipmentEntities` is split up to 4 separate keys. The total `InvariantContext` looks like this: ``` export interface InvariantContext { labwareEntities: LabwareEntities moduleEntities: ModuleEntities pipetteEntities: PipetteEntities wasteChuteEntities: WasteChuteEntities trashBinEntities: TrashBinEntities stagingAreaEntities: StagingAreaEntities gripperEntities: GripperEntities liquidEntities: LiquidEntities config: Config }
… errors & warnings (#17893)
…Props (#17843) This PR utilizes the existing `propsForFields` structure to pass all necessary fields to `CheckboxExpandStepFormField` for the implicated checkbox stepform field. Instead of individually passing values for the field props `value`, `updateValue`, `isChecked`, `tooltipText`, and `disabled`, we can simply pass that field's `propsForFields`, and destructure inside the checkbox expand component.
Covers EXEC-1266 Updates the Max pool limit to accounts for the overlap of the last labware within a given pool over the first.
41bf7e5
to
361ce3e
Compare
361ce3e
to
de110bb
Compare
This PR is stuck in branch h*ck. Closing in favor of #17972, which is freshly branched from |
Replacing #17914 Below description from that PR. # Overview API docs update for new lids methods in API 2.23: `load_lid_stack`, `move_lid`, and lids loaded onto labware. ## Test Plan and Hands on Testing sandbox: http://sandbox.docs.opentrons.com/docs-lids-in-8.4/v2/ ## Changelog - light editing to API reference entries; including removing a TODO - Loading Labware section: updating well plate used throughout the section so we can demonstrate loading a lid onto it; adding a new "Loading Lids" subsection - Moving Labware section: new "Moving Lids" section that can grow as we add more lids, like cell culture lids, compatible with `move_lid` ## Review requests Code blocks correct? Anything missing? Do we like where new information was added? Maybe update the Auto-Sealing Lids section for the [Thermocycler module example](https://docs.opentrons.com/v2/modules/thermocycler.html)? ## Risk assessment Low. --------- Co-authored-by: emilyburghardt <[email protected]>
Overview
API docs update for new lids methods in API 2.23:
load_lid_stack
,move_lid
, and lids loaded onto labware.Test Plan and Hands on Testing
sandbox: http://sandbox.docs.opentrons.com/docs-lids-in-8.4/v2/
Changelog
move_lid
Review requests
Code blocks correct? Anything missing? Do we like where new information was added?
Maybe update the Auto-Sealing Lids section for the Thermocycler module example?
Risk assessment
Low.