You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if the user simulates a protocol on the robot and the protocol spec's pipettes that are incompatible with the currently attached pipettes, neither the app nor the API prevents the user from proceeding to calibration and then run.
In a well-behaved system, this would be the job of the API to block this behavior, but the entanglement of the RPC API prevents us from doing this properly at this time.
As a stop-gap until the RPC API is replaced, the app should keep the user at the file info page (i.e. disable the calibration and run navigation tabs) if the app detects that the session (protocol simulation) pipettes do not match the attached pipettes (GET /pipettes)
User is able to calibrate pipettes / labware with incorrect pipettes and proceed to run
This behavior is a holdover from when we weren't comfortable blocking users with "incompatible" pipettes because a non-trivial number of pipettes were leaving the factory without their provisioning process being properly completed. This factory process issue was solved a long time ago.
acceptance criteria
If the robot's attached pipettes are incompatible with the pipettes spec'd in the protocol:
"Calibrate" nav button is disabled with a tooltip
"Please attach the correct pipettes before calibrating your equipment" or similar
"Run" nav button is disabled with a tooltip
"Please attach the correct pipettes before running your protocol" or similar
Note: Disabling the top-level nav button is a lot more straightforward than enabling the page and disabling individual control elements, due to the same entanglement concerns that are leading us to deal with this in the app in the first place.
open questions
Do we block the flows by either:
Disabling the top-level nav button with a tooltip?
Enabling the page but disabling
After a pipette swap, does the protocol need to be re-simulated?
Ping @Opentrons/py
The text was updated successfully, but these errors were encountered:
overview
Currently, if the user simulates a protocol on the robot and the protocol spec's pipettes that are incompatible with the currently attached pipettes, neither the app nor the API prevents the user from proceeding to calibration and then run.
In a well-behaved system, this would be the job of the API to block this behavior, but the entanglement of the RPC API prevents us from doing this properly at this time.
As a stop-gap until the RPC API is replaced, the app should keep the user at the file info page (i.e. disable the calibration and run navigation tabs) if the app detects that the session (protocol simulation) pipettes do not match the attached pipettes (GET /pipettes)
related issues
current behavior
User is able to calibrate pipettes / labware with incorrect pipettes and proceed to run
This behavior is a holdover from when we weren't comfortable blocking users with "incompatible" pipettes because a non-trivial number of pipettes were leaving the factory without their provisioning process being properly completed. This factory process issue was solved a long time ago.
acceptance criteria
If the robot's attached pipettes are incompatible with the pipettes spec'd in the protocol:
Note: Disabling the top-level nav button is a lot more straightforward than enabling the page and disabling individual control elements, due to the same entanglement concerns that are leading us to deal with this in the app in the first place.
open questions
The text was updated successfully, but these errors were encountered: