I've been running on a B+ for 8 months without any problems at all. Pi is dedicated to the printer and only runs Octoprint. Memory usage is quite light and current load average is 0.17 while printing.
1 Like
You would be wasting money on something that is way overkill and wouldn't be utilized with a Pi4.
See also
1 Like
Obviously foosel knows best in this matter, but I'd also like to add that Pi4 might offer some benefit if you intend to slice files with the Pi because of the extra computing power. Keep in mind that Octoprint no longer has an imbedded slicer, though, so you'll be going off-road a bit to get it set up. I'd go with a Pi 3B if I were doing it all again.
I need the Pi4B with lots of RAM given the Kivy-heavy project I'm working on. OctoPrint by itself runs quite well on the 3B even while streaming the webcam.
And maybe as well for something "simple". I noticed on the 3B while printing (Prusa MK3S / MMU2S) that when uploading gcode (from PrusaSlicer via wifi), the printer GCODE buffer is emptied and the print slows down significantly for as long as the upload takes. Personally I would rather solve this by re-prioritizing the upload prio, so that the print works "normal" and the upload takes longer.
So: is this configurable?
and: would a Pi4B perform better in this situation?
I think not, because this issue is the calculation power of the (mostly 8 bit) printer board.
Also see here:
Thanks ewald_ikemann, for responding. I followed the link, but this might be about something else. my situation is: Octoprint printing fine, then I send a GCODE file (through the wifi) from the Prusa Slicer to the SD card of Octoprint. (The printer's SD card does not play any role here; I could even remove it without any problem).
The bottleneck could be in CPU, but that is not likely, or IO to the SD card in the Pi, from where Octoprint is printing and where the gcode file is written to.
As soon as the IO finishes, Octoprint continues printing (some other file obviously than the one sent by wifi) at normal speed. If I folow the printing through the graphical interface of Octoprint (where it shows the GCODe and how the head moves), you see how the buffer is emptied (progress at same position as the printerhead) and how the printerhead moves slowly, even stops.
also: It doesn't matter whether I send the GCODE file to the Raspberry filesystem (SD card of the Pi) using Prusa Slicer's "send file to Octoprint", or through drag and drop in the browser (PC file system initiatig GCODE file transfer.
Am I the only one seeing this? Streaming video all works great, even two camera's, which make me assume it is not so much CPU critical. And probably not wifi and USB. So is it indeed SD card IO?
I'm not quite sure if this is the result of an empty send buffer in OctoPrint.
For
- The actual hotend position often is not that position that is shown on the gcodeviewer (because of the buffering in OctoPrint and the printer)
- The slowing down most often is the result of very tiny movements that the hotend has to perform, mainly on fine structures (a resolve could be: https://github.com/FormerLurker/ArcWelderPlugin)
I assume you use SD cards of the faster speed class. Slow cards can speed down IO.
And during print, there is not that much SD card IO: Reading codelines, writing logs. Even with enabled serial.log I did not notice a slowdown that maybe caused by IO.
BTW: When I try to send a file from PrusaSlicer to OctoPrint during printing, the transmission is denied.
Blockquote 1. The actual hotend position often is not that position that is shown on the gcodeviewer (because of the buffering in OctoPrint and the printer) 2. The slowing down most often is the result of very tiny movements that the hotend has to perform, mainly on fine structures
Precisely that! If I send the file when I have many "straight" lines (like the first layer), the effect is less noticeable (but still present), because there are fewer GCODE commands required to keep the head moving.
It is interesting that you cannot send files to Octoprint while printing. I can, but the processing of the files (to show printtimes, the filament lengths etc) is deferred till until the print is stopped. Can you send a file from your PC with drag-and-drop into the left part of the octoprint browser? That has the same effect with me. If that is also prevented for you, it must be a setting somewhere that I have wrongly set, compared to you. It would explain why few people notice it!
Further:
With the serial line logging, the SD-card IO is proportional to the GCODE commands and printing progress. When sending a GCODE file, it sends many IO to the SD card in bulk, independent of the printing speed. That could make a difference!
It's times ago I moved the gcode files from the file browser to the WEB GUI of OctoPrint and honestly I can't remember if this was possible during print.
Maybe the denying of sending a file with PrusaSlicer is in option in the API connection.
Sure, file read and write managed by the OS and usually it's done in block access to the medium. The block is stored in the ram from and to where the data is flowing.
On the other hand, a Pi 4 with 4 or 8 GB of RAM could run a "RAM Floppy" (nice term from the older days 
). Data during print is stored there up to the end and then saved to the SD card.
RAM Disk, yeah, remember hacking the Atari 400 to reserve 2048 bytes of precious memory for RAM disk? Those were the times, that you would store some screen bytes in memory and retrieve them in the HBLANK delay (6 opcodes or so) to set the color palet differently per line...
I will try and do something similar, I got an SSD from an old laptop and I have purchased an USB interface, so should be able to mount a fast file system part for those GCODE files, lets see (and look for that API setting),
Thanks for the inspiration!!!
1 Like
Not sure if related but there were several people on Reddit complaining that gcode viewer recently was not keeping up with the print. They didn’t mention doing uploads, and I forget what printers they were using. But they were unsure when it started loosing track. I don’t know if they ever raised an issue.
-- Off Topic On ---
That's a reason I don't like Reddit: People complaining about everything instead of using the provided forums of the product to get certified information. Sometimes they know it even better that the folks who produce the stuff.
--- Off Topic Off ---
2 Likes
--- Rant on ---
That's something I don't like about The Internetâ„¢ in general, it's not just limited to Reddit. Complaining about something somewhere on some obscure forum, but not bothering to actually reporting it to the official places so that it can be improved on.
In the specific case of the GCODE viewer mentioned above - known issue, excessively discussed here and I even wrote a plugin that provides a workaround until 1.4.1 is released. Of course, you won't learn about that in some echo chamber on Reddit or a Facebook group but will have to actually go to the official community and use the search once:
--- Rant off ---
1 Like
Isn't in the rpi3 the network on the same bus as the usb-port? (or is this only for wired nedwork?)
Maybe the network traffic competes with the USB-serial for transfer capacity.
Semi off topic.
I probably shouldn’t have said ‘complaining’ , asking for ideas would be better. But some people only ever use Reddit forums, other google groups or Facebook etc. People often find the official forums intimidating and just lurk. Personally I still prefer usenet...
The Raspberry Pi Foundation seemed to be cutting corners on the USB bus hardware on the Pi3B and earlier models. They're starting to invest more money for the 3B+, 4B and such, moving away from ganged bus controllers. But you can power down all network and USB controllers with one toggle in the software if you know what you're doing. (It's both wifi and ETH.)
I scratch my head that there's seemingly a full effort to get support on Reddit when there's a forum here. I'm often directing them here.
I use a 32MB RAM disk on my 3B/4B Pi computers for some things. It works quite well and lowers the microSD thrashing.
Keep in mind that simply pushing new gcode files to the OctoPrint instance triggers an analysis phase so it's not just network activity that's occurring.
Pushing from Prusa -> Pi -> SD card on the printer's controller board necessarily uses the same USB serial connection that's streaming the print job, right? I personally would never do this during a print job. The firmware is already working like crazy to manage its receive buffer and the RAM is super-limited over on that side. I would not complicate things by further taxing that RAM to now buffer an SD I/O event.
1 Like
the few prints i used the panda pi board so far, the raspberry pi3 was powerful enough.
And there runs Marlin and OctoPrint together on the board.
I had no issues.
Sadly the printer is actually partially disassembled.
The other is a mk3 with an Einsy.
Using one on the Makibox 
And for my new custom build there is still one mgn rail missing.
So i couldn't test it more ...
Actually i have 2 pandapi boards (V2 and V2.5) so @foosel if you want to test/play with one ...
I still have a "Semester-Ticket" ...
Pushing from Prusa -> Pi -> SD card on the printer's controller board necessarily uses the same USB serial connection that's streaming the print job, right? I personally would never do this during a print job. The firmware is already working like crazy to manage its receive buffer and the RAM is super-limited over on that side. I would not complicate things by further taxing that RAM to now buffer an SD I/O event.
So, what would you suggest?
Would a node-red or mosquito installation running in the background hinder the octoprint process?