-
Notifications
You must be signed in to change notification settings - Fork 175
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
Update PD Staging Beta #2646
Merged
Merged
Update PD Staging Beta #2646
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
* chore(api): Add 'TODO's to labware-related tests. Closes #2259
The protocol API will be the way for protocols to interact with the OT2 system. It will allow users to run protocols locally and simulate them as well as allowing the higher level system to run the protocols on a robot. It will couple to the hardware controller. This commit introduces the structure of the API. It is conceptually similar to the robot API we currently use, but explicitly notes that what you manipulate are contexts rather than exact hardware representations. The required changes to current protocols are minimal and are only in fact required to run a simulation with the protocol as an entrypoint. Closes #2233
* feat(api): Add top, bottom, and center methods to Well Add top, bottom, and center methods to Well, and add internal methods for referencing an abstract position relative to the center of a well using cartesian coordinates (all methods return a point in absolute deck coordinates). Also moves the new labware module to `opentrons.protocol_api.labware` Closes #2369
…efs (#2380) * feat(shared-data): Add generator function to create regular labware defs
The jupyter notebook package has a bug in 5.7.0 where specifying the notebook application’s listening ip as ’*’ causes it to fail to boot: jupyter/notebook#3946 The workaround listed there is to bind the server to 0.0.0.0 instead, so we do that here. Closes #2394
* feat(api): Add back compat shim for new protocol API and restructure old This commit puts the components of the old protocol api (robot, instruments, etc) into a new `legacy_api` subpackage. It moves the singletons previously defined in`opentrons/__init__` into a file in `legacy_api`, and creates similar ones in `protocol_api/back_compat`. Then, `opentrons/__init__` now conditionally imports the right one based on a feature flag. This means it is now possible (using the feature flag) to import opentrons without the robot singleton being instantiated. It also means it is now possible to import components of the legacy API without actually instantiating them. In addition, this commit adds a new file, `simulate_protocol.py`, that will be the frontend for simulating protocols without a robot. Closes #2246
* chore(api): Require mypy pass for lint pass and fix type errors
…e in tooltip (#2400) Restructure the return value of compound step generators such that their constituent atomic aspirate and dispense actions are not reduced to one step. With the new substep specific intermediate liquid states reshape the way that the steplist generated StepListItems and its children SubstepRows to rely on mid step liquid state, as opposed to initial liquid state of the entire parent step. Instead of passing down a boolean flag to substep rows for presence or absence of liquid in source and destination wells, give them a map of all well liquids and their individual volumes. Display all of this in a HoverTooltip on IngredPill. Closes #2286
* update step-generation & JSON schema to support new optional field * add default-values param for touch-tip offset
* refactor(api): Split out protocol_api.__init__ to submodules This file was getting a bit out of hand and promising to get much worse. The context classes are now in contexts and the deck is in geometry. Other geometry-related, context-free utilities should be placed there as well. * refactor(api): Add instrument load, aspirate, dispense to protocol_api Closes #2243
* add labware details card component & container * add EditableTextField component * remove old LabwareNameEditForm and its reducers + actions + selectors * replace overly-imperative MODIFY_CONTAINER action with RENAME_LABWARE action * (components) modify type of InputField's units to be Node, not just string Closes #2428
* refactor(api): Change motion target locations and add arcs The motion commands in the protocol API take a new type, Location, which has a reference to a labware or well it is related to. This labware or well is used by a new function, geometry.plan_arc, to break down individual motion commands into either arc or direct moves depending on if the target is in the same well or labware as the target of the last move. In addition, change the Well class position accessors (top(), bottom(), center()) to return a Location instead of just a Point, and build Wells with references to their parent Labwares.
…ield validation (#2574) Consolidate step error logic to formLevel and fieldLevel error getters. Remove error block from stepFormToArgs functions. Clean up hydration pathways.
…2606) * refactor(api): aspirate and dispense can be given wells as position You can now do aspirate(2.0, lw.wells()[0]) instead of aspirate(2.0, lw.wells()[0].top()). * refactor(api): hardware_control handles retracting the last mount The protocol api now always refreshes its location cache with the gantry position for the specified mount to catch moves made either automatically by the hardware control (like a retract) or a user.
Hardware control now checks that incoming gantry moves are in acceptable bounds. That means less than the home position and > 0, for XYZA. If the move is outside bounds, hardware_control raises a RuntimeError. This bounds checking is applied in deck coordinates after the mount offset and critical points are applied, which means that top level move calls may succeed or fail based on the state of the rest of the system. For instance, with no pipette attached to the right mount, move_to(RIGHT, Point(50, 50, 0)) will fail (because the mount on its own cannot descend to 0); but with a P300 single with tip attached in the right mount, that move will move the end of the tip to the deck.
* add 48-well-plate * remove 24-vial-rack; clarify 0.2mL PCR strip name * fix labware typo in API docs Closes #2583
) * separate name-level vs model-level pipette specs in shared-data * support unversioned pipettes in JSON protocol execution in Python API * drop versioning from PD (strip out from loaded files) * update Run App to use new shared-data getters * Python API loads newly-split pipettes config * rename nominalMaxVolume to maxVolume * rename aspirateFlowRate to defaultAspirateFlowRate (same for dispenseFlowRate) * add JSON schemas and consistency checks for pipette data * remove underscore from _retrieve_version_number fn * add README for pipette data * for backwards compatibility, always include 'model' field with hard-coded "_v1.3" suffix in JSON protocols, in addition to 'name'
* refactor(api): Make pipette get tip length from tip rack
* implement Alt-Up / Alt-Down key combos to reorder steps
Partition views within tabs, so that forms and modals do not appear outside of their home tab. Properly restrict tab navigation, when in blocking state(e.g. analytics modal, splash). Preserve form state when navigating between liquids and design tabs. Closes #2198
Instead of locking users into their initial pipette selection, we now allow users to select and change their pipette while designing their protocol. In the best case, the change will happen silently and will not effect the protocol at all. In the worst case, changing pipettes might require users fixing invalidated parts of many affected steps and adding more tipracks to accommodate the change. Closes #2474, #2475, #2477, #2632
IanLondon
approved these changes
Nov 8, 2018
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.
⏳
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.
Move new updates to staging branch for QA