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?