Pi proxy for lightweight printing

I think it would be pretty awesome to move the heavy lifting to a bigger computer with the interface and compute. Then have a "proxy" using a raspberry pi as the interface.

  • gcode start; forward code
    ui -> server -> proxy -> printer -> move
    ...

  • camera -> server/octoprint

This would allow for pi zero's and such. I think this would be a pretty nice upgrade since everyone has a computer...and everyone who cares about octoprint has...conservatively 50 micro controllers.

I don't know the arch that the devs have settled on. This may be unrealistic.

You can run OctoPrint on whatever bigger computer you wish, and then use a browser installed on a pi zero with a display to access it.

One of the major reasons not to use a pi zero to run OctoPrint on is that using the Wifi affects the CPU, which causes underruns (stutters) while printing if the pi is used for serving gcode to the printer and providing updates and a webcam stream through wifi. You can use a pi zero as a webcam server if you want; you don't need octoprint running on it for that. OctoPrint itself does not handle the webcam..

@taybart, Maybe I'm confused but I believe OctoPi / OctoPrint IS the architecture you are proposing.

Modeling and slicing are done on a desktop or even a server on the local area network (LAN). A Raspberry Pi is connected to (each) printer (via USB) and to the LAN via WiFi or a wired ethernet connection. Any system on the LAN that can run a browser (Chrome, Firefox, Edge, etc) can control / monitor the printer from a browser.

The Gcode file produced on the desktop or server is transferred to OctoPrint using this web interface and the print can be started and monitored. Optionally, a camera can be connected to the RPi to provide for closer monitoring.

The only issue here is which Raspberry Pi models are appropriate for this task. Experience has shown that the RPi Zero is not sufficient. Not enough CPU capacity as it has only a single core and the network interface uses CPU power and can interfere with the USB connection (which also uses CPU power).

Can you elaborate with some detail as to why this is not what your are proposing?