How to aspirate with cLLD on the Hamilton

General
1

I can’t seem to understand how to aspirate with cLLD? My Venus brain has cLLD tied to the aspirate command. Is this not the case in pylabRobot?

Not seeing a cLLD parameter here:

2

yes it’s tied to the aspirate command, but it’s a backend kwarg.
LiquidHandler.aspirate is the universal command, and cLLD is not a part of that

see docs here:

3

Haha idk how I missed that, was searching “cLLD” “pLLD” but those don’t appear on that page. My bad.

Follow up question, I see immersion depth there which is awesome. Is there liquid following?

4

good feedback actually, I have added those words so search terms work in mention pLLD and cLLD in star lld docs · PyLabRobot/pylabrobot@8023ff3 · GitHub

added to docs: add liquid following to star lld doc · PyLabRobot/pylabrobot@65737f0 · GitHub

await lh.aspirate(
  [tube],
  vols=[300],
  lld_mode=[STARBackend.LLDMode.GAMMA],
  surface_following_distance=[10],  # 10mm
)
2 Likes
5

Thoughts on making this automatic similar to Hamilton Venus? Hamilton uses the container volume to set how far to move I’m pretty sure. I could write a function to calc this for me before aspiration, jw why not include it for pylabrobot

6

VENUS uses a ballpark equation to do this.
It is very imprecise with complex container geometries in my experience.

So we added real-to-reality volume to height and height to volume calculators.

E.g.:

First plate uses older generation PLR functions based on knowledge of the container geometry.

Second example: we learned that container geometries can be highly irregular. So we perform a polynomial fit based on empirical data (is this “AI” because of a regression :person_shrugging:t2:).

Downside: we have to generate these functions for every plate separately. It is part of what makes the PLR Resource Library so powerful :slight_smile:

1 Like
7

:brain:

yes, would be an awesome feature. we can implement it based on the height<>volume functions camillo described, where they are available. (it will raise an error for resources where they are not defined)

happy to add this

8

Yes sometimes you end up tuning the virtual definition to the returned liquid heights. Aka ball park the definition, then iterate over a plate checking it is returning the correct volume for all ranges. I’d say though for normal plates its a good enough ballpark.

That would be sweet. Sorry as I flesh out all the features we currently have in our Venus protocols I’ll probs be requesting a lot. Happy to try to push some stuff too

9

camillo will tell you this is poor design. why is the plate different day to day? we can just have one good definition, in PLR, shared by everyone. fine tuning everything to every protocol is “a house of cards”, you can never build moat (I wholeheartedly agree with this)

?

this is super helpful feedback! keep it coming!

2 Likes
10

Not different day to day. We just empirically have had to test the volume at times to make it match. You just can’t model some geometry’s well enough in Venus and have to work with the cards you’re given.

11

right exactly, but fundamentally it should just be an attribute of a particular plate right? ie you should only have to go through this process once per plate

1 Like
12

Yep.

1 Like
13

…I know this Dutch guy who invented this “card creation engine”… You never have to deal with the cards you’re given anymore - you can just make your own cards :fire:

1 Like