Print from sd
Stutter begone: printing from "SD"
One of the features that Redeem introduces in Umikaze 2.1.2 is the ability to bypass OctoPrint feeding the Gcode to Redeem. Instead, we let Redeem read the GCode file directly from the eMMC. This means there are no longer stutters due to a buffer underrun when printing curves or fine details (think screw holes or small radii curves). To keep useability through OctoPrint, Redeem now mimics Marlin's SD-printing related M-codes (M20 to M29).
Let's walk through how to get you started to do so, shall we?
If you've done a flash of Umikaze 2.1.2 from a previous installation of 2.1.0 or 2.1.1, it will have backed up your configuration files, which is user-friendly, but you need to check the right settings are on. Specifically, the SD support feature in the OctoPrint Features tab of the configuration panel.
If it isn't enabled, or the little SD icon above the file listing doesn't appear, toggle the setting, and then restart OctoPrint. (if you had it on but no SD-related functions, turn it off, reboot, turn it on, then reboot one last time).
Literally nothing to do here if you're using the standard folder structures we ship with. If your gcode files get uploaded to somewhere else than /usr/share/models, you may need to modify the Redeem code to point in the right direction. Or, a symbolic link is easier to put in place.
Understanding what it does
So, you've enabled SD support and restarted OctoPrint. Now you notice you have a duplicate of your gcode files showing up in the file list.
Say before the SD settings showed up you had:
Now you should see:
What this means, and you can play with OctoPrint's file panel settings to "Show only SD files", is that you're seeing what Redeem is telling it can see to OctoPrint.
So say you wanted to print File1.gcode. You could just hit the print icon next to File1.gcode, but that would print the old fashioned way - OctoPrint reads the gcode then sends the line to Redeem. Slow. That's what causes the stutter - when the lines are shorter to execute than the time it takes for OctoPrint to send it to Redeem.
Instead, why don't you print /lcl/File1.gcode instead? What OctoPrint does when you select that file is run M23 /lcl/File1.gcode. Redeem then loads File1.gcode in memory for itself directly.
When you hit Print, if the M23 wasn't run before, Octoprint does so. Then runs M24. That starts the print from that file. Pause will issue M25. Resume M24 again. Standard Marlin behavior.
During a print from SD, you will *not* see a preview of the layer in the Gcode Viewer panel. OctoPrint isn't reading the Gcode so it doesn't know where Redeem is in the layer. But, you will see a progress bar based on what percentage of the file's bytes it has executed. OctoPrint gets those percentages by running M27, which, much like M105, returns a formatted response that OctoPrint understands.
We tried to make it work as well as we could. But we have some limits to what the print from SD can do. For instance, the file names should not contain a space. Or a non-ASCII character. Seriously, it will not work if you have either a space or an accented letter. It's able to cope with files that have upper and lower case characters - but don't put, for example, File1.gcode and file1.gcode in the folder at the same time. You won't be able to tell which one you'll be printing!
If you should cancel a print from SD and want to restart it, you'll need to select another file from SD (not print it, just select it), then select back to the one you want to print it. So, if you started /lcl/File1.gcode then cancelled it, make sure you select /lcl/File2.gcode, then select /lcl/File1.gcode again, then you can print /lcl/File1.gcode again. It's a limitation because M25 is technically only pausing the print. It's not explicitly cancelling it, so Redeem doesn't know if an M24 is meant to start from the top or to resume from where it paused.
There may be other limitations or bugs that were overlooked in this page. Please report them on github, Google+ or the #development channel on Slack! We will try to fix the code or update this page to reflect what works and what doesn't. This is also only a stopgap until OctoPrint 1.4.x is released, with a modular communication layer. We'll then be able to offer a much higher level of integration between Redeem and OctoPrint without having to worry about this kind of interface.