Plr protobuf

prototyped making a remote liquidhandler/starbackend/resource, such that you can access pylabrobot remotely. It works, but definitely can be improved.

lh = RemoteLiquidHandler.connect(f"http://127.0.0.1:{_LH_PORT}")

await lh.pick_up_tips(["tip_rack_01_tipspot_A1"])
await lh.aspirate(["plate_01_well_A1"], vols=[100])
await lh.dispense(["plate_01_well_A2"], vols=[100])
await lh.return_tips()

This is useful for me, because you can implement the LiquidHandler interface and then basically just use the exact functions of PLR. Allows intercepting calls to do things like liquid tracking and serialization of full state.

1 Like

based

hope to merge something like that into PLR after Updating PLR API for machine interfaces discussion

I’ve learned a few things while building this, which I’ll briefly put:

  1. the protobuf definitions are the most important. With a good interface description, generation works great.
  2. you can autonomously test by creating fake serial backends and then check RemoteClient vs Local. This is more useful than the other tests it produces and usually guarantees, to some degree, that the interfaces are functionally compatible
  3. the hardest part is creating the nice interface for humans. While client/server can be generated from protobuf, you need to implement server (can be done autonomously by making serial-comparisons), and you need to make sure the user-facing interface is correct. This takes a shit ton of boiler plate on top of the autogenerated client, but is very easy to do. plr-interace → client-interface -> server -> serial
1 Like