Opentrons: how to handle Transfer volumes that exceed the maximum volume of a pipette?

[bbartley]

There are situations in which an operator may wish to transfer a volume that exceeds the maximum capacity of the mounted pipettes. There are a few possible ways in which we might deal with this:

• Throw an error that says "you can't do that, because you've exceeded the maximum volume" and force the user to break the Transfer down into multiple Transfer steps, e.g., 200 uL, then another 200 uL, then another 200 uL...
• Throw an error that says "you can't do that, because you've exceeded the maximum volume", but provide an optional parameter that allows the user to specify they want to repeat a Transfer n times
• Make the Specialization smart enough to figure out for itself the most parsimonious way to break the Transfer down into multiple steps

[jakebeal]

I would definitely be inclined towards option 3, since this is about execution of a general protocol not just on OpenTrons but on a specific robot under a specific configuration. I would find it extremely problematic to have "my robot has only a 50 uL pipette this morning" end up propagating back up to the protocol.

What I do think would make sense as an option, however, would be:

1. Have the Specialization log a warning that it's planning to break down the operation into multiple steps
2. Have an option for a "no decomposing transfers" in which the warning is instead an error. That would allow a user to choose whether to reconfigure their deck or to allow the breakdown.

[danbryce]

Inspired by @photocyte script that couldn't translate cherry picking to transfer operation.

Dan's take is that the protocol itself wouldn't enforce any semantics. The specialization should be where we warn, raise errors, or handle interpretation. The standard doesn't have a say about how this happens.

[photocyte]

For posterity, link and text of original script/context:
https://bitsinbio.slack.com/archives/C02UJJ3AND8/p1667401643485429

"
, really exciting to hear progress on LabOP Opentrons specialization! Continuing our discussion from this weeks meeting, these are the protocols I've been adapting https://protocols.opentrons.com/protocol/cherrypicking , and a more recent fork: https://protocols.opentrons.com/protocol/6d901d-2 , for my current wetlab work. The modification I'd like to do is have a single transfer as specified by these CSVs (note 1: The CSV formats are different between the two versions, I prefer the CSV format for the cherrypicking protocol), actually be 3x repeated transfers with a single tip (no dropping & picking up new tips between transfers). (Note 2: The CSV gets baked into a JSON that is hardcoded into the .py , not ideal, but that is the Opentrons standard at the moment. I have a Jupyter notebook that simplifies making that JSON). The simple way: Have it be so the CSV specified volume, i.e. 300 µL, just gets repeated 3 total times. The harder way: make it so 900 µL could be specified in the CSV, but then the script would figure out how many transfers it should do, including doing "partial" transfers (say transferring 50 µL vs 300 µL). Would be curious to hear your thoughts on adapting this to LabOP...
"