Firmware retraction retract/unretract independant feedrates
-
I saw a bit about this a while ago from Joseph Prusa. Here is a link http://prusaprinters.org/slic3r-and-marlin-configuration-for-reprap-firmware-retraction/.
I personally haven't had any problems using the same speed for retract and unretract on my Diamond, tripple extruder setup so I've no desire to mess with it. Also, I can't quite fathom how unretracting slowly would work. Wouldn't that just cause a delay before filament starts flowing again? -
No, I can't name any slicers that support this, but Smoothieware supports it in their firmware which is the reason I use firmware retraction.
Options are a good thing. Is having finite retraction control in an otherwise high-end 3D printer controller somehow out of the scope of this project?
Not out of place, but I need to get a feel for the priority of implementing this, given that there are so many other items on the wish list.
-
I believe KISS slicer has this functionality.
-
It does make a noticeable difference in reducing blobs with all three of my Bowden equipped printers. And one in particular with a questionable quality hot end it pretty much eliminates jamming in retract-heavy prints as well.
But yes, I'm sure there are higher priority things to implement at the moment… As long as it's not dismissed completely, I'm a happy camper.
-
Here's more evidence to support what I've been seeing where it's very useful to be able to retract and feed at different speeds.
-
It would be useful to not only be able to set the speed in each direction, but also it individually per drive. This could either be the drive as a whole or specific to which tool is selected. This would allow different retract rates and amounts for different materials in multi material printing scenarios
-
W3RDK, I have it already on my list to add another parameter to M207 to allow a different un-retract rate.
Tony, you can achieve the same effect by using M207 commands in your tpost#.g files, if all drives used by a tool need the same retraction parameters.
PS - M207 T parameter will be supported in the next 1.16 beta release, which will probably be beta 6.
-
could you setup macros for that are executed for retract and unretract, that send gcodes for feedrate changes during the retract and unretract?
-
could you setup macros for that are executed for retract and unretract, that send gcodes for feedrate changes during the retract and unretract?
I don't think that would be wise, because there might be contention on accessing the SD card, so opening and reading of the macro file could get delayed if you are doing a file upload or download at the same time.
-
That's fantastic news! Thank you!
W3RDK, I have it already on my list to add another parameter to M207 to allow a different un-retract rate.
Tony, you can achieve the same effect by using M207 commands in your tpost#.g files, if all drives used by a tool need the same retraction parameters.
PS - M207 T parameter will be supported in the next 1.16 beta release, which will probably be beta 6.
-
could you setup macros for that are executed for retract and unretract, that send gcodes for feedrate changes during the retract and unretract?
If you use firmware retraction (G10) there is nothing to stop you sending M207 Sn.n Fnnnn from DWC during a print. In fact, it's the best way to to set your retraction IMO. I printed 2 "cubes" 4mm in X, 20mm in Y, and 20mm in Z spaced 100mm apart in X and simply played around with M207 until I had the minimum amount of retraction with no stringing. Repeat that with different speeds and temperatures and/or different filaments and you end up with the ideal retraction settings for every scenario in very little time.
-
Exactly. Although stringing is easily tuned out, it's zits left behind at the beginning of the next path after retraction completes that I find trickier to eliminate. In my case about -0.1mm un-retract does a good job reducing them for most PLA filaments I've tried.
Which brings up a good question…David, does RRF's implementation of M207 allow for a negative R parameter?
Here's an example, see the back of this Boon I recently printed on my Duet WiFi powered Kossel 250...there's a tiny bit of a zipper effect in some spots but for the most part, there's barely any sign of retractions. Absolutely no zits.
https://drive.google.com/file/d/0B4X2cVKW2B3sTUhKbUV2YS1mSUI2OUk3Zmg3eHdydWVRQmpv/view
-
Exactly. Although stringing is easily tuned out, it's zits left behind at the beginning of the next path after retraction completes that I find trickier to eliminate. In my case about -0.1mm un-retract does a good job reducing them for most PLA filaments I've tried.
Which brings up a good question…David, does RRF's implementation of M207 allow for a negative R parameter?
No, but I've just changed the code so that it does, down to minus the retract length.
-
Excellent, thank you! This firmware just keeps getting better and better.
I will be watching closely for the next 1.16 beta to come out. The last few betas have been working flawless for me on both my Delta and Cartesian printers.
-
I wonder if anyone else would agree, now that firmware retraction support is getting pretty configurable wouldn't it be nice to have GUI adjustments for it in the Print Status screen, similar to the feed rate, extrusion multiplier, and fan speed sliders?
Perhaps a section containing sliders for the retraction length, retract/advance speeds, and a little drop down/text field to enter the positive/negative un-retract length. Or is that a recipe for too much clutter?
-
1.16 beta 6 preview is at https://dl.dropboxusercontent.com/u/19369680/DuetWiFiFirmware.bin. Please note, the pin numbers used by M42 have changed in this release, see https://duet3d.com/wiki/Using_servos_and_controlling_unused_I/O_pins.
-
@ W3DRK Just out of curiosity, have you tried playing around with pressure advance (M572) and if so, did it do anything for you?
Ian
-
I did, briefly, with mixed results. The default setting of .1 seconds works splendidy on my Ord Bot, but I wasn't able to find a value that worked well with my Kossel so I ended up leaving it disabled.
-
I tested this on my Kossel last night and it worked perfectly. Thank you! Once it's released for the "legacy" Duets, I'll be using this on my Ord Bot as well.
1.16 beta 6 preview is at https://dl.dropboxusercontent.com/u/19369680/DuetWiFiFirmware.bin. Please note, the pin numbers used by M42 have changed in this release, see https://duet3d.com/wiki/Using_servos_and_controlling_unused_I/O_pins.
-
Update:
See David's post here: https://www.duet3d.com/forum/thread.php?pid=3931#p3931
