Modeling plate reading capabilities

[rickwierenga]

@hazlamshamin

One question is, how are we going to handle a machine that support many classes? Are we going to completely separate the backends, or will this be under capabilities for PLR v2, ie machine.frontend_attribute.capability, eg tecan_infinite.absorbance_reader.read_absorbance?

second option, different attributes

It will be possible for what is currently backends, will be drivers to implement multiple “capability backends”, but they can also be separate objects that then point to the driver.

See this post for more info: Updating PLR API for machine interfaces discussion - #62 by rickwierenga

@hazlamshamin

So I believe it should be in standard.py. I partially agree that we could just handle the time series on the frontend, however using your example with the thermocycler, certain microplate readers might also do planning, mainly calibration, for the whole time series.

whether something exists in standard.py is just a question of whether we want backends to support it. In this case you and @vcjdeboer have made convincing arguments that time series are an atomic command, not just a loop on the client side.

@hazlamshamin

For more transparency, I think it is better to return both the frontend and the backend read time, so developers can use these data however they want to analyse, and less pain to standardise strictly.

why is frontend/client read time important? assuming backend here means machine reported time for each measurement.

@hazlamshamin

The streaming is feasible too I think, depending on backend (tecan infinite allows it, but currently we do pooling for multiple wells. if streaming is enabled, this can be an argument, like stream=True,

I was thinking two separate methods for stream/read. Backend only does streaming so

class AbsorbanceReaderBackend:
  async def stream_absorbance(self) -> AsyncGenerator[dict, None]: ...

and on the front end:

class AbsorbanceReader:
  async def stream_absorbance(self) -> AsyncGenerator[dict, None]: ...
  async def read_absorbance(self) -> List[dict]:
    all_data = []
    async for data in pr.stream():
      all_data.append(data)
    return data

Changing the return type based on a parameter is ugly.

@hazlamshamin

Additionally for time series, we usually do shaking and temperature control using the machine. How are we going to model these? Will the microplate reader (any 3 class) also be a HeaterShaker or an Incubator?

Mostly a topic for the main architecture thread, but will answer briefly here. The idea is the Device (object user creates) will orchestrate different capabilities, so

class TecanInfinite:
  def __init__(self, ...):
    self.driver = TecanInfiniteDriver(...)
    self.absorbance_reader = AbsorbanceReader(backend=InfiniteAbsorbance(driver=self.driver))
    self.temperature_controller = TemperatureController(backend=InfiniteTemperatureController(driver=self.driver))
    self.shaker = Shaker(backend=InfiniteShaker(driver=self.driver))

The capabilities are universal, and mimic the existing front/backend pattern. In this specific example I assume we have different InfiniteAbsorbance, InfiniteTemperatureController, InfiniteShaker objects (I assume we want this for big backends), but we can also have TecanInfiniteDriver implement AbsorbanceReaderBackend etc. directly.