Just bought a Pi Zero W, as it is dirt cheap. Installed Octopi, and it is just running. Installing is way slower than my old Linux do-it-all box in the corner, but needed to move the printer.
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.
It takes around 5 minutes for the Zero W to start up and settle with CPU usage under 50%. That is another reason to keep it running.
So the Zero W is absolute a possibility, especially for the price. Just be aware of netork traffic and CPU intensive stuff.
I read somewhere discouraged as the goal was to target all users, and not those of us who can tweak the internals.
Without camera (using network cam), there really is no problem running it. File transfer aka WLAN traffic should just be done when printer is not busy.
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.
I hate it when a print job fails 14 hours into it. I try to maximize my chances for success. A Raspberry Pi 3B is close enough to "maximized" for my taste.
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 have not touched anything in the OS, I'm way to dumb to do that.
I encourage others to try it, and decide for themselves.
I don't have a pi cam, so I cannot comment on it, but the CPU has to be busy processing the images. I had an old Logitech web cam, it works great.
My experience with a pi 3, the CPU isn't busy at all. Way more headroom that needed. I can afford the 3, but why not use one of these zero's I have laying around.
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.
It could be I'm printing way slow? I have a monoprice ultimate running at default speeds. Perhaps my objects doesn't enough someing a gons?
Foosel can you recommend a file that would stress test the zero?
I don't think it matters, but the zero w was within 10 feet of the wifi router.
Is this the correct forum for posting our experiences? I may be in the wrong place. Not the first time.
@tivobyte: Referring to a stress test: In this video, The Pi Zero W is tested among some other SBCs. So you may get a tiny glance of what it is capable.
I wanted to figure out why my testing was so different than that of others. Some conclusions I reached by direct observation:
USB web cam adds almost nothing to overhead.
I can absolutely make the zero loose it's mind and "lock up" the CPU at 100% by doing too much file IO. I did make it crash.
100% agree that the zero should not be on the "certified" list or whatever.
it runs fine if you don't mess with it while running. I tend to start a print and monitor it. I may adjust temp or something. Runs the web cam all day long. The only thing I tend to do is cancel a bad print. Works great for this.
It just really bugged me I couldn't re-produce the results at first. Science should be re-producible.
Thanks to all who responded.
P.S. Running plenty of plugins. I do all of the config using a PI 3 then copy the SD card and use the copy in the zero. I wouldn't like to load the OS using a zero...
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.
)