Feature Request: Delay after retraction restart for Bowden #1677

Closed
alexborro opened this Issue Jan 6, 2014 · 26 comments

Projects

None yet
@alexborro

An usual issue on Bowden printers is the delay of extrusion on retracts restart... the filament takes some time to start flowing while the printer already started to trace.

It would be great having a "delay on retract restart", I mean, the printer wait for "n milliseconds" before print moves after the retract restart. That time would be enough for the filament start flowing..

The implementation is quite easy, just a "G4 Pn" after retract restart.

Alex.

@mrbi11
mrbi11 commented Jan 6, 2014

i have the same problem.

I set my retracts to ridiculously small amounts to try to compensate.
Like 0.5.
It seems to help with strings, but starts extruding more quickly.
An incomplete workaround at best.

I don't think it is a bowden only issue, If you retract a full
centimeter, the end will not be melted on most hot ends, by design.
It will always take some time for that to melt again.

*peace,
Bill Kelley

  • 512 266 1896

On 1/6/2014 8:30 AM, alexborro wrote:

An usual issue on Bowden printers is the delay of extrusion on
retracts restart... the filament takes some time to start flowing
while the printer already started to trace.

It would be great having a "delay on retract restart", I mean, the
printer wait for "n milliseconds" before print moves after the retract
restart. That time would be enough for the filament start flowing..

The implementation is quite easy, just a "G4 Pn" after retract restart.

Alex.


Reply to this email directly or view it on GitHub
#1677.

@nophead
nophead commented Jan 6, 2014

Perhaps you could simply slow down the restart so it takes long enough for the right amount of plastic to be extruded by the end of it. If indeed the hot end is not melting it fast enough better to feed it more slowly than ram it in faster than it can melt as that will build up spring tension in the tube.

@mrbi11
mrbi11 commented Jan 6, 2014

I think adding a delay to slow down the rate was the request, so I
probably don't understand what you are saying.

It does not need to slow down in general, as it can keep up with melting
new stuff as fast as it comes in.
I think the "F" field lets you specify the speed, so putting in a very
slow speed, just for reversing the retract
should have the same effect as a delay.
I think you can control the speed, but it uses the same speed for
retract and un-retract.

In general, you can retract as fast as you like, but the time to reverse
it depends on whether it has been retracted far enough to solidify
in the cooled section of the hot end. My hack is to not retract to the
point none of it is liquid.

I would guess it is always best to retract as fast as possible, to
minimize leakage, but un-retracting has other limitations.

So perhaps it is easier to be able to set the speeds separately than to
put in a delay?

(please everyone, I already know un-retract is not a proper word...)

peace,
*Bill Kelley

  • 512 266 1896

On 1/6/2014 11:52 AM, Chris wrote:

Perhaps you could simply slow down the restart so it takes long enough
for the right amount of plastic to be extruded by the end of it. If
indeed the hot end is not melting it fast enough better to feed it
more slowly than ram it in faster than it can melt as that will build
up spring tension in the tube.


Reply to this email directly or view it on GitHub
#1677 (comment).

@nophead
nophead commented Jan 6, 2014

The request was for a delay after restart (un-retract). What I am saying is a slower un-retract is better. In-fact the speed of the un-retract is critical. At the end of it the pressure needs to be correct for the intended flow rate and just enough filament to reach the layer below should have flowed from the nozzle. Any less and there will be a gap at the start or the filament might not anchor if it is the first layer, too much and you get a blob.

So the speed of the un-retract and the distance depends on the intended flow rate. The rewind should be as fast as possible and the distance depends on the last flow rate. I.e. far enough to reduce the pressure to zero. It can be further as long as the restart is that distance plus just enough to raise the pressure to the required value. So in general retract and un-retract distance should be different unless flow rate does not change from one filament run to the next.

@alexrj
Owner
alexrj commented Jan 10, 2014

Wow. I always learn new things from you @nophead. But discovering that Yet Another Option is needed even where I would have never thought makes me a desperate man.

@mrbi11
mrbi11 commented Jan 15, 2014

While I think the delay has merit, I expect it is much easier to make
the retract and UN-retract speeds separate.
If blobs and late extrusion start are an issue one could set retract
speed to 400 and un-retract to 50,
where 50 is the maximum desired extruder printing speed.
(numbers just picked a large and a small).
So the print time is less affected by retracting at 400, not 50, but the
extrusion "momentum" is in the right range for printing, and there
will be no large discontinuity in speed, from 400 to 0 to <under 50> as
would happen with the wait strategy.

With the 2 speed approach, one can find settings where the filament is
always molten at start of next fill and late starts do not happen.
It still minimizes total time by still allowing quick retracts.

It is not clear how one could calculate the correct wait time for an
option, as it is dependent on factors like how long the move was,
1 millimeter or 100, the cooling of the filament is not a constant
amount. The wait would always be wrong for some length move.

Anyway, the immediate problem could be fixed by allowing retract and
un-retract speeds be set by the user i think.

(PS
Slic3r is hamstrung by what one can say in gcode.

It makes me think there should be a higher level gcode G<999> X Y Z E,
whereby you tell the machine to retract E, lift Z,
move to point (X,Y) drop Z, un-retract E and be ready to print before
processing the next fill. Ideally in overlapping motions.
The firmware could track how long the filament has cooled, and may
"know" the geometry or time characteristics of its print head.
Worst case it would just do the same thing as done now with 3 gcode lines.
Really smart firmware could look ahead to the next fill and have ending
extruder speed matching the next fill's extruder speed.
So it might retract at 1000, while moving, reverse the retract half way
to X,Y still at 1000 for 80%, and then decelerate to <under 50>,
matching the look ahead speed. The firmware has much better information
to optimize this both in speed, blobs and slow fill startup.
I could make one for Repetier if anyone wants to test it out.)

peace,
*Bill Kelley

  • 512 266 1896

On 1/10/2014 11:30 AM, Alessandro Ranellucci wrote:

Wow. I always learn new things from you @nophead
https://github.com/nophead. But discovering that Yet Another Option
is needed even where I would have never thought makes me a desperate man.


Reply to this email directly or view it on GitHub
#1677 (comment).

@llluis
Contributor
llluis commented Jan 22, 2014

I though I had the same problem, but in the end, the problem was with (very) different speeds and the pressure in the hotend / bowden tube.
If going from slow perimeter at 30mm/s to a fast infill at 100mm/s, it takes some time to build pressure in the tube, causing a failed infill like the photo:

00deb126-822d-11e3-9791-23c3392fdeff

I was playing with Slic3r source and implemented a test: when changing speeds like that, I "injected" some additional filament to build the pressure, in my example, it was 2mm. It was enough to have a perfect infill.
Would you have any suggestions?

It's pretty much the same place to change the speeds like suggested here, so I will try to have un-retract speed at a different speed from retracts.

@alexborro if you want, I can implement the delay after the restart also so you can test it. It's, again, the same place to change the code.

@mrbi11
mrbi11 commented Jan 23, 2014

You could simply edit the gcode file and alter the un-retract speed (F
parameter I think) as a test.
That is in place of injecting additional filament.

Also, there is a parameter to add some extra to the un-retract amount,
sso it rectracts X and unretracts X+extra.
I think on the extruder settings.

I would be very interested in your results.

*peace,
bill kelley
512 266 1896 *

On 1/22/2014 2:21 PM, Luís Andrade wrote:

I though I had the same problem, but in the end, the problem was with
(very) different speeds and the pressure in the hotend / bowden tube.
If going from slow perimeter at 30mm/s to a fast infill at 100mm/s, it
takes some time to build pressure in the tube, causing a failed infill
like the photo:

00deb126-822d-11e3-9791-23c3392fdeff
https://f.cloud.github.com/assets/708868/1978302/fc363b32-83a1-11e3-884f-b3ecb0fd1351.JPG

I was playing with Slic3r source and implemented a test: when changing
speeds like that, I "injected" some additional filament to build the
pressure, in my example, it was 2mm. It was enough to have a perfect
infill.
Would you have any suggestions?

It's pretty much the same place to change the speeds like suggested
here, so I will try to have un-retract speed at a different speed from
retracts.

@alexborro https://github.com/alexborro if you want, I can implement
the delay after the restart also so you can test it. It's, again, the
same place to change the code.


Reply to this email directly or view it on GitHub
#1677 (comment).

@llluis
Contributor
llluis commented Jan 23, 2014

The extra length on restart doesn't work as the problem is with changing speeds (different flow rates require different pressure in the tube) and not the retract itself.
It's the same thing, but applied at a different situation.

To change the un-retract speed in the gcode, you would have to write a script.
Much easier (to me) just change Slic3r code (it's done already).
;-)

My retract is working great.
My point is: maybe you guys are blaming the retract, but the problem is elsewhere, like mine was.
Even if I disable retraction, I would see the failed infill at speed change.
Injecting the extra filament, the problem is gone. Is just a matter of adjusting the amount to be injected.

@mrbi11
mrbi11 commented Jan 23, 2014

I didn't realize you had it implemented. Cool, but I cant tell what "it" is.
Do you inject for any speed change?
Can you describe what the algorithm is?
I had the impression you just edited the gcode to add a do nothing fill,
because you knew where the problem was occurring physically.

*peace,
bill kelley
512 266 1896 *

On 1/22/2014 10:55 PM, Luís Andrade wrote:

The extra length on restart doesn't work as the problem is with
changing speeds (different flow rates require different pressure in
the tube) and not the retract itself.
It's the same thing, but applied at a different situation.

To change the un-retract speed in the gcode, you would have to write a
script.
Much easier (to me) just change Slic3r code (it's done already).
;-)

My retract is working great.
My point is: maybe you guys are blaming the retract, but the problem
is elsewhere, like mine was.
Even if I disable retraction, I would see the failed infill at speed
change.
Injecting the extra filament, the problem is gone. Is just a matter of
adjusting the amount to be injected.


Reply to this email directly or view it on GitHub
#1677 (comment).

@nophead
nophead commented Jan 23, 2014

If you inject more filament where does it go? What goes in the extruder
must come out so the object must get too much fill at some point unless it
has been lost as ooze after the retract.

On 23 January 2014 05:02, mrbi11 notifications@github.com wrote:

I didn't realize you had it implemented. Cool, but I cant tell what "it"
is.
Do you inject for any speed change?
Can you describe what the algorithm is?
I had the impression you just edited the gcode to add a do nothing fill,
because you knew where the problem was occurring physically.

*peace,
bill kelley
512 266 1896 *

On 1/22/2014 10:55 PM, Luís Andrade wrote:

The extra length on restart doesn't work as the problem is with
changing speeds (different flow rates require different pressure in
the tube) and not the retract itself.
It's the same thing, but applied at a different situation.

To change the un-retract speed in the gcode, you would have to write a
script.
Much easier (to me) just change Slic3r code (it's done already).
;-)

My retract is working great.
My point is: maybe you guys are blaming the retract, but the problem
is elsewhere, like mine was.
Even if I disable retraction, I would see the failed infill at speed
change.
Injecting the extra filament, the problem is gone. Is just a matter of
adjusting the amount to be injected.


Reply to this email directly or view it on GitHub
#1677 (comment).


Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1677#issuecomment-33097366
.

@alexborro

Chris, I'm talking to Luis for a while about this issue...

The excess of material will remain in the infill.. The system is injecting,
let say, 1% more material for that layer, but all of them in the beginning
of infill, to build up pressure.
We usually set the infill to 20%~50%, so there is enough room for a little
bit more material (1% or 2%).

Cheers.

Alex.

2014/1/23 Chris notifications@github.com

If you inject more filament where does it go? What goes in the extruder
must come out so the object must get too much fill at some point unless it
has been lost as ooze after the retract.

On 23 January 2014 05:02, mrbi11 notifications@github.com wrote:

I didn't realize you had it implemented. Cool, but I cant tell what "it"
is.
Do you inject for any speed change?
Can you describe what the algorithm is?
I had the impression you just edited the gcode to add a do nothing fill,
because you knew where the problem was occurring physically.

*peace,
bill kelley
512 266 1896 *

On 1/22/2014 10:55 PM, Luís Andrade wrote:

The extra length on restart doesn't work as the problem is with
changing speeds (different flow rates require different pressure in
the tube) and not the retract itself.
It's the same thing, but applied at a different situation.

To change the un-retract speed in the gcode, you would have to write a
script.
Much easier (to me) just change Slic3r code (it's done already).
;-)

My retract is working great.
My point is: maybe you guys are blaming the retract, but the problem
is elsewhere, like mine was.
Even if I disable retraction, I would see the failed infill at speed
change.
Injecting the extra filament, the problem is gone. Is just a matter of
adjusting the amount to be injected.


Reply to this email directly or view it on GitHub
#1677 (comment).


Reply to this email directly or view it on GitHub<
https://github.com/alexrj/Slic3r/issues/1677#issuecomment-33097366>
.


Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1677#issuecomment-33115966
.

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É
aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

@ledvinap
Collaborator

Maybe some version of advance (http://reprap.org/pipermail/reprap-dev/2011-May/003323.html) would be much better way to handle this.

Or maybe starting and ending infill at perimeter speed and slowly accelerating/decelerating to infill speed - this should give nozzle enough time to equalize pressure. 'Advance' amount of plastic will be moved from infill start ramp to infill end ramp, but it is spread over whole ramp interval, so it should be negligible ..

@llluis
Contributor
llluis commented Jan 24, 2014

@mrbi11 Yes, I have it implemented already in my Slic3r 1.0.0RC2.
This started as a "proof of concept" for me, to verify if my suspicion was correct and that it would work. And it worked!
Right now the algorithm is simple: just detect the speed change and, based on the increase, inject more filament to create the required pressure.

For instance, here is an example:

Increase from 16 mm/s to 40 mm/s (150%). Advanced: 1.25 (mm)
Increase from 24 mm/s to 40 mm/s (67%). Advanced: 0.478571428571429 (mm)
Increase from 16 mm/s to 40 mm/s (150%). Advanced: 1.25 (mm)
Increase from 24 mm/s to 80 mm/s (233%). Advanced: 2.33 (mm)
Increase from 24 mm/s to 80 mm/s (233%). Advanced: 2.33 (mm)
Increase from 20 mm/s to 50 mm/s (150%). Advanced: 1.25 (mm)
Increase from 30 mm/s to 50 mm/s (67%). Advanced: 0.478571428571429 (mm)
Increase from 20 mm/s to 50 mm/s (150%). Advanced: 1.25 (mm)
Increase from 30 mm/s to 100 mm/s (233%). Advanced: 2.33 (mm)

@nophead I was experimenting trying to find a solution to my problem. I did try to remove the additional filament injected, but this caused flawed perimeter at low speed. So, right now, I'm just injecting filament and not removing it. I don't know why this happens. I'm studying the subject yet and your input is very valuable. AS @alexborro indicated, the additional filament seems to be spread over the infill.

@ledvinap I've been using Repetier's advance implementation (I did try Marlin also) for a while now, since version 0.6 I believe. While it helps a lot in infill quality, it looks to me that it works only releasing pressure, not creating it. For instance, when doing a solid infill, I can see the extruder retracting during the direction inversion, avoiding blobs in the corner touching the perimeter. Also, when infilling small areas, the same retract occurs, leaving a much more smooth surface. However, for the speed change I described here, it does not advance, creating the necessary pressure. If I increase my advance variable in the configuration, it starts to retract too much, causing a completely flawed extrusion.

Maybe I'll try to implement a simplified version of the advance in the Slic3r, to see how it goes. I was also reading about Sailfish firmware, which has a different implementation of the advance algorithm: http://www.makerbot.com/sailfish/tuning/#5

@nophead
nophead commented Jan 24, 2014

To run at a higher flow rate then it is correct that you need to unretract further at the start. To create the higher pressure necessary you need to compress the filament / tension the Bowden cable more. At the end of the high flow rate run you should also retract further to release the tension / pressure to match.That way there is no extra plastic extruded overall because all the retracts match the preceding un-retract.

@4ndreas
4ndreas commented Jan 29, 2014

Well I have similar problems, but i think a good solution would be different speeds for retract and unretract.
I can retract with about 70 mm/s but then I lose sometimes steps at unretract. Because you need much more torque to set the filament under pressure.
So you could retract with about 70mm/s and unretract with about 25 mm/s or slower.

@fehknt
Contributor
fehknt commented Feb 12, 2014

On my machine I can retract and prime at about 75mm/s just fine depending on what gets printed next: slow perimeters are OK but fast and/or thick infill will cause skipped steps on E somewhat after the prime. I run at 55mm/s now as a compromise but particularly after many retracts I still lose steps when starting a fresh batch of infill. Nylon has no problem with this, but PLA does, mostly after doing many gap-fills because of the low flow-rate with lots of retracts and related heat creep effects. I think that this solution would help me, and/or using a 'only retract after x mm of filament extruded' setting like Cura has (but Slic3r is nicer!). Not that I want to add yet another parameter. I have wondered if 'avoid crossing perimeters' could be instead 'avoid repeated retractions' which has some of the same effect but that's probably another discussion entirely.

@llluis
Contributor
llluis commented Feb 14, 2014

Hi all,

I've put together a modified Slic3r with the modifications suggested in this thread (and a few others. I really enjoyed adding more features).
It can be found here: https://github.com/llluis/Slic3r/tree/stable
(stable branch)

A description of the modifications can be found in the readme of the repository.
I really would like your input and/or test results, as I only have my machine to test it (Kossel Mini).

The difference using the "pressure advance" is major.
Please see the picture below:

photo

The part in the left was sliced in my version and the part in the right using default 1.0.0RC2.
All parameters were exactly the same.
Perimeters @ 30mm/s and infill @ 100mm/s.

As you can see, using default slic3r, the infill gets broken, as the pressure in the bowden is insufficient for the new speed. After the infill, the inner ring is printed and we have the opposite situation: the pressure is too high and the line gets thicker than it should.

Using the advance, extra plastic is injected to create the pressure for the new high speed. When the speed changes again to a lower value, plastic is removed to match this new speed. So every speed has its "advance value" and the difference is injected or removed during the transitions.

In all my tests so far, I had great results using this.
My bowden now has the same performance of my previous direct extruder.

@fehknt
Contributor
fehknt commented Feb 14, 2014

Wow that sure looks promising! Is this just doing the "advance" that's in some firmwares in the slicer though? Is doing it in the slicer better?

@llluis
Contributor
llluis commented Feb 14, 2014

No matter what I do with the advance algorithm in the firmwares (I tried Marlin and Repetier, using the linear and quadratic terms), I'm not able to get even close to the results I got with my modified Slic3r.

I don't how it's implemented there, but it just doesn't resolve the issue with the bowden.

@neodavid315

Absolutely marvelous, I was just going to go Bowden.

Good timing sir

On Feb 14, 2014, at 3:17 PM, "Luís Andrade" <notifications@github.commailto:notifications@github.com> wrote:

Hi all,

I've put together a modified Slic3r with the modifications suggested in this thread (and a few others. I really enjoyed adding more features).
It can be found here: https://github.com/llluis/Slic3r/tree/stable
(stable branch)

A description of the modifications can be found in the readme of the repository.
I really would like your input and/or test results, as I only have my machine to test it (Kossel Mini).

The difference using the "pressure advance" is major.
Please see the picture below:

[photo]https://f.cloud.github.com/assets/708868/2174647/03a341ac-95b4-11e3-9805-bf71c6edcc14.JPG

The part in the left was sliced in my version and the part in the right using default 1.0.0RC2.
All parameters were exactly the same.
Perimeters @ 30mm/s and infill @ 100mm/s.

As you can see, using default slic3r, the infill gets broken, as the pressure in the bowden is insufficient for the new speed. After the infill, the inner ring is printed and we have the opposite situation: the pressure is too high and the line gets thicker than it should.

Using the advance, extra plastic is injected to create the pressure for the new high speed. When the speed changes again to a lower value, plastic is removed to match this new speed. So every speed has its "advance value" and the difference is injected or removed during the transitions.

In all my tests so far, I had great results using this.
My bowden now has the same performance of my previous direct extruder.


Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1677#issuecomment-35120793.

@DerFlob
DerFlob commented Feb 28, 2014

Hello

I was trying your stable branch of Slic3r, @llluis, because I have similar problems with my Kossel Mini in combination with the Marlin Firmware.
I started using some of your options one by one to see what changes they make. Unfortunately it seems you forgot to actually use the separate speed for unretraction. It still uses the same speed as for retraction.

As you are using a Mini Kossel as well, what values did you find to work best for you?

@llluis
Contributor
llluis commented Feb 28, 2014

Hi @DerFlob, you are correct.
I've forgot to inclusive the different speed.

I pushed the new version now.
Can you retry, please?

As for the settings, I use:
Pressure Advance = 1
Retract speed = 100mm/s
Unretract speed = 40-50mm/s

@DerFlob
DerFlob commented Feb 28, 2014

Thanks, I quickly sliced something and the gcode seems right. I will try it tomorrow on the printer.

@llluis
Contributor
llluis commented Mar 7, 2014

I've commited a new version, including corrections from @DerFlob (thanks!) and a few more features.
It's all described in the readme.

@alexrj alexrj added a commit that referenced this issue Nov 24, 2014
@alexrj New experimental feature for pressure management. Credits to @llluis
…for the original implementation. #1203 #1677 #2018
ff9b532
@lordofhyphens
Collaborator

I think this can be closed, as there's a commit attached to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment