High level pylabrobot resource library (PLR-RL) discussion

resources
5

we are in agreement that in the future to make our resource library useful for other software we need to have a separate database.

for PLR users right now, i would say it’s close to maximally useful and having it in a separate database doesn’t change anything. if anything, it will make development more painful. (versioning separately is a smart idea.)

do you envision yourself using PLR? or how would you want to use the information in the PLR RL? let’s talk specifics

you seem to be misunderstanding one specific piece:

No. If your database has information in sufficient detail (most labware libraries do not: they miss material_z_thickness), you can instantiate a Plate object at runtime.

await lh.setup() # protocol starts
info = get_plate_info()
plate = Plate(
  name="name",
  size_x=info["size_x"],
  ...
)

# assign plate to deck (at runtime)
lh.deck.assign_child_resource(plate, location=...)

# use it
await lh.aspirate(plate["A1"], ...)

alternatively if you want to go by plate name / part number (from the PLR RL):

await lh.setup() # protocol starts
info = get_plate_name()
if name == "cos_...":
  plate_creator_function = Cos...
elif name == "thermo_...":
  plate_creator_function = TF...
else:
  raise UnknownPlate

plate = plate_creator_function(name=name)

# assign plate to deck (at runtime)
lh.deck.assign_child_resource(plate, location=...)

# use it
await lh.aspirate(plate["A1"], ...)

for this 2nd example, we can make some improvements eg being able to query by part number.

but ultimately it’s just python code. you can instantiate plates however you want. the PLR-RL is just a convenience but if you look closely you will see that every function returns an instance of the same general class. that means that in your script, as soon as you say plate = some_func() after that line runs it doesn’t matter which function or whatever created the Plate instance.

you can have your information in any database, and when the time comes to use it in a protocol create the PLR instance.

as far as i am aware, PLR is the only system which allows you to define your deck layout and plate types (for any device) at runtime.

again to emphasize: you can literally instantiate Plates or any other labware AT RUNTIME using information from anywhere. If you want have a nice scientist-facing UI, build it and just get the required plate information from there.

no “no new release, push to production, testing etc.” required, just dynamically create Plate instances

what does this mean?

curious what you think about this: Almost-equivalent plate naming convention

it would be good to zoom out a little bit. what are we discussing here? how plr can be useful to a specific use case you have / how to make plr useful for that? or the general vision for a future labware database?

1 Like