Rpi Zero & Octopi working!!!!  

Re: Rpi Zero & Octopi working!!!!

I've recently looked into this myself. Several months ago, the Octoprint developer said WiFi on the Pi Zero W was a real CPU hog
https://www.reddit.com/r/3Dprinting/comments/5woeut/will_this_new_10_raspberry_pi_with_wifi_and/demb14z/

I personally use Octoprint on a Zero W but disabled WiFi and Bluetooth in config.txt (deliberately as the WiFi speeds on the Zero W are pants anyway - havent tested WiFi recently). It's connected to a K8400 Velleman Vertex (it's still based on an Atmega 2560 running Marlin) and even on a USB Ethernet adaptor to reduce CPU overheads it really struggles to keep up "shovelling data" over a 250000 baud USB serial link unless the webcam is turned off and it's doing very little else. Average CPU usage in top shows 25 to 55% usage just with the web interface for Octoprint and streaming g-code over USB serial. Pi is set up for command line operation via SSH, no desktop. Still get the occasional zits on prints 🙁

Printing circular things pose the biggest challenge as there are multiple G-code commands drawing out the curve which (I guess) fills the buffer quickly and then we are totally reliant on how responsive each command is sent from the pi to the printer. Any delays in g-code transmission over USB serial results in zits on the printed object as the printhead pauses for what must be microseconds. I'm only guessing here but what probably doesnt help matters on a slow CPU is that Octoprint appears to be written in Python, which isn't the fastest language around as it's interpreted, compared to C which is compiled. My next test will be with a Raspberyy Pi 3, once I get hold of my MK3 printer! Octoprint speeds are probably better off raised with Gina Häußge on the Octoprint site.

Re: Rpi Zero & Octopi working!!!!

What about the other Octoprint type programs, are they just as bad if used on RPi Zero/W?

Re: Rpi Zero & Octopi working!!!!

I've never tried anything other than Octoprint. A quick google reveals Astroprint, but I've read that Astroprint borrows heavily from Octoprint anyway.

Suggestions to alternatives welcome!

Re: Rpi Zero & Octopi working!!!!

I managed to configure my new toshiba Wifi SD yesterday (after hours of playing...), set it as mapped drive and that's all i want: to drag&drop a file to SD without moving SD. So i guess my story with RPi is pretty much over. I dont' intend to print directly from printer, because it's just too many factors that cango wrong - wifi can go down, PC can freeze, RPi can freeze... printing from SD is the most reliable in any case. And especially because even picture via RPi is - well, nicely said terrible. 640x480 isn't something to be proud on and if i change it to better quality i get 1-2 fps at best. What's the point of 5MP camera then?
I'll rather put standalone camera beside my printer and connect it to my NVR.

Re: Rpi Zero & Octopi working!!!!

I have a Toshiba wifi W-03 card coming as well. I planned on the RPi and camera stuff that I bought earlier but if the wifi SD card works as I've heard then the Octoprint and Pi Zero are history. I can use the Pi Zero and camera or other type camera setups for the time lapse and monitoring game. I guess I can still use the Pi Zero wifi and camera standalone and just power it ONLY from the MK3 Einsy board.

Re: Rpi Zero & Octopi working!!!!

Ok few things. These issues are mostly software bugs. I had issues with PiZero and direct from the SD on firmware release Dec 30. I been running on a zero for a very long time with MK2 and RockMax witn not issues on RBzero. Only reason is stop using it whit MK2 is when i ungraded to MM and it did not work right with MM firmware. Also gcode does not require high serial speeds. I bet you can get away with using 9600.

Now getting back to the main issue. Testing the latest firmware 3.1.1 b150 RC5 with RbPiZero. So far so good no issues with everything turned on. Going do do a longer print that I know failed before.

Re: Rpi Zero & Octopi working!!!!

New firmware rocks. No issues with octoprint on RBZeroW with all settings turned on. I did a few prints including a 20hr print zero issues, no errors in logs or werid movements. How every i have found issues with Slic3r (from Jan 5 OSX). Seems not slice modle correctly, droping parts of objects. Same model has no issues in simply3d. Also odd thing i notice is the flow rate is 95 for all layers. Usually its was only lowed on the first layer not others.

Re: Rpi Zero & Octopi working!!!!

I just wrote the Prusa image onto my 32GB SD card and its left 22GB unallocated.. Any idea how you write the image so that the whole card is usable? Or do people just use 8gb cards instead?

Edit: just read that Octopi has an auto expand feature to use more of the SD card, so i think i am worrying about nothing,

Re: Rpi Zero & Octopi working!!!!

I just wrote the Prusa image onto my 32GB SD card and its left 22GB unallocated.. Any idea how you write the image so that the whole card is usable? Or do people just use 8gb cards instead?

Thinking about it.. Perhaps I just partition/format the free space and mount them (such as /GCODE and /VIDEOS) perhaps?

Re: Rpi Zero & Octopi working!!!!

If ocotprint does not auto expand, you can do it via the raspi-config interface.

See here: https://www.raspberrypi.org/documentation/configuration/raspi-config.md

Option one does the trick.

Re: Rpi Zero & Octopi working!!!!

How are people safely shutting down the RPI without risk of corrupting the SD card? If you turn off the power to the MK3 does it kill power to the Pi? If so, does turning off the power to the printer initiate a safe shutdown command on the Pi or is the Pi constantly powered by the board, despite being turned off.

If the Pi powers off with the power of the printer the SD will eventually be corrupted by not powering it down properly. I may solder up a graceful shutdown button to the Pi if that's the case.

I apologize in advance if I'm not being clear. Currently batting a horrible migraine.

Re: Rpi Zero & Octopi working!!!!

How are people safely shutting down the RPI without risk of corrupting the SD card? If you turn off the power to the MK3 does it kill power to the Pi? If so, does turning off the power to the printer initiate a safe shutdown command on the Pi or is the Pi constantly powered by the board, despite being turned off.

If the Pi powers off with the power of the printer the SD will eventually be corrupted by not powering it down properly. I may solder up a graceful shutdown button to the Pi if that's the case.

I apologize in advance if I'm not being clear. Currently batting a horrible migraine.

Shut it down via the web interface before powering off your printer. That should leave you as safe as possible.

Re: Rpi Zero & Octopi working!!!!

Shut it down via the web interface before powering off your printer. That should leave you as safe as possible.

Cool, thanks for getting back to me. I thought that was going to be the response, or SSH into the Pi and shut it down. I'll solder up a graceful shutdown button so all you'll have to do it press the button, wait 2 seconds, and shut off the printer.

Re: Rpi Zero & Octopi working!!!!

fwiw I've used Pi's of different models in different capacities for years, and I've cut power to them hundreds (thousands?) of times, and I've never had an SD card corruption issue. I know that "it doesn't exist because it hasn't happened to me" isn't a good argument, but this seems like a rare event.

Re: Rpi Zero & Octopi working!!!!

It's truly a your mileage may vary. I've had SD cards corrupt after yanking the power just once without properly shutting down and others survive several improper shutdowns. I plan on keeping very organized gcode folders for each project and would like to prevent corruption if I could. Soldering up a button that executes a graceful shutdown is no sweat.

Re: Rpi Zero & Octopi working!!!!

Has anyone physically confirmed the supposed "high CPU usage due to the wifi driver" on the raspberry pi zero W while using octoprint?

And is it causing any issues?

That argument is a dead end. I have been using RPi Zero Ws since they came out via USB to my MK2s. I never saw any performance related issues on the PI, nor the MK2. So long as you have the Octopi configured correctly with enough drive space and buffers, it works perfectly fine even with camera and gcode visualization, so I think we need to look elsewhere.

Re: Rpi Zero & Octopi working!!!!

I had issues with my pi zero w, even w/ overclock and cam disabled. Swapped the SD card over to a spare PI3 I had laying around for another project. Top is same gcode from pi zero w, and bottom is pi 3. Same SD card in it and everything. YMMV this is mine, switched to PI3 and have significantly less issues.

Re: Rpi Zero & Octopi working!!!!

Interesting. I just hadn't seen any issues nor anything taking up much process with exception to the video processing of the timelapse. Perhaps all Pis are not created equal and there are definitely opportunities for various versions of modules out there. I have always kept my Jesse and Octopi up to date via apt-get upgrade/update vigilantly. Thanks for posting your results.

Re: Rpi Zero & Octopi working!!!!

INteresting. I just hadn't seen any issues nor anything taking up much process with exception to the video processing of the timelapse. Perhaps all Pis are not created equal and there are definitely opportunities for various versions of modules out there. I have always kept my Jesse and Octopi up to date via apt-get upgrade/update vigilantly. Thanks for posting your results.

Ah yup this was a fresh install w/ update before prints, coming from a printer that didn't need octopi. I think it may have something to do with the pi zero being single threaded and the pi 3 being multi threaded. If something is demanding the core's attention when it is trying to send printer commands and its even a ms or two off it can add blemishes. The rose has a bunch of rounded parts which require a lot of updates I think. I haven't benched the original pi zero either, might have gotten a dud hah.

Re: Rpi Zero & Octopi working!!!!

I should have probably included that these were both connected to the PI headers on the board, and not through the USB plug.