Firmware retraction retract/unretract independant feedrates

deckingman · 9 Jul 2016, 21:09

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?

dc42 · 7 Sept 2016, 21:31

@W3DRK:

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.

bot · 7 Sept 2016, 21:45

I believe KISS slicer has this functionality.

W3DRK · 9 Jul 2016, 22:20

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.

W3DRK · 27 Oct 2016, 13:40

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.

http://sublimelayers.blogspot.com/2016_10_01_archive.html

T3P3Tony · 27 Oct 2016, 13:47

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

dc42 · 27 Oct 2016, 14:08

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.

Sniffle · 27 Oct 2016, 14:36

could you setup macros for that are executed for retract and unretract, that send gcodes for feedrate changes during the retract and unretract?

dc42 · 27 Oct 2016, 14:49

@Sniffle:

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.

W3DRK · 27 Oct 2016, 15:02

That's fantastic news! Thank you!

@dc42:

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.

deckingman · 27 Oct 2016, 16:26

@Sniffle:

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.

W3DRK · 27 Oct 2016, 18:12

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

dc42 · 27 Oct 2016, 18:36

@W3DRK:

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.

W3DRK · 27 Oct 2016, 19:16

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.

W3DRK · 27 Oct 2016, 19:35

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?

dc42 · 27 Oct 2016, 19:58

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.

deckingman · 27 Oct 2016, 20:05

@ W3DRK Just out of curiosity, have you tried playing around with pressure advance (M572) and if so, did it do anything for you?

Ian

W3DRK · 27 Oct 2016, 20:43

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.

W3DRK · 28 Oct 2016, 12:48

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.

@dc42:

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.

T3P3Tony · 29 Oct 2016, 09:25

Update:

See David's post here: https://www.duet3d.com/forum/thread.php?pid=3931#p3931