Firmware retraction retract/unretract independant feedrates

W3DRK · 9 Jul 2016, 18:45

I looked at the RepRap.org GCode Wiki for the M207 arguments and it doesn't look like independent feed-rates for G10/G11 firmware retraction are supported. In some circles it's considered best practice to un-retract with a lower feed rate than the retraction, which is the method I prefer to use.

If this is indeed not currently supported, could it be added to the firmware wishlist?

W3DRK

dc42 · 7 Sept 2016, 19:38

Hi,

By what mechanism do you think changing the un-retract speed could affect the print? Do any slicers support different retract and un-retract speeds?

W3DRK · 7 Sept 2016, 20:13

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.

I find I get the best results with 100mm/sec retract, 30mm/sec un-retract. The theory is if I were to un-retract at 100mm/sec there is a greater risk of creating a burst of pressure in the nozzle. The risk of chewing up filament is also reduced by un-retracting slowly.

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?

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