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?
Just responding to this thread, because of "new" activity" apparently.
Sorry for not being able to directly attribute which hardware change "made the difference", but I threw together hardware I had laying around: A Rpi4/2Gb and an NVMe 128Gb SSD in an USB3 enclosure (yes, only using 2%, but the SSD came from a dead notebook).
I could burn the octopi 0.18.0 image straight to the SSD and boot from it. After that I restored my octoprint backup and it ran. (So under Python3). It also streams two USB camera's: One "cheap chinese" endoscope at 640x480, and a logitech C920, at resolution 1920x1080. The Rpi is connected with its a wired gigabyte ethernet port. Not using its WLAN.
I am not mentioning this to recommend this specific combination of hardware, but just to describe what I am using.
The perceived performance compared to my previous Rpi3 / SD-card based installation is notorious. The interface comes alive fast. The web page loads noticeable faster. I can now upload big GCODE files mid-print, without any noticeable effect to the extruder movement. When I look at the resource monitor (through its plugin) and with two screens open (one for each camera), the CPU load remains low. Big files are arc-welded during print, and files become available for printing seconds after uploading.
For me, it is just a so much nicer user experience, so I am at the point that I continue with this, without the urge to see "what could be left out". I would definitely recommend the Rpi4 and possibly see if SD / SSD makes another difference, in case you are not happy with the performance and are using an SD card.
The best way to find out it to monitor its resource usage, to see whether you hit bottlenecks.
The price, in the UK anyway, is the same so shouldn't the question be "Why wouldn't I use Pi4 for Octoprint?".
On a RPi3B+, allthough the Ethernet chip is gigabit capable, the connection from chip to SoC is still via USB2.0, which limits that bandwidth available to 220-250Mbit/s. This is still better than the 100Mbit/s for a Rpi3B.
I decide based on this 3 categories.
The pi3 runs cooler as the RP4 and is good enough for octoprint +1 cam
I use the pi4 if i need more than that and the pi hat.
if not
i use a intel ( Bay/Cherry Trail / Braswell or Apollo Lake) board with a picopsu.
actually it consumes around 20w with a dual tuner dvbs2, 4GB ram, 1ssd for the os in it.
Runs 4 instances, 3 cams, 1 vdr, and the unify controller software. And without the dvbs2 card it was much cheaper than a raspberry pi4 with case and power supply.
In the early Pi4 days, there were concerns on overheating and subsequent down throttling. I do use a housing with passive cooling. The temperature is not a concern with current firmware and the octopi 0.18.0 image for me.
My Pi3B+ cannot keep up with webcam processing in higher resolutions. One cpu core is 100% all the time and streaming (via octopi web interface) isn't great.
serial.log from octoprint slows things a lot (like 5h print becomes 7h print) and it's crucial for debugging of some problems. I would love to have it always enabled. With 4GB rpi4 I could just log into tmpfs (ram based fs) and don't care. Hopefully there will be no time penalty with such setup.
So 3b+ is not always enough. But didn't test if 4 will perform better. Don't have spare 4 yet - waiting.
I would say if you can go with rpi4, go with it. If not, 3b+ is not a bad option.
I don't because it turns out that with writing to serial.log on sd card on rpi3 slows things so badly that even layer shifts happen.
But I would like to have it always enabled and be able to go back and see what happened when needed.
When (or "if" these days) I get raspberry pi 4 I'm going to put serial.log in ram and see if it works without problems.
The writing speed depends on the speed of the SD card and not that much on the calculation power of the SOC. In this case, a RPi4 wont give that huge advance.
It's a good reason Gina mention this:
If you have constant issues, maybe fixing them takes away the need for a constant serial logging.
Also, without serial.log, in case of an communication error, in the octoprint.log the last lines of the serial communication are stored.
Rpi4 is to have 4GB of ram so serial.log can be in ram and not on sd card.
Constant issues are easy because they happen... constantly. Debug log is useful for these rare or intermittent issues.
And I'm not talking about communication issues but issues like
So for one issue that can occur at the start of the print you are logging the complete print?
I'm logging (or rather I want to log on rpi4 to ram) because issues exists and without logging I get no valuable information at all. And hopefully on rpi4 + ram - logging will be fast and not problematic, so there will be no point in NOT logging everything.
Anyhow: Logging if for tracking bugs down, not to keep the alive.
But if you really want to log all, the I recommend something way more powerful than a Raspberry Pi.