Raspberry Pi Zero W

0 views

Skip to first unread message

Etta Lesniak

unread,

Aug 3, 2024, 5:27:14 PM8/3/24

to viouroswhitel

I know you are wondering, yes, OctoPrint will run, and better yet, even OctoPi 0.18.0 boots up fine on it as well, so no new image needed! And contrary to the earlier iterations of the Zero, the Zero 2 is actually a platform I can recommend for the...

I used to run astrobox with a pi zero w (first version) for a couple of years and never had issues with speed or stability. Camera streaming was a bit slow, but usable. Main reason to use it was to be able to run it powered directly from the trigorilla board.

So nothing wrong with the Zero W, as long as you use it within its parameters.
Its biggest problem is supposedly CPU usage with wireless data transfer while printing. So no camera on the Pi, get a standalone IP camera.

I do not capture printing video anyway I have Octoprint to allow me to easily upload files from Cura to the printer (Octoprint) avoiding the memory card swap, to see the progress and time estimates, to cancel a print. To have easy buttons to move printhead/bed around.

I have been using it with telegram to observe long prints from work. I do have a Tasmota Sonoff S20 to control the printer, so I can turn it off if I see something going wrong. I keep Octoprint / Octopi running 24/7 though.

the raspberry's are to expensive and cheap.
when you want to stay closed source and want a favorable and not cheap solution then the Orange Pi Zero H2 is much better and cost the same.
Yes the wifi rates are half of the pi, but the antenna is much better.

For me i would buy a rockchip based board when choosing arm. because they are open source.
for $7 more you get a Pine64 ROCK64
a quadcore with 1,5 GHz with L2 cache, 1 GB ram, 20nm process tech a much better FPU and NEON.
You will also get native gigabit lan (not via USB) and one usb3.0 port, usb ports and wifi ....

I personal i use for server things a baytrail based solution which cost around $100 and consumes around 7W
I am currently running 3 cams and 4 printer bards (2 printers / to for playing around) and 6 octoprint instances on it with one core of 4 half used.

Those who say it's borderline may not have actually tried it. With only the web interface running WITH USB not pi cam. USB camera adds very little to overhead. CPU is mostly under 10%, id say average was 8%. When printing with camera, CPU varies between 30%-70%, I tested speed vs card. Pretty much exactly the same.

I did try it, did excessive testing of various scenarios, finally narrowed it down on CPU load caused by bandwidth utilisation on the built in WiFi interface (btw also present in pi3, just isn't noticeable there thanks to four cores instead of one) and then could reproduce it even without OctoPrint or a webcam in the mix just by curling a file from my NAS.

Can it work under the right circumstances? Yes. Is it recommendable for general consumption by people who wouldn't even know where to look for possible reasons of observed slowdowns (= the majority of users)? No.

If you're going to try to run a USB-based camera on a Raspberry, try to remember that the "S" in USB stands for serial. There's only one good UART in the Raspi. In my humble opinion, it's best to keep the webcam as the ribbon cable variety since that won't try to use a UART, possibly taking the good one.

Agree big time with cpu maxed out at 100% when rendering. I'm using built in wifi as well. I'm using an external hub since I need 2 usb ports. For Outsourced, The UART takes serial and converts it to parallel in hardware. All the pi sees is that parallel data is available. The USB also has a limited FIFO buffer in case the cpu is busy. I'm not using the Ethernet port that's on the external hub. It may contend for serial resources.

As far as nubi's I can understand a "standard" config that's pretty bulletproof. I feel like if someone can get octoprint running, the only extra thing they need to know is htop to get cpu usage. But again, I understand and defer the experts.

The Prusa guy was clueless. He even has them solder the board on instead of using a header and pin combination. And then of course, his configuration leaves the bad UART on the GPIO pins and it took one of his users to figure out that you have to disable Bluetooth and to turn off a serial feature in sudo raspi-config so that it wouldn't keep dropping the serial connection.

They were probably aiming for a small footprint (to have it inside the Einsy case), low power requirements (to power up the Zero directly from the Einsy board) and easy access from a price perspective (5-10 USD being more tolerable than 35-40). Without a webcam and additional plugins, the Zero mostly works; when you start piling up on it, that's when things go bad. So just like alfred.w above, the Zero has been repurposed and printing is done from a Pi 3.

I am using Pi 0W with Pi Camera V2. I use it to remotely monitor my prints and adjust temperature. I have not tried running code from it nor do I intend to. It works great! After printing a few camera mounts I settled on this one :2736439 . I think it is the best one out there.

I wish I had researched first before I bought this damn Pi zero W. My mistake for assuming that since Prusa endorsed it so much that they built in compatibility with their MK3S. I just built my MK3S, ordered the Pi Zero and had it set up and ready to go before the printer even arrived. I have a Pi 3B+ on my Ender 3 Pro that runs beautifully, but again, since it's built in, no need for external box or occupying the USB port to connect it...went with the Pi Zero. DON'T DO IT!! This thing is sooooo slow. Causing print errors too. I have a logitech 270 webcam attached and even the 720P resolution it has is too much and if you look in on your print, you're liable to over tax the tiny Pi zero and get messed up prints. The damn thing can't handle pushing the video out, and handling the g-code at the same time.

Prusa...if you're monitoring these forums...you REALLY should mention the poor performance, and NOTE that it's ONLY useful for enabling wireless printing, but NOT to install any mods in the Octoprint, and DEFINITELY don't connect a camera!!! Lesson learned and $ down the drain on a piece of *hit Pi zero. Now, since I pre-attached the micro USB to USB adapter and inserted the Pi Zero into the board BEFORE I mounted it, now I have to completely removed the board to remove the PoS Pi Zero...either that or cut out a section of the cover so I can wiggle it off with a flat head screw driver (probably what I'm going to try, then print a patch to whole where I removed the Pi Zero from the backside.

I've just connected using Octopi with a 3B and an external USB Logitech C720. I'll be trying a RPi camera module soon. So far it's working well but you do want to avoid bogging down the RPi mid-print. Did you have specific questions?

Zero is fine for a camera with MotionEyeOS in dedicated mode. Probably good enough for wifi printing with nothing added. But yeah, they're underpowered for serving up camera streams while printing. Still, having a Zero or three around is always useful.

Yah, I'm going to do what I've done on my Ender 3 Pro, and that's print a case for the 3B+ that will attach to the MK3S, power it using it using the supplied 2.5A power supply, then connect it via the USB on the MK3S.

The ONLY silver lining for me with my experience with this WAY underpowered RPi Zero, is that at least the SD card I have in it is already setup with Octoprint, fully updated and tweaked the way I like it...ready to pop into the 3B+ when it arrives Saturday. I'll still have a few minutes work on my router, setting up static IP & port for it on my network...but otherwise...now that I even have the enclosure printed and ready to go for it...once it arrives Saturday...within 10 minutes I'll be wireless and with power to spare.

This next bit is a bit off topic as well, but...I gave serious consideration to just using the 3B+ that I have attached to my Ender 3Pro to run a second instance of OctoPi and just use it to run both of these printers. YouTuber, Chris Riley ( ) Has a great tutorial on running 4 instances of OctoPrint from a single 3B+ to run 4 of his printers. My only concern was the risk of bottlenecking it and running into performance issues if running simultaneous prints and streams. With the 3B+'s 4 cores, I'm guessing it would handle the 2 printers, streaming and gcode w/o difficulty, but that also means I'd have to keep them setup fairly close to one another (at least as far as the USB cable is long) for the single 3B+ to do this. Went ahead and just ordered another 3B+ so that I have more flexibility with physically placing the printers wherever I want.

At any rate...the RPi Zero was a disappointment and waste of time and money. But if you guys have a decent one, like the 3B+ running another printer, you CAN at least follow Chris's tutorial that I linked above on how to run multiple instances. Just be careful that you don't add too many and divide it's processing power too greatly that you figuratively end up with multiple RPi zeros ? But I'm confident it could easily handle 2 instances w/o significant performance hits, and certainly wouldn't muck up the gcode like the RPi zero was doing when I'd try to stream it to look in on the job process. It was weird...at each section of the print that I looked in on...in the end...when looking at the model I printed, I could see defects in at the layer heights that were printing when I looked in on it using the webcam.

I really don't understand the compulsion to load poor hapless RPis up beyond their limits. They're great inexpensive little devices, and very well suited to dedicated functions, yet so many of the youtuber ilk seem intent on loading them up with full desktops and extra services. A new board with more CPU, RAM and IO comes out and they declare it the "Raspberry Pi Killer" ignoring the fact that it costs 3-4 times as much. A spool of filament will cost me somewhere close to the price of a RPi. I'm not about to risk hours of a long print, my prep time and the cost of filament saving a few bucks on another RPi, much less putting 2, 4 or more such prints at risk. Why on earth would I want to introduce a somewhat fragile device as a single point of failure for more than one such print? It's not like you can share a camera module with multiple printers.