Another topic related to the current one and part of this thread’s agenda (dev discussions on heaters, shakers and the like) as well:
Every machine requires two PLR definitions to make them usable, to my understanding:
- a physical /
Resource definition
- a control software module (the backend)
We are currently discussing the backend, how to establish control of machines (in this case the HHS) using PLR.
Controlling up to two devices directly plugged into a STAR(let) is already possible.
Now we are trying to figure out how to make it possible to control more than 2 machines of this type.
In parallel, I have been making Resource definitions for the HHS and the HHC and would like to brainstorm with you guys the most sensible ways to integrate them with PLR.
My proposal
We just integrated the MFXCarrier and MFXModule concepts into PLR (PR#77).
Machines like the HHS and HHC could, physically speaking, all be members of the MFXModule superset.
The benefit of this approach is that one person has to generate the physical definition and everyone in the world can instantly use the “site” on top of the machine straight away.
The alternative would be that these machines could all be simply defined as a Resource class. But then any assignment of a child would have to be made explicitly using location=Coordinate(x,y,z) - every time anew when the deck is generated.
This leaves a lot of room for errors and I therefore recommend we generate these physical definitions using the MFXModule as the base class.
The physical definition for use of the HHS could therefore look like this:
################## 2. Machine modules ##################
def Hamilton_HS(name: str) -> MFXModule:
""" Hamilton cat. no.: 199034
Hamilton Heater Shaker with 3.0mm shaking orbit and flat
bottom adapter (shaking speed: 100 -2400 rpm, temperature
control: RT+5°C - 105°C, max. loading: 300mm)
"""
return MFXModule(
name=name,
size_x=145.5,
size_y=104.0,
size_z=184.1-8.0-100, # includes HHS' carrier_site_skirt_height=2.85mm
# probe height - carrier_height - deck_height
child_resource_location=Coordinate(9.4, 8.55, 184.1-8.0-100)
# site_size_x=127.0,
# site_size_y=86.0,
model="Hamilton_HS"
)
→ Note:
This definition is still very flexible. These devices were made to be screwed into a MFXCarrier, hence I believe making them members of the PLR superset of MFXModules makes sense to me, and I’d assume that the vast majority of the time this would be how they are used, i.e. screwed onto a MFXCarrier.
However, this definition still allows PLR users to define them anywhere:
- maybe someone wants to screw them into a liquid_handler deck directly
- maybe someone wants to just place the Hamilton_HS on a bench and programme an arm to place labware on them (think massive heater-shaker arrays)
…the important thing is to not limit usability.
Please also provide feedback on the naming. I am not attached to “Hamilton_HS”, I just found it a bit more descriptive than “HHS” (and generally try to find a balance between avoiding acronyms as much as possible and not having to write out lengthy descriptions).
Please also voice your opinion on how to best connect the naming of…
- the PLR control software module (the backend)
with
- the naming of the physical definition of these smaller machines.
)