PLR Compatibility for Machines That Require an Intermediate Control App

[hazlamshamin]

I have a question about devices that do not expose a serial port.

Some devices, especially machines with their own built-in GUI, do not expose a serial port or any obvious external control interface. I understand that if a device does not expose any controllable interface at all, there is not much we can do.

But I recently came across a machine that does not have a serial port, but still has a USB port for data transfer and can connect to the internet. Basically, the machine has its own Windows computer inside it, and the controller app is installed on that Windows system. We can still access and control this “computer,” including using its terminal. It just seems that the only practical way for bidirectional communication is through LAN or the internet. We can also understand how the OEM controller app works since we can go through its program files including the DLL.

So I am thinking the best-effort approach would be to create something that makes the machine expose an API to the local network, which would allow an external desktop to control it from outside.

But this would look more like:

User ↔ Intermediate app for API exposure ↔ Firmware API ↔ Machine movements

Instead of the usual direct PLR model:

User ↔ Firmware API ↔ Machine movements

I have no idea if this reverse-engineering would eventually work or not. But, would PLR still accept this kind of setup, since it may involve installing an intermediate app inside the machine?

[mr.hyde]

@hazlamshamin

But I recently came across a machine that does not have a serial port, but still has a USB port for data transfer and can connect to the internet. Basically, the machine has its own Windows computer inside it, and the controller app is installed on that Windows system. We can still access and control this “computer,” including using its terminal. It just seems that the only practical way for bidirectional communication is through LAN or the internet. We can also understand how the OEM controller app works since we can go through its program files including the DLL.

Add Electroporation capability and BTX Gemini X2 backend

amazing!

[hazlamshamin]

thanks! but the PR for the electroporator was not the “intermediate app” i’m referring in this post, just clarifying. the electroporator one was weird but it still can connect to a desktop therefore I can still control it via its OEM desktop API, though messy.

meanwhile in this post, i’m referring to different kind of machines where we cannot and communicate into it via serial port, so i’m thinking is, the only way might be make own intermediate app that expose its firmware API through LAN/Internet so can communicate with external client.

[rickwierenga]

I think it is important to separate the two things you are saying in your post clearly:

1. controlling machines without communication ports
2. servers for those machines

solving one does not necessarily solve the other, but (1) is required for (2)

in the case of the electroporator, that is kind of a lucky find since it allows this hack. but not all machines will be like that. You can easily imagine a machine that uses a microcontroller that’s entirely closed (besides hardware modifications), and you would be out of luck. I have seen people use automatic button pressers for these as well as programmable outlets.

For servers, that is something we plan to make for all PLR machines after the v1b1 refactoring is stable.

[rickwierenga]

if you run some kind of API on the device itself, I see that as one way of getting the machine working (so (1)) even if it doesn’t ordinarily have an api. It is essentially slightly modifying the software. the PF400 also needs this. It’s just how some machines are born. Case by case this can be entirely reasonable (and necessary), but generally speaking it’s best to just the existing communication as much as possible

[hazlamshamin]

Thanks for the clear separation,

@rickwierenga

For servers, that is something we plan to make for all PLR machines after the v1b1 refactoring is stable.

Can’t wait for that to happen.

For this post, I think I am more referring to a custom server as a way to solve (1): getting control of the machine in the first place. Not the server in (2), you are referring to, I think.

Let me clarify the machine setup a bit more. The machine I stumbled upon is a standalone machine with an integrated PC. It does not expose a serial port (unfortunately), but we can transfer files through USB-A, connect it to the internet/LAN, and access the Windows environment inside the machine.

See AI generated image of this kind of machine here https://drive.google.com/file/d/1XVU1FmlCt8gYj1kUg5AXhS5QWq3o-Ipq/view?usp=sharing (not sure why I can’t upload images here, it says “Processing upload” and never done).

So I was thinking about making a custom app that needs to be installed on the machine itself. This app would expose a local API server, allowing an outside client to control the machine over the network. This is mainly because the machine does not natively expose an HTTP API like the OT-2 does.

So my question is:

Would you recommend that this custom app/server should live in a separate repo, with clear warnings and disclaimers as appropriate, instead of being part of PLR directly?

Then the PLR backend could still be implemented in PLR, assuming the user has already installed the custom app on the machine. Something similar to how the OT-2 backend works:

OpentronsOT2Backend(host=“192.168.x.x”, port=31950)

So the architecture would be something like:

PLR client/backend ↔ custom API server installed on machine ↔ Firmware API (ie its existing communication) ↔ machine movement