Prusa-firmware-buddy: Reliable network/USB printing

[ftrofin]

Version

2.2.0+

Operating system type + version

Mac 10.14.6 / Linux (KDE Neon 20.04 LTS)

3D printer brand / version + firmware version (if known)

Stock Prusa Mini firmware version 4.2.1

Behavior

New feature request

I purchased a Prusa Mini recently and I'm disappointed because I can't print to it remotely. In fact, this was one of the reasons why I chose a Mini (because of the network port).

I understand that Octoprint is one option but I couldn't get it to work (lots of info about Octopi but very scarce about setting up octoprint itself on Linux).

I read on the forums that people consider printing from the USB memory stick the most reliable (especially for long prints) because you don't have to worry about the computer during the print time. But printing from the computer is more convenient as I don't have to do these many steps:

• unplug stick from printer
• plug it into the computer
• copy files to it
• eject the stick
• remove the stick and plug it back into the printer
• select the file I want to print.

How about if you implement the best of both worlds: make printing from the computer even easier and more robust? Instead of having the computer in charge all the time of the file is printing, use the USB stick as a local storage on the printer and copy the file(s) there. So you always print from the USB stick, even when you send the file from the computer. It's basically like a cache. The firmware would create a special folder (like .print_cache) in the root of the stick and copy the file sent over the network there. Then it prints normally from there and deletes the file when it's done. This workflow should be a lot more robust and even easier to implement in the firmware as the software doesn't have to communicate with the computer to constantly read more stuff during printing.

This behavior can be implemented for both Ethernet or USB connectivity and it would allow the computer to disconnect from the printer after the firmware copied the files locally.

Don't hesitate to contact me if you have any questions or if you want to talk.

Thanks!

Florin

[rtyr]

Your issue is better suited for prusa3d/Prusa-Firmware-Buddy, I moved it there.

[Gordontgopher]

I know Prusa are working on network connectivity and further developing the web interface, but whilst the developers battle with covid restrictions and code have a look at https://community.octoprint.org/t/setting-up-octoprint-on-a-raspberry-pi-running-raspbian/2337 for instructions on seting up Octoprint on a Pi, that should give you pointers for other platforms / distros. The community is very helpful and if you ask a question on the forum or discord someone will offer help,

[derenma]

@ftrofin I second octoprint. It is absolutely awesome for this kind of thing.

If you don't want to go through the vanilla setup of OctoPrint, just get a Raspberry Pi and flash the OctoPi image here: https://octoprint.org/download/

[ftrofin]

Isn't Octoprint a "print server", i.e. it has control over printing for the whole duration of the printing? So if your computer shuts down or Octoprint crashes then your 12 hour print is compromised. My suggestion was for the firmware to transparently copy the file to the local USB stick a print from there (like it normally does).

[Saij]

What you could maybe do is to use a Raspberry Pi Zero W as a WiFi USB Stick. Like the FlashAir Cards. Then you could mount the Drive via WiFi and still print from USB even without detaching it.

[d-zalewski]

Hopefully wifi support comes to the Mini soon and we will be able to run serial usb over wifi using ESP01.

[ftrofin]

@Saij That might work but it's basically a hack which requires additional hardware, setup and steps. I would really like this to be available by default.
@d-zalewski That's marginally better than printing over USB cable. In fact it might be the least reliable solution (I don't trust wireless as much as wired - if your wi-fi router has a hiccup in the middle of your print after 5hrs of printing, you won't be happy...). The file needs to be transferred all at once at the beginning of the print to the local USB stick then the printer can use the local copy to print. That way you have the convenience of remote printing with the reliability of local printing (from USB stick).

[pkg2000]

@ftrofin You can set up Octoprint on any RPi which you connect by a micro USB cable (phone charger) to the small micro USB port on the MINI. This will automatically connect and you will be able to send files and monitor your print, though not every plugin supports the 32-bit system etc. Currently, PrusaConnect will allow you to only monitor prints, but its functionality will be expanded upon in time, and also the ESP Wi-Fi connectivity. There may be some wifi USB flash drives out there until then. Just make sure it formats to FAT32, as exFAT does not work.

There is no difference in setting up Octoprint on Linux or Mac compared to Windows. Octoprint runs from the Pi, not on your computer. If anything it is easier, as you do not need to SSH to access the filesystem, but you can simply plug the SD card into a reader on your Linux machine to do the edits described to do over SSH (Damn: except change the sudo password I guess.)

No need to have a computer connected (other than the Pi) for the duration of the print, but you will have to option to send the gcode to either the Pis SD card or the printers USB stick. Sending to the printers USB sticks requires it to go over serial which is sloooow.

[seidtgeist]

@ftrofin I understand your frustration and I had the same expectations, I did however follow @Saij’s advice and made it work. I now have a wireless USB stick on a <10€ piece of hardware that I can reliably copy files onto, which will see me through until the network printing software is working.

[ozett]

request from thread-starter was to save results from slicer via network onto the prusa-mini.
i would still request this as a first (small) feature within prusa-soft&hw ...
+1

[Gordontgopher]

Full web access to the Mini is coming, you can already monitor prints using connect local connect (
https://help.prusa3d.com/en/article/prusa-connect-local-mini_133279 ) and more features like upload are being developed. The suggestions are to get the OP a solution to solve his problem whilst waiting for more features.

[Area5142]

I would like a simple network sharing of the USB drive, like the Toshiba FlashAir. No complicated Octoprint or RPi or special web page. This way the USB storage could be used from a file explorer on a PC (Win, Linux, Mac) and gcode send directly from PrusaSlicer as done today with FlashAir.

[seidtgeist]

I would like a simple network sharing of the USB drive, like the Toshiba FlashAir. No complicated Octoprint or RPi or special web page. This way the USB storage could be used from a file explorer on a PC (Win, Linux, Mac) and gcode send directly from PrusaSlicer as done today with FlashAir.

@Area5142 This is what you want: https://magpi.raspberrypi.org/articles/pi-zero-w-smart-usb-flash-drive – works beautifully for me

[Area5142]

@seidtgeist I see what you suggest - An advanced homemade FlashAir, based on RPi Zero.

I already have a FlashAir attached to my Mini and the other Prusa printers - Only had to configure them once and they are easy to use.
What I like is to have the sharing functionality of FlashAir build into the Mini firmware and use a regular USB memory stick as storage. Connection is done through the wired Ethernet port on the Buddy board or if anyone chooses through an added WiFi board.

I like simple solutions with low maintenance and complexity.

[ozett]

seems there is first code for this in the firmware. not fully working, i guess..

look/search for "/api/files" in the firmware

https://github.com/prusa3d/Prusa-Connect-Local/blob/7c41cc834b78312b34183889ace037d64327e772/ui/src/components/upload/component.tsx#L162

[rickarddahlstrand]

Just adding a simple upload gcoede-file to USB-drive will improve functionally 1000%. Please add this soon!!

[ozett]

I would like a simple network sharing of the USB drive, like the Toshiba FlashAir. No complicated Octoprint or RPi or special web page. This way the USB storage could be used from a file explorer on a PC (Win, Linux, Mac) and gcode send directly from PrusaSlicer as done today with FlashAir.

@Area5142 This is what you want: https://magpi.raspberrypi.org/articles/pi-zero-w-smart-usb-flash-drive – works beautifully for me

i tried this on my raspberry pi. i installed samba and save my gcode files over wifi on the raspberry pi zero.
the zero is cabled to the usb-port of my prusa mini. The usb-port powers the raspberry.

sadly one caveat. to make the printer known that there a new files on the raspberry OTG-device at the usb-port, like a usb-stick, one has to reload the OTG-Module like this..

alias prusa='sudo modprobe -r g_mass_storage; sudo modprobe g_mass_storage file=/piusb.bin nofua=1 luns=1 ro=0 stall=0 removable=1 cdrom=0 idVendor=0x0781 idProduct=0x556e bcdDevice=0x0103; sudo tail /var/log/messages'

maybe there is better solution, or the comes one with saving the gcode to the prusa firmware... waiting for this..

[matthewlloyd]

My mind was blown when I plugged my Mini into the LAN and discovered you can't upload files through the Prusa Connect interface - it doesn't even support OctoPrint's simple /api/files protocol.

On the other hand, it looks like Prusa is attempting to write the web server and route handlers in pure C (https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/master/lib/WUI/http/httpd.c#L2628), so it's not surprising it's taking so long - that is quite difficult, especially given the CPU and memory constraints on the Buddy board. With the appendix too I expect not many outside developers are willing to help out.

However, I am also having great success with the instructions here: https://magpi.raspberrypi.org/articles/pi-zero-w-smart-usb-flash-drive. I couldn't get Samba to work with Windows 10 so I'm just copying the files over to the Pi Zero by WinSCP. I'm using the supplied Python script to restart the SD card driver after 5 seconds of filesystem inactivity, and it works great. I upload the Gcode with WinSCP, and by the time I've walked over to the printer, the Mini firmware has automatically selected the most recent file on the SD card ready to print. It would be trivial to add a little Python script that emulates the OctoPrint API to upload files, then this solution would allow direct upload from the slicer.

[OJFord]

Hopefully wifi support comes to the Mini soon and we will be able to run serial usb over wifi using ESP01.

@d-zalewski Why do you not expect that to work today? I have been trying exactly that - ESP01 running as a WiFi/serial/USB bridge plugged into Mini's micro USB port. I don't have it working, but it sounds like you don't expect it to - why not, what's the difference between that and Octoprint on a Pi directly connected, as far as the Mini's concerned?

[ftrofin]

It's almost an year since I got my Mini and I'm still stuck with clunky workarounds while that network port is just sitting there, unused. Cmon Prusa, are you listening? I sincerely regret getting this printer now. I should have gotten a kit for a CoreXY printer...

[derenma]

I'll take that printer off your hands, for sure.

On Tue, Jun 22, 2021 at 1:03 PM Florin T. @.*> wrote:

It's almost an year since I got my Mini and I'm still stuck with clunky
workarounds while that network port is just sitting there, unused. Cmon
Prusa, are you listening? I sincerely regret getting this printer now. I
should have gotten a kit for a CoreXY printer...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/961#issuecomment-866253993,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAWE53VWKOSQN54NOB3GDHLTUDNBFANCNFSM4SQGMQIA
.

[OJFord]

Hopefully wifi support comes to the Mini soon and we will be able to run serial usb over wifi using ESP01.

Why do you not expect that to work today? I have been trying exactly that - ESP01 running as a WiFi/serial/USB bridge plugged into Mini's micro USB port. I don't have it working, but it sounds like you don't expect it to - why not, what's the difference between that and Octoprint on a Pi directly connected, as far as the Mini's concerned?

Update on that: I got it working, the problem was that since the Mini identifies as a USB 'device', and of course the ESP01 (or rather a generic FTDI USB serial board) does too. So connected together nothing happens; they need a 'host'.

So I added an LPC1768 mbed board (just something I had lying around, not important) with it running as a USB host, reading from each and writing to the other. It works. It's slow. I'm not really sure how much of that is a result of putting a wireless network between Octoprint commands and the Mini's ack, and how much is my rusty embedded programming just doing everything inefficiently/poorly.

(There's some really clear improvements I could make, but I'm not convinced they'd make as much difference - 18mins for first layer vs. 11mins for entire print from USB - as they'd need to in order for it to be usable, or how much longer I want to spend on it, at least without it being better supported in firmware (thinking mainly of the store-file/print-file commands mentioned as planned in another issue; I assume that's how the official wireless or even ethernet printing will work).)