-
Notifications
You must be signed in to change notification settings - Fork 180
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
docs(api): Flex revisions for Building Block Commands #13282
Conversation
Replace uL with muL and make sure there's a space between the number and unit in text and comments.
Getting started. Revised intro.
New intro, reorg headers, lunch save.
Following the beginning style and organization used by the Tutorial section, tutorial.rst. Committing to save and pull down changes from the merged pipettes doc.
internal code comment as reminder/placeholder of where to start.
Codecov Report
@@ Coverage Diff @@
## edge #13282 +/- ##
=======================================
Coverage 72.24% 72.24%
=======================================
Files 2407 2407
Lines 66581 66565 -16
Branches 7441 7441
=======================================
- Hits 48101 48091 -10
+ Misses 16695 16689 -6
Partials 1785 1785
Flags with carried forward coverage won't be shown. Click here to find out more. |
Revise text. Link to page intro for labware used and base protocol code. Link to liquid handling methods in intro. Skipping tip iteration section and will come back to it.
api/docs/v2/new_atomic_commands.rst
Outdated
|
||
.. note: | ||
You tell the robot to discard a used tip by calling the :py:meth:`.InstrumentContext.drop_tip` method. This method automatically drops a tip in the on-deck trash bin. It also lets you set a specific drop location. This code builds on the pick up command by including ``drop_tip()``. |
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.
Not sure if this is the right place for it but we should note somewhere that from v2.15 onwards, if you don't specify a drop tip location, the robot will drop tips in multiple locations within the trash container (as opposed to always dropping them in the center of the container) in order to prevent tips from piling up in a single spot.
I know @ecormany has added a line for it in versioning doc but I think we should mention it in these docs too.
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.
How about something like this:
You tell the robot to discard a used tip by calling the
:py:meth:.InstrumentContext.drop_tip
method. This method automatically drops a tip in the on-deck trash bin. And, starting with v2.15, if you don't specify a location, the robot will drop tips in different spots within the trash container. This behavior helps prevent tips from stacking up in a single location. The optionallocation
argument also lets you set a specific drop position. This code builds on the pick up command by includingdrop_tip()
.
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 all looks good except the last sentence confuses me. I'm in the shoes of a reader who has jumped right to this section because I want to learn about drop_tip()
, so it's not obvious what came before, or why drop_tip()
would "build on" pick_up_tip()
.
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.
Yeah, this is a sentence, and repeated instances in other sections that can be removed. The idea is this page is similar to the tutorial and each section builds upon the previous. I can see this doesn't work. Will remove here and where used elsewhere.
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 think we add "New in version " for new features, ya. I was thinking something like this would go in that section since it would also give an old user a quick summary of what changed in 2.15 with regards to drop tip.
BUT, if that's not what the 'New in version..' labeling is used for (or you don't think it's a good idea) then your write-up looks good too 👍
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 should get a .. versionchanged:: 2.15
label.
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.
Removed that sentence from the main paragraph. It now appears above the tag .. versionchanged:: 2.15
.
If you don’t specify a location, the robot will drop tips in different spots within the trash container. This behavior helps prevent tips from stacking up in a single location.
Changed in version 2.15
Adding versionadded tag and placing related text above tag.
Closing this in favor of a new PR, #13376. |
Overview
This is a revision to the API doc, Building Block Commands. The file is
new_atomic_commands.rst
.The purpose is to update and include Flex info, examples, and context in the API docs. The structure, text, and code samples in the current doc will change, but we're working to keep it similar to the original.
Sandbox: https://docs.opentrons.com/v2/new_atomic_commands.html
Test Plan
We need code samples for Flex and OT-2. Part of the testing is checking code in the App after modification.
Additional testing would be the usual editorial review for grammar, style, consistency, etc.
Changelog
Changes include treating this doc similar to the Tutorial. We'll have an equipment/labware section, a section with base protocol code for Flex and OT-2, and then code samples that show just enough to work with each robot without repeating the usual protocol file boilerplate.
Other changes give this doc a stronger outline / organization and revising the text.
Review requests
@ecormany (as usual).
Risk assessment
Pretty low risk. Documentation changes only.