docs(api): new_modules.rst revsions for Flex #13143
Conversation
Starting revisions.
Mid-day save.
Mid afternoon push.
More saves.
Afternoon save.
Near end of day save.
Some progress at lunch. Saving.
Late lunch save.
pre-meeting save
End of day revisions.
Starting and continuing revisions on Wednesday.
spelling error
End of day save
Morning update, magnetic block.
post-lunch save
Saving to turn in to a draft pr.
Codecov Report
@@ Coverage Diff @@
## edge #13143 +/- ##
==========================================
- Coverage 72.56% 72.44% -0.13%
==========================================
Files 2391 2357 -34
Lines 65946 64895 -1051
Branches 7306 7202 -104
==========================================
- Hits 47857 47013 -844
+ Misses 16344 16143 -201
+ Partials 1745 1739 -6
Flags with carried forward coverage won't be shown. Click here to find out more. |
Removing commented text. Adjusting code samples.
Changes to deck slot note and put module methods in a bullet list under the "Additional labware parameters" section.
api/docs/v2/new_modules.rst
Outdated
| | GEN1 | | | | ||
| +--------------------+-------------------------------+---------------------------+ | ||
|
|
||
| Some modules were added to our python API later than others, and others span multiple hardware generations. When writing a protocol that requires a module, make sure your ``requirements`` or ``metadata`` code block specifies a :ref:`Protocol API version <v2-versioning>` high enough to support all the module generations you want to use. |
There was a problem hiding this comment.
Do we need to add another table or list here to indicate which modules are usable on Flex vs. OT-2? Expanding this table out to 5 columns would be a bit 😵💫
Leaning towards list because we can say "Flex supports HS, Temp 2, TC 2, and Mag Block only. OT-2 supports everything except Mag Block"
There was a problem hiding this comment.
Ouch, a 5-column table would be too much. I wonder if adding more text adds complexity without help. Instead, it may be simpler to call out a module only when it doesn't work with a particular robot.
For example, the draft already does this now with the Magnetic Module and Magnetic Block. There's a note under the section header that says, "Recommended for use with insert robot here only."
Unless we say something, the default assumption (dangerous) should be all modules work with all robots unless indicated otherwise.
api/docs/v2/new_modules.rst
Outdated
| def run(protocol_api.ProtocolContext): | ||
| mag_block = protocol.load_module('magneticBlockV1', 'D1') | ||
|
|
||
| .. load something on the magnetic block here example. |
There was a problem hiding this comment.
can be part of the above snippet. it uses load_labware() like all other module contexts.
api/docs/v2/new_modules.rst
Outdated
|
|
||
| In order to send commands to the correct module on the deck, you need to load the modules in your protocol in a specific order. Whenever you call :py:meth:`.load_module` for a particular module type, the OT-2 will initialize the matching module attached to the lowest-numbered USB port. Deck slot numbers play no role in the ordering of modules; you could load a Temperature Module in slot 4 first, followed by another one in slot 3: | ||
| In order to send commands to the correct module on the deck, you need to load the modules in your protocol in a specific order. Whenever you call :py:meth:`.load_module` for a particular module type, the robot will initialize the matching module attached to the lowest-numbered USB port. Deck slot numbers play no role in the ordering of modules; you could load a Temperature Module in slot C1 first, followed by another one in slot D3: |
There was a problem hiding this comment.
the notion here was to have the "higher" number slot load first. so maybe D1 first, then C1, or something like that. (there's less of an obvious ordering with coordinate slots than numeric slots)
There was a problem hiding this comment.
Yes, this is a good idea. I will try to make it more clear in the text. As you note, it is tricky with Flex because of the alphanumeric deck system. Visually row D is first or closest to the user, followed by C, but C comes before D in the alphabet. I will use an example with a module in D3/usb 2 and C1 usb 6 (to match the usb connections on the image) to show how a module on D3 would load before C1 because of the usb port number.
There was a problem hiding this comment.
Pushed revisions to draft this morning.
api/docs/v2/new_modules.rst
Outdated
| .. image:: ../img/modules/multiples_of_a_module.svg | ||
|
|
||
| Before running your protocol, it's a good idea to use the module controls in the Opentrons App to check that commands are being sent where you expect. | ||
|
|
||
| For additional information, including using modules with USB hubs, see our `support article on Using Multiple Modules of the Same Type <https://support.opentrons.com/s/article/Using-modules-of-the-same-type-on-the-OT-2>`_. | ||
| .. Does the support article apply to Flex? |
There was a problem hiding this comment.
let's check with support.
There was a problem hiding this comment.
Checking in Slack: https://opentrons.slack.com/archives/C0JLZLPL3/p1690306874357039
Mid-afternoon push.
Pushing end of day draft.
Multiple modules / same type section.
More revisions. Finished for now with this section. Checking comments.
Once more on this section. Moving on after this.
Committed. Co-authored-by: Ed Cormany <[email protected]>
Committed. Co-authored-by: Ed Cormany <[email protected]>
Committed. Co-authored-by: Ed Cormany <[email protected]>
Quick push
…pentrons/opentrons into hardware-modules-docs-revisons
Committing Co-authored-by: Ed Cormany <[email protected]>
Committing change Co-authored-by: Ed Cormany <[email protected]>
Adding to batch commit. Co-authored-by: Ed Cormany <[email protected]>
Committing Co-authored-by: Ed Cormany <[email protected]>
Pulling batch commit and pushing stashed changes.
Adding `from opentrons import` statement to code samples.
More revisions and end of day push.
Another draft for review. final_final_final ? maybe?
|
Closing in favor of #13183 🚚 |
Overview
Suggested text and code example revisions to the Modules API docs (new_modules.rst file) to include Flex code and code examples.
Test Plan
Changelog
Review requests
Check for proper Python usage and writing/style.
Risk assessment
Low, documentation changes and code samples only.