hello,
I am looking to make a plugin to support the card flashair, and, I can not find in the document octoprint, if, it is possible to replace the initial behavior of octoprint on SD upload.
What I would like to do is replace the initial behavior of the download on sd by that of flashair, and start the print.
it's possible ?
best regards
I'm wondering about the reasons why you'd want to do this.
The documentation for OctoPrint is on the Octoprint.org website.
I think the reason why is because the upload to sd is so slow with the current implementation, which is part of the reason why I don't do SD printing. There was a pull request against OctoPrint that would enable software flow control, which improves transfer speeds, but is tagged as "needs work", and doesn't appear to be worked on it a bit by the contributor.
Oh... this is for putting the SD card into the printer's controller board like on a FlashForge perhaps. I just rarely do that if it's not necessary. It seems like there's little control over the printer via OctoPrint that way.
Hello,
I want to create a plugin to use the flashair card, for a simple reason, the speed and print quality is much better via SD. because of the speed of serial connection (USB) I have a breaks with the complex prints, which creates blobs on my prints (I already mentioned the subject and you had participated https://discourse.octoprint.org/t/cr-10s-octopi-raspberry-3b-zits-blob/2355/3), I have since changed PI for a 3b +, I also tested without plugin and I add a ferrite ring, the problem is still the serial!
if not yes, it is to put the SD card in the printer and print via SD with octoprint, at least that's what I want to do: p
because currently download a 40 MB file on the SD via octoprint, it's very very long 
otherwise flashair cards have an API and one in particular allows to upload a file.
from what I read (I get the card in the week) the transfer speed is of the order of a few MB / s, it's not huge but it's enough to be comfortable.
ps : I know the documentation octoprint, but I can not find a solution that will allow me to replace the upload system (sd) ocoprint by that of the plugin
Please see the FAQ entry on FlashAir cards below:
Don't upload things to the FlashAir over the API...it's not going to get you any kind of speed advantage. Also, generally don't upload to OctoPrint to upload to the FlashAir, as you're creating a much slower process. Slice and then upload via a WebDAV mount, and then have OctoPrint update the SD card files. If you REALLY need to upload from OctoPrint (you're slicing on OctoPrint, maybe?), use a WebDAV mount for the FlashAir card and a directory watcher to push it over, much the way that OctoPrint moves uploads.
Hello, thank you for your comment, I've read it during my research. as for the webdav, I'll see the time comes (I do not have the map yet :)). at first I would really like to try a full integration with octoprint. there is no way to overload the initial octoprint upload system?
Technically, you could mount the root of the WebDAV volume as the local storage directory, and then filter your files list to only show what's on the SD card and then do an SD card print. OctoPrint would be limited in what it could do about the in-progress print, but you'd be able to upload stuff to OctoPrint and it'd automagically be in the right place once OctoPrint moved it from the watched upload directory. I haven't actually tried this myself, but it should work.
Hello, thank you for your return.
but I do not want to use the webdav, the purpose of creating a plugin, which will replace the current system to upload on SD, because I want the current API is functional (I use the plugin cura octoprint to upload and launch the automatic printing).
Using webdav is problematic because it will take an ssh action to install a webdav client and mount the directory.
moreover, the use of the directory webdav poses a major problem, when uploading a file, it will be imperative to determine that the file has been completely uploaded (finished).
as for the speed, I tested with a file of 150 mo and it took 4-5 min (upload to octoprint and upload on the SD combined), it is not utra fast but always more than via serial.
I just need a solution to replace SD writing of octoprint.
I want to make a solution that everyone can use, if it was for me only, I would have already modify the source octoprint for my needs.
I'm not sure I understand the problem you're trying to solve, and I'm not sure you fully understand how some of these components work.
First, using WebDAV doesn't require ssh, unless you're talking about doing manual installation and configuration, which is a one-time task anyway. If you want to avoid that badly for a plugin, have it handle the install and setup - it's something pretty basic for it to do.
Second, I don't understand what major problem you're having with uploading files with WebDAV as the underlying network protocol for mounted storage. I assume you haven't tried it, because it should be transparent and the hypotheticals you posed don't make sense to me. If you're worried about making sure the file is fully in place before starting the print job, you're creating problems that don't exist, since no firmware loads the entire file into memory...they all read either lines or chunks from the SD card on a rolling basis and process the lines of GCode (often times they load a few lines ahead, but microcontrollers are very resource constrained, so no one is loading a file faster than you can upload it).
I'm not clear what you were talking about at the end of your reply, but uploading over WebDAV should be the fastest method for interacting with remote FlashAir cards from an RPi, since it's handled at a fairly low level and fairly high priority as a series of kernel-level filesystem and network operations and completely avoids the API overhead on the card, python overhead of a plugin, and lower userland priority of doing it in a process instead of letting the kernel handle it. Keep in mind that you're using an embedded system, not a desktop or server class system, and that the RPi has a very poorly designed set of communications peripherals (on the RPi all IO except for GPIO, HDMI, audio, and the camera header goes through a single USB 2.0 port to a hub that gives you the external USB ports and also connects to a chip with the WiFi, Bluetooth, and Ethernet interfaces), so your primary bottleneck is going to be either your software stack (the current serial driver is the culprit for why USB upload is so slow, per @foosel), or that single USB port being used for everything. Anything you can do to eliminate processor overhead is to your benefit.
If you are relying on Cura on an OctoPi install, I believe a WebDAV mount for your local storage directory is probably going to be your best bet, and everything should work automagically. Please keep in mind that you aren't uploading directly to that directory and that if you're slicing on the Pi, it's going to write the gcode file to the filesystem and won't complete until that is done, so I don't see any race conditions here like you seem to be worried about.
Hello,
I admit that I had not tried the webdav directly, but unless you upload the file to a directory TMP, before moving it in the main directory, an impression can still be executed without the file is completely uploaded. it will be difficult to estimate time and others ...
moreover with the webdav system, if there is a network interruption or if another problem appears, the file will never be finished and at the PI, we will print an incomplete file and with the WebDAV, I can not to secure.
conversely, the use of the flashair api card should allow the detection of the error and I could also know when the download is finished.
As for the use of SSH, I do not know if a webdav client is installed on raspbian, but I doubt it.
in this case, it will require an apt-get installation, so an SSH connection.
the use of the flashair API involves a double upload (computer => pi, pi => flashair), it is the default but in the tests, I have a little less than a minute to upload on the pi ( for a 150mo gcode file).
I could provide an option in my plugin for the webdav, but I want to create a more secure system with the API.
so I ask again the question, is it possible to overload the upload system on SD ?
A strategy often used is to start uploading the file as:
myfile.gcode.uploading
...and when it's finished, it gets renamed in-place. The odd file extension prevents it from being available in a lot of interfaces.
Hello
I'll have to look for the .uploading extension, if this method is used for the webdav. but again if an error occurs, nothing can be detected octoprint side (the print will never run ... it's better, but not perfect)
Hello, I finally developed another solution, I'm talking about it here: Expansion card for sending (fast) to the printer SD via octoprint