This tutorial assumes you know the traditional OctoPrint deployment process and that both your SBC and server are ready to work with (has internet connection and the utility
In order to establish communication between OctoPrint and the 3D printer, the usual serial connection that is typically found in these deployments should be tunnelled through an internet protocol. The endpoints of the tunnel will be the server itself, and the SBC, that will remain connected to the printer, as usual.
In this example architecture the SBC is connected to the 3D printer through an USB-to-TTL converter, and using the RX/TX lines. This is done to prevent a hardware reset in the event of a (presummably frequent) disconnection.
In the server, assumed to have a GNU/Linux OS, a working instance of OctoPrint should be in place. Please, read the installation instructions in order to know how to do so. Also the
socat utility must be installed. Very possibly, it is already packaged for your distro, so you just have to install it like any other software.
The server endpoint of the tunnel is setup with the following socat command:
socat PTY,raw,echo=0,link=/dev/ttyUSB0 tcp-listen:8888,reuseaddr,fork
That will create a new pseudoterminal, and create the link
/dev/ttyUSB0, pointing to it. This link name can only be used if there is no USB serial device connected to the server. Probably, something like
/dev/ttyVUSB0 can be used, and can be detected by OctoPrint after adding an additional serial port pattern (OctoPrint Settings -> Serial Connection -> General -> Additional serial ports), but hasn't been tested yet.
Of course, any other port (instead of the 8888) can be used.
Very probably the above command should be run with
sudo, and the default permissions of the pseudoterminal won't let the OctoPrint instance use it, so additional
chmod tuning would be required.
Finally, the OctoPrint server can be launched. The new (link to) device should appear in the Connection -> Serial Port dropdown. If not, check that the name of the link is correct, or add the appropriate serial port pattern (as explained before) so that it won't get filtered out from that menu.
The client will be the SBC, and must have the USB-to-TTL appropriately connected, both to the SBC (through USB) and to the 3D printer (through TX/RX wires). A direct USB connection to the 3D printer is, theoretically possible, but wasn't tested because of the multiple hardware resets that can occur, even in the middle of a print.
The client should execute the following command:
socat /dev/ttyUSB0,raw,echo=0,b115200 tcp:123.234.345.12:8888
Setting the IP and the port to the appropriate values. Also, depending on how the SBC is connected to the printer, chances are that the device is not
/dev/ttyUSB0, or that the speed is not 115200 baudios. In that case, also tweak them to the appropriate values.
This architecture won't let you print from OctoPrint (this is what would happen. The hand is there only to prove that it's not a video issue), so your only option is to print from the SD card. Uploading files to the SD is also painfully slow.
A direct USB connection from the SBC to the 3D printer (like it's typically found in any OctoPrint deployment should be avoided, since the network connection could be very unreliable, causing 3D printer resets at any moment. ALWAYS KEEP AN EYE ON THE PRINTER.
If you're using an USB-to-TTL to connect the SBC and the printer, like it's recommended, in the event of a disconnection, the printer should keep printing (since the GCode is fed from the SD card), but OctoPrint won't recognize that the printer is printing, so it would show the state "Operational" until the print finishes and another one is issued. Nevertheless, the terminal and thermal monitoring works as expected after a reconnection.
This tutorial is strongly based on this Unix & Linux StackExchange thread. This setting wouldn't have been possible without this information.
"We do what we must, because we can"
Daniel. We're done here.