Add Pioreactor

[har1eyk]

The Pioreactor is a small-volume cultivation bioreactor that pairs well with automated liquid handling.

[rickwierenga]

do you happen to have a resource definition for this?

[har1eyk]

The Pioreactor is implemented as a skirted 1×1 Plate (PioreactorPlate) with a single circular well (A1) so it can be assigned to existing PlateHolders (e.g. Hamilton_MFX_plateholder_DWP_metal_tapped_10mm_3dprint).

Code: pylabrobot/resources/pioreactor/plates.py

[rickwierenga]

I think maybe we should make PlateHolder accept other resources then. It does not really make sense to index A1 into what is just a single container. I could also imagine Bioreactor (Resource) > Container as a child if people switch out the container frequently

[rickwierenga]

also in this case I was specifically asking about the adapter "This ANSI-compatible adapter allows the Pioreactor to be placed on the deck."

[rickwierenga]

why a Plate rather than a single Container instance?

[har1eyk]

I chose a skirted 1×1 Plate to stay within PLR’s existing deck/labware model. PlateHolders already expect Plates, collision/geometry logic is mature, and well addressing (A1) fits naturally.

While physically it’s a single vessel, modeling it as a Plate avoids adding special-case handling for a Container-like resource on the deck.

[rickwierenga]

#893 (comment)

[rickwierenga]

does it need a backend to work? is that something that would be valuable to include in PLR?

[har1eyk]

does it need a backend to work? is that something that would be valuable to include in PLR?

The resource definition itself does not require a PLR backend.

The Pioreactor already exposes its own control layer via HTTP API and job system. In this model, PLR acts purely as an orchestration layer rather than a hardware controller.

I’ve been successfully interfacing with the Pioreactor using simple API calls from PLR scripts (start/stop stirring, OD readings, logging events, etc.).

Conceptually this fits PLR’s existing pattern of integrating with externally-managed devices rather than introducing a new backend.

Longer-term, a lightweight Pioreactor backend could be valuable if deeper synchronization or tighter lifecycle management becomes desirable, but basic interoperability works well via the API alone.

[rickwierenga]

Conceptually this fits PLR’s existing pattern of integrating with externally-managed devices rather than introducing a new backend.

so far PLR does not have a pattern of using externally managed devices, this would be a first

why not add the backend for it? the api will be the same for everyone and then it'll just work out of the box