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

[har1eyk]

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

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

Rick, good question about Pioreactor-PLR backend.

From my perspective, the Pioreactor already functions as an externally managed system with its own control plane (HTTP API + job model). In that architecture, PLR naturally fits as an orchestration layer rather than a hardware controller.

Adding a full PLR backend is certainly possible, but it introduces a larger design commitment:

• lifecycle management (who owns device state?)
• configuration / discovery / auth
• synchronization semantics between PLR runs and Pioreactor jobs
• long-term API compatibility maintenance

For the current scope, the resource definition + API-level integration already provides stable interoperability without expanding PLR’s backend surface area.

That said, I do see value in a backend longer-term if deeper coupling or tighter state coordination becomes desirable. I’d just prefer to avoid baking that architectural decision into this PR.

Since this touches Pioreactor design philosophy directly, it may be useful to loop in its creator.

@CamDavidsonPilon, we would love your thoughts here. Specifically:

What do you think the relationship should be between Pioreactor and PLR?

[CamDavidsonPilon]

👋 this is interesting to see!

Here are my thoughts (as a non-experienced PLR user):

1. The API is converging to stability, but APIs still change often. We are still adding new features as well, so the core API continues to expand.
2. From a state-ownership POV, I think PLR shouldn't control Pioreactor's stirring, heating, optical density readings, aeration, experiments, etc, unless there is already precedent for such bioprocessing control with other devices.
3. We expose a UI that Pioreactor users have an existing workflow with. I don't expect them to wish to be removed from that. Users of the Pioreactor are focused on bio-processing, and want to use tools to improve that (i.e. use Pioreactor UI to control external hardware, not vice-versa)

However, with some initial support (this PR) in place, we may see more users adopt PLR + Pioreactor, and can decide on a direction later. WDYT?

[har1eyk]

Oh, man, two of my fave programmers/developers having a discussion about my PR. Am I dreaming?

Thanks for your thoughts, @CamDavidsonPilon . I agree, for right now, I think we get this PR in place and decide in the future what direction to take.

[BioCam]

I have already been on the fence about buying some Pioreactors (I've been burned by the Chi.Bios in the past).
With a PLR backend for them to facilitate their integration into bigger workcells and make their programming easier, I'd buy some today :)