Updating PLR API for machine interfaces discussion

dev discussion
60

yes strongly agreed.

maybe we should even have this on the io objects? This way backends do not have to think about it in the base case (although we might still want that if there are relevant protocol level locks such as write + read being matched.)

io.Socket and InhecoSiLAInterface actually already have this, as well as the InhecoIncubatorShakerStackBackend.

Locks are actually already needed right now, strictly speaking, since people could theoretically call two backend methods together even if they are in one object right now.

No lock needed there,

actually since FTDI is a serial protocol, and the cytation has a “serial” protocol on top of that (write + read always match), we should actually have locks there…

agree, and this is actually also the case for byonoy plate readers. They either do only luminescence or absorbance. PlateReader as it exists right now definitely can’t be in this next version if we wanna do it right.

We have to break up plate reader into separate classes such as AbsorbanceReader/AbsorbanceReaderBackend etc, exactly as you propose.

What is Protocol in your draft, is simply ABC in the current code (the current abstract backends also declare capabilities - the problem is that these are not nicely defined, like lh containing arm stuff and them not being composable)

as for

class ByonoyDriver:                          # no PlateReaderBackend parent
    absorbance = SignalR(unit="OD")          # honest declaration

    async def read_absorbance(self, plate, wavelength): ...
    # read_fluorescence simply does not exist

Why not:

class ByonoyDriver(CanReadAbsorbance):

or

class ByonoyDriver(AbsorbanceReaderBackend):

temperature = SignalR

This is very interesting. I hadn’t considered what we would do for thermometers, I only thought about temperature controllers.

I think something like device.temperature_sensor.get() makes a lot of sense…

one thing I am not 100% decided on is whether we should have a devices folder and then also resources folder separately? It is easy to imagine resources also being a universal folder like capabilities and the actual definitions just going into the vendor module:

pylabrobot/
  capabilities/
    ...
  resources/
    ...
  hamilton/
    star/
      ...
    labware/
      ...

plate_reading/ ← COMPOSITE (existing, unchanged)

why keep this? why wouldn’t composition be done at the Device layer at the end?

1 Like