PLR Workcell/Deck Transfer between Protocols

General
1

Hi everyone,

Does PyLabRobot currently support transferring deck layouts AND their state from protocol to protocol?

I am aware of the ability to store deck layouts in JSON format but I’m looking for a complete state transfer.

E.g.: after one automated Protocol (aP1) is run I might want to instantly chain another aP2 via a supervisor script.
aP2 should not require human input but have the deck transferred from aP1 in the state it was left (which changes based on variable aP1 inputs).
This design enables flexible working on each aP and quick decision making of whether to execute aP1 or aP2 or (aP1 followed by aP2).

PLR is designed to support this from a workcell management perspective due to its naming system.
But I’m not sure how workcell state is transferred?

2

the tip and volume tracker state for a resource with all its children can be serialized using

resource.serialize_all_state

(or just Resource.serialize_state for a single resource)

3

Does this mean we can just serialise an instance of LiquidHandler directly at the end of aP1, load it in aP2 and give the new liquid handler the loaded liquid handler as… It’s deck argument?

Or can it be directly loaded as the liquid handler instance, just followed by a new lh.setup() call to create the connection to the machine again?

Would Python’s good old pickle do the same?

4

to do an entire lh not just the resource tree you also have to serialize the state of the head (LH.serialize_state, LH.load_state - I now see the 96 head is not supported in this, I will fix that)

I don’t know what " liquid handler the loaded liquid handler as… It’s deck argument" means. the deck argument has to be a deck. in ap2 you can load the deck from a file that was stored in ap1, first the resource tree then the state.

I think so

1 Like
5

I think the confusion behind the question arises from this:

Both aPs require a liquid handler instance.
LiquidHandler, as a frontend, is a combination of a machine class and a resource class.

I cann now see how the resource (and all subchildren) can be transferred from the old to the new aP (exactly as the old aP has left it behind).
But the actual connection to the machine would still need to be re-established?

6

the machine connection (usb connection) is owned by the python process on your computer that is running

if you stop this process then yes you have to reopen it

if you want to keep it you have to keep the process running

perhaps with the new server ability @koeng is working on, we can have a single process running on the computer and all client scripts just sending commands there

until that’s ready you’d have to find another way to keep the python process running. how this will work depends on your specific setup

1 Like
7

that’s the goal

2 Likes
8

one can use (for example) a different flask server to maintain constant connection to each individual backend.

the frontend client for the integrated workcell could load deck according to spec, run process A/B/C if resources are available, and return all plates to cytomat/trash when finished without interrupting the python process(es) responsible for communicating directly with instrument backends

i am working up the clarity of thought to build this type of functionality directly into pylabrobot… in the ideal world, the end-user should not have to think very hard to get their system spawning/cleaning up workcell tasks and persisting state continuously