Atomic Pi - Can it run Octoprint?

What is the problem?

Not a problem - just a question.
I have an Atomic Pi and wondered if anyone on this forum had managed to get Octoprint running on it. I would expect the performance to be better than Raspberry Pi 4, but I don't know whether there would be issues in getting OctoPrint to run or whether Raspbian could be installed successfully or whether the APi Hardware would be suspported and configure correctly..

What did you already try to solve it?

Posted here :slight_smile:

Complete Logs

octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support! Not log excerpts, complete logs.)


Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible


1 Like

Should run fine - but you have to install octoprint yourself.
I would suggest you use debian as OS and then go with this guide:

Just ignore the pi related things and use your user instead.

Hi, and thank you for your reply. I am currently running the Octopi image on a Raspberry Pi model 4. If I can get the Atomic Pi working in it’s place I can find other things to do with the RP4. The Raspberry runs OK but I’m still a bit peeved that the actual print time is generally about double that estimated by S3D. There might be another cause but I’m keen to give the APi a shot.

Thanks again for your reply. I’ll certainly follow your advice.


The estimated print time from S3D and the actual print time taking 3 times longer has nothing to do with Octoprint. It doesn't modify the GCODE that S3D, or any slicer, generates.if the pi was an issue, you would see timeouts in the communications and your print would stop completely

1 Like

I didn’t say that I thought the problem was Octoprint, rather the processing power and buffering capabilities of the hardware, i.e the Raspberry Pi. The Pi 4 works better than the Pi 3a I was using previously. I expect the Atomic Pi to be better.

Same answer applies. if you aren't seeing timeouts between the pi and printer, a faster or larger buffer isn't going to speed anything up at all. USB is a serial connection. The Pi sends until the printer says wait, I'm full. the printer is printing away. When it's buffer can hold more GCODE, it tells the pi to send more and the cycle repeats. If the pi can't send the data fast enough before the printers buffer empties completely, then you will get a timeout, or if no timeout, the printer will stop for a second until it gets more data in it's buffer. I have an Atomic Pi here that I have been playing with for different things to see what it is actually good for. I have to say my Pi4's surpass it's performance in every way. AND they are smaller, take less power, generate less heat etc.

I'm also looking at putting the Atomic Pi to work as an Octoprint server. Its my first 3d printer ( Creality CR6 SE), so both printing and octoprint are a new adventure.

My reason for using the A-Pi is just that I have several sitting on the shelf, and figure I'd put one to work. No Pi-4s on hand, so the RPi option would be a 3B...with based on @5ft24's comments, make me wonder if the Pi-3 may still do better. My sense is, getting the APi running Octoprint may be a bit more of a science project than just going with OctoPi and the ready-made image.

If you have an RPi 3B available, I'd say use that with OctoPi. That's what I use and am very happy with it.

It doesn't modify the GCODE that S3D, or any slicer, generates.if the pi was an issue, you would see timeouts in the communications and your print would stop completely

Thank you. I appreciate that gcode is not modified (except by some plug-ins) but I still find that, even with a Pi 4a, there is still stuttering when circles are being printed. I am also concerned about why S3D printing time estimates are usually almost half of the actual print time. I don’t know whether that is a slicer issuer of whether print time is being reduced by the hardware, i.e the Pi. Can the buffer size be increased. If so, how?

Stuttering when circles are being printed is usually because the circle has been turned into lots and lots of short linear moves (GCode commands). A bigger buffer might mitigate some smaller circular sections, but larger ones will still suffer.

The most dramatic, slicer independent solution, is to use the OctoPrint plugin Arc-Welder assuming your printer can handle G2/G3 commands.

1 Like

Thanks b-morgan. I'll check that out.