i started using the term “troughplate” to differentiate from “wellplates”. a troughplate and a wellplate with 12 children will have a different layout (1x12 vs 3x4).
(thought it got kinda boring with just the “wellplate” specification)
3 questions:
I noticed the small-letter start of the name: is this to represent that it’s a function? I thought we would adhere to a capital letter start to represent the class instance that the function returns?
Should we call this a “troughplate” or a “reservoirplate”? Nomenclature is, as usual, quite ambiguous here and PLR has a chance to standardise nomenclature internally. Assuming identical meaning of these two terms, I prefer the term “trough”, simply because it’s shorter and easier to spell but I think we should clearly state our intentional use of the word here.
I don’t think this has to be the case?:
Can the arrangement of children not be arbitrarily defined by the designer of the resource?
→ in this regard: Should we clearly define the difference between a Well and a Trough?
I am not certain about a clear definition distinction here yet.
I didn’t even consciously do that. I guess we should be consistent with other definitions and make it uppercase. On the other hand, other definitions were actually classes at first (a long, long time ago), so perhaps that convention does not really make sense and we should make everything else lowercase. (pep8)
agree. I also think “trough” is a little more specific than “reservoir”.
It does not have to be the case, you can have children (including wells and troughs) at any arbitrary location. Plate takes an ordered_items input dict, where ordered simply means there is a linear ordering to them, and create_ordered_items_2d is simply a convenience methods that creates a list of a list of items regularly spaced in a grid. But nothing prevents the user from passing their own dict.
I said this more so to clarify what people might reasonably expect. I think wellplates should generally be of the SLAS standard (including exceptions that maybe do not follow the spec exactly but are very similar at first sight. eg Eppendorf_96_wellplate_250ul_Vb).
To answer your question “Should we clearly define the difference between a Well and a Trough”: how about saying Wells are circular or square, and troughs may be rectangular but not square? Wells also have to be part of a plate (exclusion of square troughs that are stand-alone).
we should probably rename Porvair_24_wellplate_Vb to Porvair_24_troughplate_Vb:
Thanks for this @rickwierenga ! These are the reservoirs that we have. Tested it out today and we were able to successfully aspirate and dispense using the definition for the 12 channel.
A couple of questions and requests
Is it possible to use more than one pipette head in the same well? For the 12 channel, to move more than 1mL of liquid at a time, I want to use all 8 tips. But this results in an assertion error since # wells != # pipette heads
Would you be able to add nest_1_troughplate_195000uL_Vb? (NEST part 360103). This is equivalent to nest_1_reservoir_195ml defined for opentrons, but I am not sure how to get it to work with a Hamilton, and I imagine you also want to refactor it to the troughplate format. Here is the part, but the photo is actually wrong. Only Opentrons seems to have a correct photo: NEST 1-Well Reservoir, 195 mL (50 count) - Opentrons
Hi, Rick! I’m working with Adit on our Hamilton automation. I commented on the update on Github, but wanted to add here that I tested the 195000 uL trough and channels 0 and 1 did not go into the trough, but were attempting to aspirate at a greater y value than the edge of the trough.