No, I have never seen this orange plate_adapter before.
@dkone Is this the deck setup you use for the images you’ve shown?
If yes, then I can help you fix the defining plate adapter issue because you are using the wrong plate_adapter definition for your specific, new-to-PLR plate_adapter.
This is the Hamilton plate adapter from the definition you have posted above. It is size_x=110.0 and size_y=75.0, i.e. not SLAS/ANSI 1-2004 (R2012), i.e. x=127.76 mm x y=85.48 mm - which your orange, plastic plate_adapter appears to be.
If you have used this definition, and you set it not into the x-y center of the plate_site but to the plate_site origin, i.e. front-left-bottom,
(which is what pcr_plt_car_0[0] = pcr_adapter_00 = Hamilton_96_adapter_188182('pcr_adapter_00') does)
then this explains why your channels move too far to the left.
Another example of a plate_adapter (to showcase a small fraction of the diversity of plate_adapters) that I hope to add to the PLR Resource Library soon is
The 96-wellplate aluminium adapter does have SLAS/ANSI 1-2004 footprint in this case.
And this seems a lot closer to the orange, plastic plate_adapter in your images.
Do you have a manufacturer catalogue number of your plate_adapter?
With that we might be able to find some engineering drawings for it to base a new definition on.
I am using a PCR tube rack which fits really well onto the plate carrier.
For the code I don’t define an adapter. I use plt_car[1] = Thermo_FS_96_wellplate_300ul_Vb_semi_skirted(name='source') It was working fine a month ago. Currently I am creating a new Thermo Fisher Scientific plate.
I can provide dimensions of the adapter.
Problem 1: Eppendorf_96_wellplate_250ul_Vb → link to docs
This plate has a footprint of 123x81 mm^2, i.e. also not ANSI/SLAS 1-2004 of 127.76x85.48 mm^2.
But the plate_holder/_site on a Hamilton carrier is ANSI/SLAS 1-2004 of 127.76x85.48 mm^2.
You assigned 123x81 mm^2 to the front-left-bottom of the carrier plate_holder → everything is shifted to the left in your defintion as a result, explaining why your tips landed around the black wire.
Problem 2:
Using a semi-skirted plate without a plate_adapter. @rickwierenga, I think we should raise an error when people assign semi-skirted and non-skirted plates to anything else but a PlateAdapter().
Physically speaking these plates cannot simple sit on a flat surface by themselves… a gust of wind will change their x-y position.
This also causes issues with your well_cavity_bottom → physically speaking your wells are now raised in the z-dimension, but your machine doesn’t know that because it is not being told that the wellplate sits on top of a plate_adapter with a plate_adapter.plate_z_offset associated with the plate-plate_adapter combo.
Solution: model reality
Generate new plate definition
Generate new plate_adapter definition
Measure specific plate-plate_adapter plate_z_offset
I will make a lot of infographics next week to give some visual guidance
Thank you for such a detailed response @CamilloMoschner!
I am working on creating and testing new plate. I might need help with _compute_height_from_volume_Thermo_FS_96_wellplate_300ul_Vb_semi_skirted
The orange adapter is a standard PCR tube rack. Could we add it to the resources? I am also thinking that people could use standard PCR strip tubes on this adapter?
Note to avoid confusion (poka-yoke):
ANSI/SLAS 1-2004 of 127.76x85.48 mm^2 is the exact footprint dimensions as defined by this plate standard.
Most machines, including our favs from Hamilton, do not allow firmware commands with a precision exceeding 0.1mm.
As a result, you might see some plate definitions as 127.8x85.5 mm^2, rounded to the closest 0.1 mm.
I tend to still give the precise 127.76x85.48 mm^2 for completeness sake, and because PLR will automatically round to the closest 0.1 mm anyway before sending commands to your machine.
Plus, we might use more precise machines in the future of PLR
if it is a plate, we check that it is skirted. for other items we don’t check since the user may have unpredictable deck setups and I think we shouldn’t introduce artificial constraints.
@dkone, what would you like to use the height computation for, is this for liquid level following during aspiration/dispensation?
Yes, absolutely!
I recommend having a look at the Hamilton plate_adapter definition, copying it, and modifying it for your new plate_adapters geometry.
Then we just need to know the manufacturer and part number to add it to the PLR Resource Library.
haha yeah
I have done the exact same thing with Opentrons OT-2 API a long time ago:
In PLR there are multiple ways we can do this but I still think the way I did it back then is the most robust.
Once this plate_adapter has been added to the PLR Resource Library you can just use essentially any plate definition as a proxy for your strip-tubes, and just adjust the plate_adapter.plate_z_offset to what you need it to be.
This will allow you to use all positions very quickly.
(The alternative would be to model the orange thing not as a PlateAdapter but as a TubeRack. But once you do that you cannot use a plate on it anymore [I believe]. Therefore I recommend generating a PlateAdapter definition for it, and using a plate definition for the strip-tubes)
