Hamilton seems to sell separate DWP carriers vs MTP carriers. Is there any difference between then - can deep well plates be used on the MTP carrier and vice versa?
The only thing I’m able to gather is that they may have different heights - wondering how this is represented in PLR. They both seem to be PLT_CAR_L5AC_A00 but I could be wrong (the image is blurry on the website).
no difference in terms of which plate can be used with them afaik
in PLR, there would be a difference: the PlateHolder (introduced today, previously known as CarrierSite) location will be higher or lower.
Could these carriers be PLT_CAR_L5MD_A00 and PLT_CAR_L5AC_A00? They are the most common in my experience. If you get them I am guessing they will have stickers with the identifier, or worst case scenario we can match by measurement.
Hamilton Microlab 182090 Deepwell Plate Carrier PLT-CAR-L5AC for sale online | eBay supports this hypothesis
ah, easily confirmed if you look at the url you shared and the serial numbers in my picture
This looks correct, thank you!
Regarding PlateHolder, is my understanding correct that e.g. carrier[0] would be of type PlateHolder?
Correct
I can confirm what Rick said: there is no difference in terms of what plates can be placed upon these two carriers, the plate_holders (previously plate_sites) are the same.
I deducted that this distinction between “DWP” vs “MTP” only stems from the average z_height of the plates placed upon it.
Why? Because Hamilton’s ancient 1D barcode readers can only scan at a fixed z_height.
To get short and tall wellplates to that height, it seems they had to invent the same carrier twice, once for “DWP” and once for “MTP” plates.
(though neither “DWP” nor “MTP” I could actually see defined, i.e. they are quite arbitrary names and different people might have very different opinions on what is what - hence why PLR [and Opentrons] stays away from these terms and calls everything a wellplate 
)
Almost forgot:
Another reason for the existence of these two heights (besides barcode reading - some people might not have a fixed or belt-movable 1D or 2D barcode reader) is that a plate of >30-40mm size_z placed on an “MTP” carrier will have the top of that tall plate protrude above the minimal_safety_height of 245mm → crash risk (e.g. pipettes trying to move above it will crash into the plate)
Easily remedied in PLR by modifying the STAR.traverse_height()
My recommendation / actionable knowledge:
Buy the “DWP” carrier if you have to choose (carriers are very expensive after all).
Less thinking and post-purchase hassle to programme. Also gives the most flexibility in terms of utilising the same carrier for different applications.
If you do have to use 1D barcodes with a short plate after that I finally have a reason to integrate the firmware command that takes a plate and moves it up and down in front of the barcode reader until it finds the barcode… It’s a standard Hamilton command but I haven’t had a use case for it so haven’t exposed it to PLR yet.
If you buy a MFX Carrier instead you’ll find the exact same decision has to be made with the plate_holder mfx modules.
I’d again recommend ordering the “DWP” MFX module for the same reasons.
why?
Because you have to keep in mind…
If the total z_height of plate + carrier goes above 245
AND
If use 1000up tip
AND
1000ul tip is used for that plate OR traverses over that plate
→ modify traverse height temporarily
Permanent modification will lead to other problems 
sounds like something we can easily fix in PLR by querying deck.get_highest_known_position, but that obviously requires that the user tells PLR about their deck setup accurately. I will agree with you that the dwp will be safer by default
Yeah, there is definitely a code solution, as usual.
But I think it would likely be a decorator (we could call check_crash_potential) that has to be added to every machine command that leads to a movement of objects in the machine (and I mean every…).
E.g.
@check_crash_potential
def aspirate(...)
@check_crash_potential
def move_resource(...)
@check_crash_potential
def move_channel_in_x(...)
This would need a more advanced understanding of the - as you mentioned correctly defined - deck layout, and trace a 3-dimensional path of the movement and identify whether that path crosses a known object volume in the deck.
I’ve got a couple of ideas of how we could build this - i.e. the “master” crash safety feature: e.g. a tensor model of the 4D deck space (x,y,z, time).
Then it becomes actually pretty straightforward.
But we’d need to figure out the granularity of the 4D tensor, and how to generate, read and write to it efficiently; it can become very computationally intensive very quickly - I tried for one afternoon as an exploration task 
.
It is a big project, so I would like PLR to mature a bit more before heading into it
Also, we should probably make this a separate thread if we wanted to discuss it some more.