Opentrons: bug: APIv2 protocols can’t access the 2nd row of custom 384 well plates

[sachalau]

Overview

A fix was included in 3.16 to allow access to 2nd row of 384 plates in API v2. However both 3.16.0 and 3.16.1 fail to allow accessing at the simulation process.

Current behavior

StopIterration error when trying to fill 2nd row in 3.16.1. The error was different in 3.16.0 (Invalid target for multichannel transfer)

Steps to reproduce

Here is the code I use to access 2nd row :

from opentrons import protocol_api

num_ADN = 16

metadata = {
"protocolName": 'Mix prepration',
"author" : "Sacha Laurent <[email protected]>",
"description": "Preparation of PCR Master Mixes into 384-well plates for KASP exome sample tracking panel by LGC",
"apiLevel": "2.0"
}



def run(protocol: protocol_api.ProtocolContext):

#labware
tuberack = protocol.load_labware("opentrons_24_aluminumblock_nest_1.5ml_snapcap", "2")
tip10rack = protocol.load_labware("opentrons_96_tiprack_10ul", "5")
tip20rack = protocol.load_labware("opentrons_96_tiprack_20ul", "3")
plate_96 = protocol.load_labware("opentrons_96_aluminumblock_generic_pcr_strip_200ul", "10")
plate_384 = protocol.load_labware("roche_384_wellplate_20ul", "1")


#pipettes
pipette_multi = protocol.load_instrument("p10_multi", "right", tip_racks=[tip10rack])
pipette_single = protocol.load_instrument("p20_single_gen2", "left", tip_racks=[tip20rack])


for i in range(2):
# Dispatch one column of mix to 384 plate
pipette_multi.pick_up_tip()

pipette_multi.distribute(2.5, plate_96.columns()[i], [plate_384[chr(ord("A")+i)+str(x)] for x in range(1, num_ADN+1)] , new_tip="never", disposal_volume=0)
pipette_multi.drop_tip()

Expected behavior

Allow access to 2nd row. The code snippet works when using for i in range(1).

┆Issue is synchronized with this Wrike Task by Unito

[SyntaxColoring]

@sachalau Try bumping your apiLevel to 2.2.

[sachalau]

No luck again, I get the "Invalid target for multichannel transfer" error again when using apiLevel 2.2

[SyntaxColoring]

@sachalau What happens if you replace "roche_384_wellplate_20ul" (your custom labware) with"corning_384_wellplate_112ul_flat" (a standard labware)?

[sachalau]

It does work with the standard labware

[SyntaxColoring]

Hm, okay. I think this is a bug that we didn’t know about before. I’m going to edit the issue title to clarify that this is separate from what just got fixed in v3.16.0.

As a quick workaround until this gets fixed, you can try using the standard "corning_384_wellplate_112ul_flat" definition, with these caveats:

• The height of the plate will be wrong, possibly causing the tip to crash into the labware during labware calibration. To work around this, keep the plate off the deck initially, then jog the pipette up, then place the plate under the pipette. Proceed with the rest of labware calibration as normal.
• The well depth will be wrong, possibly causing the tips to bottom out during the run. You can work around this by using well.top(z=...) with a negative z value to specify the tip position relative to the top of the well.

[mcous]

The API relies on the labware's parameter.format field to be "384Standard" for 384 well plates to work properly. The Labware Creator always sets the value of parameters.format to irregular; see labware-library/src/labware-creator/fieldsToLabware.js. From what I can tell, this is a bug in Labware Creator, not the API itself

@sachalau if you open your custom labware JSON file and change the value of parameters.format from "irregular" to "384Standard", does everything work?

[mcous]

On second thought, removing the "api" label was premature until we've confirmed, and also it's weird that we require a parameters.format field at all. Presumably examining the well layout and making decisions that way would work

[SyntaxColoring]

Workaround

If you run into this, a workaround is to open the custom labware .json file and edit it: change parameter.format to 384Standard. Note the capitalization.

[sachalau]

Thanks for the workaround, I'll implement it as soon as I can !

[theosanderson]

To piggyback, a general issue is "labware creator does not generate JSON files that follow style of Opentrons shared_data". Nice to have features would include prettifying the JSON (https://github.com/theosanderson/opentrons/compare/ca54a3fc5218c73aa5c9e595f12edc8ace89ecbe...e4fee7b790782404527e1f7f3532aaa3337d728f) so that (A) it is ready to go to the OT repository and pass CI (B) This just looks a lot nicer for e.g. the layout of people's custom labware.

[theosanderson]

Expanding on the "labware creator does not generate JSON files that follow style" point: the labware creator erroneously assigns the metadata also to the "groups" of a plate. https://github.com/Opentrons/opentrons/pull/5776#discussion_r433492432

[anthonywilleee]

Adding some comments from Max:

Labware definitions have a parameter.format field (96Standard, 384Standard, trough, irregular, or trash) that’s somehow involved in positioning 8-Channel pipettes.

For 384 well plates, Labware Creator never sets that field to 384Standard.

The Python Protocol API needs the field to be 384Standard for 8-Channel access to the second row to work. So you can’t use 384 well plates from Labware Creator in the Python API without doing some hacky stuff.

Protocol Designer, apparently, ignores 384Standard, and looks at the labware geometry itself (are these wells 4.5 mm apart?) to figure out if it looks 384-ish.