I’ve been doing a lot of testing of the true volumetric extrusion and firmware retraction code I’ve been working on, and I’m loving it more and more.
Besides making it SO much easier to tune the machine by allowing you to modify filament diameter and all of the retraction settings on the fly (without re-slicing, or even restarting a print), it makes it possible to do something that I never thought would make such a huge difference…
It turns out that the retraction and recover speeds should not be the same. Retraction should always be as fast as possible to quickly zero the pressure of the plastic in the nozzle, but recovering from retraction should be closer to the speed that plastic is actually going to be extruded so that the nozzle has the correct pressure as the extruder starts to move. This is particularly important on bowden extruders, where there can be significant delays in nozzle pressure response.
Most people use extra extrusion on restart to make up for the slow repressurization of the nozzle, but this results in extra plastic being extruded, and that plastic has to go somewhere. Slowing down the retraction recovery (something that none of the slicers I’m aware of support) with no extra extrusion on restart puts the right amount of plastic exactly where it belongs.
This is great news being as I am in the calibration stage of setting up my printer. I’ve been looking into all of the things I will need to tweak and there a quite a few “nobs” that need to be adjusted to be able to get accurate prints. With this new method what are the main adjustable parameters?
Excellent work @Whosa_whatsis We had seen this for some time with printing nylon. For 3D Forging customers, the retraction wasn’t used as the part would go through a final CNC clean up pass, eliminating strings. However for more complex prints it was an issue. To solve this, we implemented a similar effect by using slic3r ver 6. 6 Set’s E(A) axis back to (0) on each retract. Because of this, we wrote a simple script to reduce the return material amount and speed. So for a retract of 7mm on a 1mm nozzle, we would pull 7mm at 100% speed, push at 10% speed and only push 6mm back. Even though you’re in retract, you’re still in the hot-zone and the material is expanding. This all but eliminated stringing. Testing is required to make sure the thread start isn’t starved (thin thread).
@Brigham_Valdez Never seen almost shapes on a CoreXY, but on a discrete cartesian, they usually indicate backlash. Could also be that your X and Y aren’t square (I imagine uneven tension between the two belts would cause this on a CoreXY. I haven’t looked closely at the CoreXY code, but I didn’t like what I did see, and I’ve been thinking about giving it a rewrite, though I don’t think that’s where your problem is.
My modifications have been accepted into the mainline Marlin.
@Mike_Creuzer I’ve thought about that, and it should help compared to just doing a high-speed recover move, but I think that just doing the slower recover move should result in more even flow going into the start of extrusion.
@Kodie_Goodwin these two features (volumetric E units and firmware retraction) allow you to adjust filament diameter, retraction/recover speed and amount, and retraction Z-lift, all on the fly.
@Ashley_Webster The slicer still decides when to retract, but with firmware retraction, when it’s time to retract, the slicer simply tells the firmware to retract (G10), and the firmware decides what that means. Likewise, when it’s time to start extruding again, the slicer issues a G11, and the firmware knows how to prime the nozzle to start extruding again.
Just thinking past the obvious improving the current process. The “slice once, print on totally different machines” concept is incredibly exciting.
This allows us to open a whole new area of printing. We would no longer be forced to slice models, but can now model direct to g-code and take advantage of properties of our printers that aren’t available otherwise. Being able to do some crazy cool stuff like ‘bridge walls’ and the like becomes very easy.
Your work also will help with the proliferation of low power print controllers like rasp-pi and android tablets as they can print any pre-sliced files.
I find this very exciting! I can’t wait until until the slicers are supporting this so we have end-to-end support!
@Mike_Creuzer , from one of my comments in the thread on the original post:
As for slicer support, Slic3r (as of RC1) and Kisslicer both have options to enable firmware retraction, and you can force volumetric E units in any slicer by setting the filament diameter to 1.12837916709551mm ( 2*sqrt(1/pi) ). Cura has an option to use the UltiGCode flavor that uses both firmware extrusion and volumetric E units, but it doesn’t currently allow you to use start and end codes with it, which are needed for the vanilla Marlin implementation (though they can be added manually after slicing and saving the gcode, which is what I did for the print I am running as I type this). +Daid Braam has mentioned that the fix for this is simply a GUI issue.
BTW, these features are built with UFID in mind, so eventually you won’t even need to set the temperature and filament diameter, because the printer will already know that based on what filament is loaded.